Math.random() session key lets attackers run code on HFS

Rejetto HFS versions 3.0.0 through 3.2.0 generate the signing key for their Koa session cookies using JavaScript’s Math.random(), and the same V8 pseudo-random generator leaks its outputs to unauthenticated clients during the SRP login handshake. That combination is CVE-2026-61500 (CVSS 9.3), now under active exploitation according to VulnCheck.

The attack chain is clean. Math.random() is not a cryptographic generator; its internal state can be reconstructed from a handful of observed outputs. Because HFS hands those outputs to anyone who starts a login, a remote attacker collects a small number of login responses, recovers the generator state, derives the signing key, and forges a session cookie that the server accepts as an administrator. No credentials required.

Admin access is the pivot, not the goal. HFS’s administrative API lets an operator define custom endpoints that run arbitrary JavaScript through the documented server_code configuration feature. Once the forged cookie gets you to that API, you write server-side JavaScript and the server runs it. Horizon3.ai’s Zach Hanley, who disclosed the issue on September 30, 2026, described the result as an unauthenticated path straight to remote code execution. Hanley also noted the bug was found using Anthropic’s Mythos model.

Rejetto shipped the fix in version 3.2.1 in July 2026, so a patch has been available for roughly three months. The public timeline is the part worth watching. A Python proof-of-concept from researcher Alejandro Ramos (aramosf) appeared in late September, Horizon3.ai published additional detail, and VulnCheck’s Patrick Garrity reported the first exploitation attempts on October 1, 2026, the day after. The window between public analysis and probing was effectively zero.

The observed activity is still modest. Caitlin Condon, VulnCheck’s VP of research, characterised it as small-scale reconnaissance: a single China Telecom IP probing Canary deployments in Japan and the United States. VulnCheck attributes the traffic to an unnamed threat actor in China hitting real vulnerable hosts in the U.S. Reconnaissance against honeypots is not yet mass exploitation, but it is the shape that usually precedes it, and the exploit needs no authentication and yields code execution.

If you run HFS, the move is to get to 3.2.1 or later. Everything in the 3.0.0-3.2.0 range is affected, and the forged-session technique works against any unpatched instance an attacker can reach. If you cannot patch immediately, restrict who can reach the server and the admin API at the network layer, and treat any currently exposed 3.0.x-3.2.0 host as potentially already holding a forged admin session.

There is a cleaner lesson in the root cause than in the patch. Math.random() is fine for jitter and shuffling and useless for anything an attacker benefits from predicting. Using it to derive a signing key is the kind of mistake that stays invisible until someone reconstructs the state and demonstrates it, and the login handshake leaking outputs of the same generator removed even the need to guess. Any session or token-signing key that traces back to a non-cryptographic PRNG is forgeable on the same principle, regardless of the product.

CVE-2026-61500 is the second HFS flaw to be exploited in the wild, after CVE-2024-23692 (CVSS 9.8). In July 2024 multiple threat actors weaponised that one to drop cryptocurrency miners, trojans, and the malware tracked as HATVIBE.