Attackers Are Exploiting a Rejetto HFS Flaw Found With Anthropic Mythos, 11 Weeks After the Patch

VulnCheck says it began detecting exploitation of CVE-2026-61500 on the evening of Thursday, October 1. The flaw is a critical authentication bypass in Rejetto HFS, an open source web file server: an unauthenticated attacker can forge an administrator session cookie and then run code on the server. Horizon3.ai researcher Zach Hanley found it with help from Anthropic’s Mythos model, and VulnCheck researcher Patrick Garrity called it “the second Mythos finding to get reported as exploited in the wild.”

The patch is not new. HFS 3.2.1 shipped on July 13, 80 days before the first sighting, and the NVD record and VulnCheck’s advisory carry the same date. What changed in the past week is that the details went public: a third-party proof-of-concept repository appeared on September 26, and Horizon3 published its write-up on September 30.

What VulnCheck saw

Garrity’s LinkedIn post said “our canaries detected an actor in China targeting real vulnerable hosts in the US.” Canaries are VulnCheck’s own sensors (the company sells a Canary Intelligence product), so these are sightings on its monitoring network. None of the sources we read reports a confirmed compromise of a production HFS server. The Register, which spoke to Garrity, said the first activity came from one IP address in China and targeted vulnerable servers in the US and Japan. On Friday he told the outlet “Today we have seen four hits,” this time from two US addresses in the same subnet, 173.239.211[.]248 and 173.239.211[.]249, which “appear to be coming from a proxy.”

VulnCheck’s advisory says the CVE is in its own KEV catalog. CISA’s Known Exploited Vulnerabilities feed (catalog version 2026.10.02) did not list it when we checked on October 3. HFS has two earlier entries there: CVE-2024-23692, added July 9, 2024, and CVE-2014-6287, added in 2022. The NVD record was published July 13 and still shows a “Deferred” status. It carries VulnCheck’s scores, CVSS 3.1 9.8 and CVSS 4.0 9.3, and the weakness CWE-338, use of a cryptographically weak pseudo-random number generator.

How the chain works

Per NVD, HFS 3.0.0 through 3.2.0 “derives its session-cookie signing key from the non-cryptographic Math.random() generator and discloses outputs of the same generator to unauthenticated clients during login.” We read the vulnerable v3.2.0 source on GitHub, and it matches. When the COOKIE_SIGN_KEYS environment variable is unset, the cookie key is randomId(30), which makes three Math.random() calls at startup (index.ts, cross.ts). The first step of the login handshake sets const sid = Math.random() and keeps it in a session cookie (api.auth.ts). Horizon3’s write-up quotes the model’s analysis describing that cookie as base64-encoded JSON that is signed but not encrypted, so the client can read the value back.

Horizon3’s write-up lists the attack as a short sequence: confirm the admin account exists with a user-enumeration oracle, sample the leaking endpoint 12 times, feed the outputs to the Z3 solver to recover the generator state, step the state backward to the key generated at startup, forge an admin cookie, then use built-in functionality to run code. The public proof of concept, which says it works over HTTP alone, uses six requests and five consecutive values. The built-in functionality is the server_code option, which HFS’s configuration docs describe as “javascript code that works similarly to a plugin.”

The fix is small. Commit 59472e5, dated July 10, swaps the signing key for 32 bytes from Node’s randomBytes() and the handshake value for randomUUID():

// src/index.ts, v3.2.0 (vulnerable)
    || [randomId(30)] // randomness at start gives some extra security, btu also invalidates existing sessions

// src/index.ts, v3.2.1 (fixed)
    || [randomBytes(32).toString('base64url')] // cookie signatures need randomness that cannot be reconstructed from observable Math.random() output

// src/api.auth.ts, v3.2.0 (vulnerable)
            const sid = Math.random()

// src/api.auth.ts, v3.2.1 (fixed)
            const sid = randomUUID()

The same release fixed five more CVEs (CVE-2026-61501 through CVE-2026-61505, per the commit messages) and made the login handler answer unknown usernames the way it answers wrong passwords. The release notes list no CVE numbers. They say only “Multiple security vulnerabilities have been found in all previous versions, potentially allowing an attacker to gain administrative access to HFS.” They also thank Hanley “in collaboration with Claude and Anthropic Research.”

Timeline

What is new, and what is not

The weakness itself is old. When V8 moved to xorshift128+ in 2015, its team warned that “even though xorshift128+ is a huge improvement over MWC1616, it is still not cryptographically secure.” MDN says Math.random() “does not provide cryptographically secure random numbers” and should not be used for “anything related to security.” Public tools for recovering V8’s generator state also predate this bug by years. TACIXAT’s XorShift128Plus repository, created in 2016, is described as symbolic execution for the algorithm, and StroppaFR’s mathrandomcrack, created in 2024, as “Cracking V8 Math.random() from arbitrary bit leaks.”

What Horizon3 says is new is the model’s role. Its post says Mythos spotted the weak generator, found a separate path that leaks its raw outputs, treated the two as a chain, wrote the Z3 model and produced a working exploit, and “did not require follow-on prompting” to find the leak. “In practice, we do not recall ever seeing an SMT solver being used to attack a cryptographic flaw like this in a real application,” Horizon3 wrote. Horizon3 sells an autonomous pentesting product and its post ends with a demo pitch, so the capability claims are the vendor’s own. The mechanism, though, checks out against the HFS source. We did not run the public exploit code. Horizon3 joined Project Glasswing, Anthropic’s program that gives select partners access to Mythos, in July. Our checklist for AI vulnerability harnesses covers how teams wire such models into a pipeline, and our report on offensive-security researchers and vetted-access programs covers who gets them.

The base rate is a useful check on the headline. Garrity’s tracker lists CVEs that credit Anthropic’s research team, including some from before Project Glasswing was announced. The Register put the count at 286 as of Friday, up from 225 in its September 21 report, and said only one had been exploited until Thursday. That September 21 report named the one exploited then: a critical SQL injection in Ghost, CVE-2026-26980. Two of 286 is 0.7 percent, under the low end of the “just under one percent to two percent” of vulnerabilities that Garrity says historically get weaponized. That arithmetic is ours, and the tracker’s README showed 300 on Saturday, so the share will move. Garrity’s September verdict was that Anthropic’s disclosures aren’t “resulting in different outcomes from a threat perspective than a random selection of other vulnerabilities would.”

Our reading is that the dates point at the public exploit material rather than the model. The release notes have credited Hanley “in collaboration with Claude and Anthropic Research” since July 13, yet VulnCheck’s sensors started seeing exploitation only a day after Horizon3’s write-up and five days after a public exploit repository appeared. No source says which of those, if either, the attacker used, so the timing is a pattern and not proof.

What to do

• Upgrade. Move to HFS 3.2.1 or later, and prefer the current release. The 3.3.4 release from September 30 lists more fixes: “Security fixes, thanks to @Motan1337 for reporting all of them.”
• Restrict the admin panel. The admin_net option is documented as a net-mask for the addresses allowed to reach the admin panel, and the default is any address. In the v3.2.0 source, the admin check rejects clients outside that range before it looks at the session’s account.
• Set a signing key where you cannot upgrade yet. The proof-of-concept’s README says an explicit strong COOKIE_SIGN_KEYS value mitigates signing-key prediction, but that “upgrading remains the recommended remediation.”
• Look for leftovers. If a 3.0.0 to 3.2.0 server was reachable from the internet, review its server_code setting, its plugin list and its admin logins for anything you did not create, since that is how the chain reaches code execution. That check is our suggestion, drawn from the NVD description.