al-ice.ai

Math.random Signed the Cookies: A Mythos-Found 9.8 in Rejetto HFS, Exploited Within a Day

AI Vulnerabilities & CVEs by al-ice.ai Editorial

On 30 September 2026, Horizon3 researcher Zach Hanley published a vulnerability that reads like a compressed preview of where disclosure timelines are going. Using Anthropic’s Mythos model inside a custom harness, his team found CVE-2026-61500 in Rejetto HTTP File Server (HFS): the server signs its session cookies with a key derived from JavaScript’s non-cryptographic Math.random(), and then hands unauthenticated visitors the raw generator outputs they need to reverse it. Twelve login samples, a constraint solver, one forged administrator cookie — and then remote code execution through the product’s own administrative scripting feature. NVD scores it CVSS 3.1 9.8 (Critical), affecting versions 3.0.0 through 3.2.0, with the fix in 3.2.1. By 3 October, The Register was reporting active exploitation, and canary telemetry cited in independent coverage put attacker activity at roughly a day after disclosure.

This briefing covers the bug chain, why the finder matters as much as the bug, and the second story that makes the timing ominous: the same week, a Cambridge professor watched exploit probes hit his live server minutes after he opened a fix pull request — the latest evidence that the disclosure embargo, the industry’s central pacing mechanism, no longer paces anything.

The chain: a signing key you can compute from the login page

HFS 3.x — a TypeScript rewrite of the Delphi-era 2.x line — is built on the Koa web framework, which signs session cookies via keygrip. When the COOKIE_SIGN_KEYS environment variable is unset, HFS falls back to generating a key with randomId(30), a helper built on Math.random(). In V8, Math.random() is xorshift128+: fast, non-cryptographic, and — the property that kills it here — reversible. Observe enough consecutive outputs and you can reconstruct the internal state, then step it backwards to anything the generator produced earlier, including the process-start outputs consumed by the signing key.

The part that elevates this from latent weakness to working exploit is the leak Mythos found in a second code path. The loginSrp1 handler stores a raw Math.random() value as a session sid, and because HFS sessions live in cookies rather than a server-side store — base64 JSON, signed but not encrypted — the client receives the exact 52-bit double in its own Set-Cookie. Reaching that endpoint requires only a valid login-enabled username, no password. So an unauthenticated attacker harvests consecutive generator outputs one login attempt at a time, feeds roughly a dozen into standard Z3/algebraic tooling to recover the xorshift128+ state, rewinds to the three outputs consumed by randomId(30) at startup, verifies each candidate key offline against the HMAC on their own legitimately issued cookie, and mints a session as admin — with the IP check neutralised by self-signing allow_session_ip_change into the forged session. From there, HFS’s administrative API permits custom endpoints that execute arbitrary JavaScript: authentication bypass in, code execution out. Hanley notes Mythos also turned up a user-enumeration oracle used to confirm the built-in admin account exists before the main chain runs.

Two details from the write-up deserve emphasis because they close off the usual dismissals. First, the code comment next to the key generation (“randomness at start gives some extra security”) confirms security intent, so the “Math.random() was never meant for security” defence does not apply. Second, the default admin_net restriction is empty, so no network scoping stands between a forged cookie and the admin API. NVD files the weakness as CWE-338 (weak PRNG), and the record — sourced from VulnCheck, currently Deferred status — references the v3.2.1 release tag and VulnCheck’s advisory as its fix pointers.

Why the finder matters: the exploit the humans would have skipped

Horizon3 is unusually candid about what would have happened without the model. The team writes that researchers who “rarely pursue weaponizing cryptographic flaws” would typically abandon this class of finding for two reasons: lack of mathematics expertise and time and economic viability. Mythos negated both. It identified the insecure PRNG and the disparate leak that made recovery feasible and the Z3-based route to weaponising it, then implemented the solver and demonstrated arbitrary command execution — unprompted, as a single chained result rather than three separate observations a human would need to connect.

