An AI Model Found a File-Server Flaw by Reversing a Random-Number Generator. The Exploit Clock Started at the Write-Up, Not the Patch

CVE-2026-61500 is a critical authentication bypass in Rejetto HTTP File Server (HFS), a small open-source tool people use to share files from their own machines. It affects HFS 3.0.0 through 3.2.0 and was fixed in 3.2.1, which has been available since July 2026. eSecurityPlanet, summarising VulnCheck's advisory, reports a CVSS 4.0 score of 9.3. The flaw became news in October for two reasons: the security firm Horizon3 says it was found with Anthropic's Mythos model, and VulnCheck's honeypots saw probing for it within a day of Horizon3 publishing its write-up. Both facts are real, but the second is easy to misread, and the dates matter more than the headline suggests.

What HFS got wrong

According to the NVD description quoted by BleepingComputer, HFS 3.0.0 through 3.2.0 derived the key that signs its session cookies from JavaScript's Math.random(), a non-cryptographic generator, and separately disclosed outputs of that same generator to unauthenticated clients during login. A signed cookie works like a stamped ticket: the server trusts any cookie whose signature matches its secret key. Anyone who can reconstruct the key can print their own ticket and claim to be the administrator. From there, BleepingComputer reports, HFS's server_code configuration feature runs custom server-side JavaScript, which turns administrator access into remote code execution. The chain is: collect a few login responses, rebuild the generator's internal state, recompute the signing key, forge an admin cookie, run code.

Why a random number can be solved like an equation

Math.random() is built for speed and statistical spread, not secrecy. In V8, the engine behind Chrome and Node.js, it uses an algorithm called xorshift128+, according to The Register's account of Horizon3's write-up. The generator holds 128 bits of internal state and updates it with bit shifts and XOR operations, which are linear when you treat each bit as a variable. The number it returns is assembled from bits of that state. Every output an attacker observes is therefore a set of equations about the hidden state. A cryptographic generator is designed so that outputs reveal nothing about its state; xorshift128+ makes no such promise.

An SMT solver such as Z3 takes constraints on bit-vectors and searches for values that satisfy them. Feed it the update rule plus observed outputs, ask for the starting state, and it can return one. The Register reports that Horizon3's analysis said Z3 could recover the generator's seed. SecurityWeek and The Hacker News describe the generator as reversible without naming Z3, so the solver detail rests on one outlet's relay of the discovering firm's own account. As a rough sizing (a DrafterDaily calculation, not a figure from any source), a double carries about 52 bits of mantissa, so three observed values supply 156 bits of constraints against a 128-bit state. In practice attackers collect more outputs to tolerate noise, but the order of magnitude explains why a handful of login responses can be enough.

This is the practical difference between a lint warning and an exploit. Static analysers routinely flag Math.random() in security contexts, and teams routinely dismiss the warning because a flagged call is not an attack by itself. Severity depends on whether the generator's outputs ever reach an attacker. Here a different code path leaked them. Horizon3 says Mythos did not just flag the insecure generator in isolation; it also identified that separate leak, which is the combination that made the bug exploitable.

What the model contributed, and what one case cannot show

Horizon3 researcher Zach Hanley used Mythos to find the flaw. The Register says Horizon3 joined Anthropic's Project Glasswing in July; SecurityWeek says the flaw was found in June, and the CVE was published on 13 July. Those dates do not obviously fit together and we could not resolve them from the sources read, so we do not state when the discovery happened. Hanley told The Register he could not recall seeing an SMT solver used this way against a cryptographic flaw in a real application. That is a claim about novelty from the person who did the work, and it is the best evidence on the table for the model adding something beyond a faster code read.

