HFS leaks the Math.random() state that signs its admin cookies

loginSrp1 is the first step of HFS's login, and anyone can call it with no credentials ^[7]. Each call runs Math.random() once and returns the result to the client as the session id, sitting inside the session cookie ^[7].

The cookie-signing key comes from the same generator. At startup HFS calls randomId(30), which runs Math.random() three times and concatenates the base-36 output into the key that signs every session cookie afterward ^[6]. HFS runs on Koa, and both the key and the handshake id are produced by Math.random() ^[5].

That generator is not secure. V8's Math.random() is xorshift128+, a deterministic algorithm with 128 bits of internal state, and once you recover the state you can compute every value it has produced or will produce ^[8]. Each output exposes only the 53-bit mantissa of a double, with the other 11 bits dropped in rounding ^[9].

Recovering the generator state is cheap. The attacker makes six unauthenticated loginSrp1 calls, then takes five consecutive session ids. For each one they recover the 53 visible bits and brute-force the 11 missing bits, 2,048 combinations in all ^[10]. Reversing the xorshift128+ recurrence then yields the one internal state consistent with every observation ^[10]. Rewind that state to startup and it reproduces the randomId(30) call that made the signing key. Because V8 rounds strings to their shortest form, a handful of candidate keys come out, and the attacker keeps the one whose HMAC matches a real cookie the server already sent ^[11].

The rest is Koa's own machinery. The attacker builds a session object naming the user admin and signs it with the recovered key the way Koa does. They send it to an admin-only endpoint such as get_config. It answers 200 with no login ^[12]. HFS lets admins register a server_code snippet that the server runs. The forged session calls set_config to install a payload that executes with the server process's privileges. In Horizon3.ai's test, running id returned uid=0(root) ^[13].

The attacker never touches the filesystem, process memory, or environment variables ^[14]. Zach Hanley at Horizon3.ai found the bug in September 2026 using Claude for the analysis, and real-world exploitation started on October 1 ^[3][4]. It affects HFS 3.0.0 through 3.2.0 ^[2].

HFS 3.2.1 swaps both weak spots for Node's secure primitives. The signing key becomes randomBytes(32).toString('base64url'), 256 bits from the OS CSPRNG. The handshake id becomes randomUUID(), so it no longer leaks Math.random() ^[15]. If you cannot move to 3.2.1 yet, set COOKIE_SIGN_KEYS and the server signs with your key instead of the Math.random() default ^[16].