That lands on top of a trendline this site has been tracking all year. Google Threat Intelligence Group’s 1 October report found that 50% of AI-discovered flaws lead to RCE against 26% of everything else, with monthly disclosures doubling across 2026. And the HFS case is not Mythos’s debut here — Anthropic’s Project Glasswing, which Horizon3 joined in July 2026 with an explicit mission to find flaws “likely to be found and exploited in the wild by threat actors at scale,” builds on the autonomous discovery work we covered in April. The through-line is uncomfortable for defenders: the bug classes that used to be self-limiting because exploiting them required rare math skills are becoming the preferred output of automated pipelines — on both sides.

There is precedent for taking HFS exposure seriously, too. The product previously appeared in CISA’s Known Exploited Vulnerabilities catalog for CVE-2024-23692, an unauthenticated template-injection RCE in the 2.x line. Internet-facing file servers with a prior KEV entry and a fresh unauthenticated 9.8 are exactly the population that gets swept within hours.

The embargo no longer paces anything

The second half of this briefing is not a CVE but a norm collapsing in real time. In an InfoQ report published 3 October, Cambridge computer science professor and OCaml maintainer Anil Madhavapeddy describes fixing a path-traversal vulnerability and noticing probes carrying the exact bug pattern in his live webserver logs minutes after opening the fix PR — before any advisory existed. His conclusion is blunt: “just one person searching for the issue class (this could be a mailing list question, an odd commit in an orphan branch, or a context leak) is sufficient to alert someone else’s agent and let them get exploit code.”

The supporting numbers are stark. InfoQ cites a recent study in which a GPT-4 agent exploited 87% of vulnerabilities in a 15-vulnerability benchmark when given CVE descriptions, versus 7% without them — the description alone is now most of the exploit. Chainguard’s Adrian Mouat spells out the maintainer’s dilemma: merely opening a fix PR puts users at risk with nothing they can do about it, which “may force projects to start publishing releases before the associated source code” — a direct break with open-source fundamentals. And rclone maintainer Nick Craig-Wood reports roughly 20 security disclosures in the project’s first ten years, versus more than 40 in the last month, triaged with AI assistance. The find-fix-disclose pipeline is being compressed from both ends simultaneously: models find more, and agents weaponise faster.

Read together with the HFS case, the lesson is that the patch window has shrunk below the coordination window. A 9.8 found by a model, disclosed with a working exploit chain, and swept by attackers within about a day leaves no room for staged rollouts — and Madhavapeddy’s minutes-scale PR-to-probe observation suggests even the pre-disclosure phase leaks. Madhavapeddy’s proposed responses — private vulnerability discussions, faster continuous releases, rapid protocol-level mitigations — are worth maintainer attention precisely because none of them assumes secrecy holds.

What to do with this now

  • Upgrade HFS to 3.2.1 or later immediately. Versions 3.0.0 through 3.2.0 are affected; the NVD record points at the v3.2.1 release tag as the fix. This is the one item here that is actionable today.
  • Do not expose HFS to the internet unpatched — and audit it if you did. The exploit is unauthenticated, the product has a prior KEV entry, and exploitation was reported within roughly a day of disclosure. Check for unexpected admin sessions, unfamiliar custom endpoints, and unexpected child processes of the HFS service.
  • Set COOKIE_SIGN_KEYS to a strong random value and scope admin_net. Per the disclosure, the vulnerable path triggers when the signing key falls back to generated randomness; an explicitly configured key from a cryptographic source removes the PRNG from the trust chain, and a non-empty admin_net restricts which networks can present admin sessions at all. Rotate any credentials and tokens that shared an environment with a potentially compromised instance.
  • Treat fix PRs as disclosure. If you maintain open-source software, assume scanners and agents diff your security-relevant commits within minutes — Madhavapeddy’s logs say so. Prefer private vulnerability discussion channels, ship the release alongside or ahead of the visible fix, and have the advisory text ready before the diff is public.
  • Budget for RCE-first triage on AI-surfaced findings. With half of AI-discovered flaws leading to remote code execution per GTIG, an AI-reported weakness with a plausible auth-bypass shape — like this one — should be triaged as a probable 9.x until proven otherwise, not as a hardening note.

Sources