Mythos Cracked Rejetto HFS Sessions From 12 Leaked Math.random() Values

Horizon3.ai has published how Anthropic's Mythos model found a critical flaw in Rejetto HFS, the open-source file-sharing server, and then wrote the exploit for it. The bug, CVE-2026-61500, lets an unauthenticated attacker forge an administrator session cookie and run code on the server. It affects HFS 3.0.0 through 3.2.0 and is fixed in 3.2.1, released on 13 July 2026.

The flaw itself is old-fashioned: HFS signs its session cookies with a key built from JavaScript's Math.random(), and it hands out raw outputs of that same generator to anyone who starts a login. What is new is who found it. Horizon3 researcher Zach Hanley says the bug came out of a harness that runs Mythos as many specialised agents in parallel, one of them dedicated to cryptographic weaknesses. Horizon3 joined Anthropic's Project Glasswing in July 2026, and published the write-up on 30 September.

Who is affected

The VulnCheck advisory credits Zach Hanley of Horizon3.ai "alongside Claude and Anthropic Research". The HFS 3.2.1 release notes say that "multiple security vulnerabilities have been found in all previous versions, potentially allowing an attacker to gain administrative access to HFS". Horizon3 says Mythos also reported a user-enumeration bug, which the exploit uses as its first step.

The fix came first: HFS 3.2.1 shipped 79 days before Horizon3 described how Mythos found the bug.

HFS has been a target before. CVE-2024-23692, a template-injection flaw in the older HFS 2.3m, was added to CISA's Known Exploited Vulnerabilities catalogue in July 2024. HFS 3.x is a separate codebase, and nothing in the advisories suggests CVE-2026-61500 is being exploited.

How the attack works

Math.random() in V8, the JavaScript engine under Node.js, is the xorshift128+ generator. It is fast, it is not cryptographic, and its internal state can be recovered from a handful of outputs. HFS made two mistakes with it:

• When the administrator has not set COOKIE_SIGN_KEYS, the key that signs session cookies is randomId(30), built from Math.random() when the server starts.
• During login, the unauthenticated loginSrp1 step sets a session id that is a raw Math.random() value. In Mythos's words, the server returns "the exact 52-bit double in its own Set-Cookie".

Horizon3's write-up lays the chain out in six steps:

1. Enumerate users to confirm an administrator account exists.
2. Start the login 12 times and collect the 12 leaked Math.random() values.
3. Feed them to the Z3 SMT solver, which recovers the xorshift128+ internal state.
4. Step the generator backwards to the values it produced at startup, and rebuild the cookie signing key.
5. Sign a forged administrator session cookie with that key.
6. Use the admin API, which "allows for custom endpoints that can execute arbitrary JavaScript", to run commands on the host.

Horizon3's six-step chain, from 12 leaked login values to code execution through the admin API.

Mythos did not stop at the finding. According to Horizon3, it "created the working proof of concept exploit, putting all the pieces together, fully implemented the Z3 solver with the given constraints, and then demonstrated it working to execute an arbitrary command."

Why this bug went unfound

Hanley's argument is about economics rather than difficulty. He names two reasons human researchers skip bugs like this: a lack of mathematics expertise, and "time and economic viability", since bugs that take a long time to understand and weaponise are not prioritised. His conclusion is that "Mythos negates both of those reasons." A PRNG state-recovery attack is textbook cryptanalysis with public tooling, and Mythos's own notes call it a "standard publicly-tooled Z3/algebraic attack from ~3–5 consecutive doubles".

That matters beyond HFS. Many JavaScript projects still reach for Math.random() to make ids, tokens and keys. A model that can spot the pattern, check whether the outputs leak, and write the solver turns a class of bugs that used to be too slow to chase into something a harness can sweep for. Horizon3 still sees a role for the researcher in choosing which projects deserve a dedicated harness, and in noticing when a flaw sits in a shared library rather than one product.

What defenders should do

• Upgrade HFS to 3.2.1 or later. Every 3.x release from 3.0.0 to 3.2.0 is affected.
• Set COOKIE_SIGN_KEYS to a long random secret, so the signing key does not come from Math.random() at all.
• Restart after upgrading, and rotate the key if you set one by hand. A new signing key invalidates any cookie forged against the old one.
• Do not expose the HFS admin interface to the internet. The final step needs the admin API; restricting it to a trusted network or VPN breaks the chain even if a cookie is forged.
• Review admin-defined custom endpoints and server code on exposed instances for anything you did not add.
• Audit your own code for Math.random() in security roles. Session ids, reset tokens, API keys and signing keys belong to crypto.randomBytes() or crypto.randomUUID().

Sources

• Horizon3.ai: Anthropic Mythos finds Rejetto HFS RCE (30 September 2026)
• NVD: CVE-2026-61500
• VulnCheck advisory: Rejetto HFS session forgery via predictable signing key
• Rejetto HFS v3.2.1 release notes
• SentinelOne: CVE-2024-23692 in Rejetto HTTP File Server