It is still one case. The account of how the bug was found comes from Horizon3, a security firm that benefits from the attention. Anthropic's statement that Mythos is too powerful for general release is, as The Register frames it, Anthropic's own claim. The Register also cites a tracker kept by VulnCheck's Patrick Garrity that counted 286 CVEs attributed to Mythos and Project Glasswing as of 2 October; that is a single third-party tally, not an official count, and the same report says only one of them had been exploited in the wild before this one. What none of the sources establish is a counterfactual: whether an experienced human auditor who knows xorshift128+ attacks would have found the same chain in the same time, how many Mythos attempts on other targets produced nothing, or what the run cost. The sceptical reading is that this is ordinary vulnerability research, done faster. The evidence cannot rule that out, and it cannot rule out the stronger reading either.

The clock: 79 days of quiet, then about one day

The timeline has four dates. The CVE was published on 13 July 2026, with a fixed release, 3.2.1, available. Horizon3 published its write-up and a proof-of-concept exploit on 30 September, per BleepingComputer and The Hacker News, which also reports a separate public Python exploit by Alejandro Ramos in late September. VulnCheck's Canary Intelligence honeypots recorded probing from 1 October: one China Telecom address aimed at decoy deployments in Japan and the United States. The Register adds that on 2 October four hits arrived from two US addresses in the same subnet that VulnCheck's Garrity said appeared to be a proxy.

Counting from 13 July to 30 September gives 79 days (our arithmetic). The widely repeated line that the flaw was exploited within a day of disclosure conflates two events. The patch was public 79 days before the details were. The probing began about a day after the write-up and exploit code appeared. For any administrator who updated during those 79 days, the later activity was irrelevant.

The observed activity also needs its proper weight. VulnCheck described it as small-scale reconnaissance, BleepingComputer says VulnCheck had not reported successful exploitation or post-exploitation behaviour, and the actor is unattributed: a single address, then apparent proxies. Honeypots are decoys, so a hit on one shows that someone is looking, not that a real server was compromised. VulnCheck identified roughly 100 internet-facing HFS instances (eSecurityPlanet), which is a small population. The headline risk is to the few people running an exposed, unpatched 3.x server.

What changes for patch deadlines

The durable lesson is about what a public write-up now contains. A working exploit and a video of the exploitation steps (The Register notes Hanley published one) mean the cost of going from knowing a bug exists to attacking it fell to roughly copying instructions. Small self-hosted tools make this worse. HFS has no security team sending advisories and no automatic update channel for most installs, so the people most exposed are the least likely to hear about the fix. For an internet-facing authentication bypass with public exploit code, a patch deadline measured in weeks does not describe the real risk; hours to days does.

The remediation steps are unglamorous. Per eSecurityPlanet: upgrade from 3.0.0 to 3.2.0 to 3.2.1 or later (3.3.4 was the latest stable release as of 6 October), confirm the updated build is the one actually running, restrict internet exposure where public access is not needed, and review logs for unusual authentication, configuration changes and edits to server_code. If an immediate upgrade is impossible, setting a strong explicit COOKIE_SIGN_KEYS value is listed as a stopgap, which makes sense mechanically because it removes the dependence on Math.random() for the key. Upgrading remains the primary fix. HFS 2.x is end-of-life and not affected by this flaw, though it has other problems and a history: CVE-2024-23692 in that line was added to CISA's catalogue in July 2024, and eSecurityPlanet notes that older campaign says little about what attackers are doing with this one.

There is a second-order effect worth watching, and it is our reasoning rather than a reported fact. If model-assisted auditing makes the pairing of a weak generator and a separate leak cheap to find across many codebases, then the supply of such reports rises, and quietly fixed bugs become less quiet, because a published patch is a map to the bug for anyone who diffs it. The same pressure is showing up on the receiving end of bug reports; DrafterDaily's piece on Google pausing product-vulnerability submissions to its open-source reward programme covers that side.

Three things would change this assessment: reports of confirmed compromise rather than probing, an entry in CISA's Known Exploited Vulnerabilities catalogue (the sources read mention VulnCheck's own database only), and independent replication of how Mythos found the chain.