SURIQ
An AI model found this bug. Within about a day of a working exploit going public, someone started hunting for servers to point it at. That compression, from quiet research to opportunistic scanning, is the real story behind CVE-2026-61500, a critical flaw in Rejetto HFS, the small HTTP File Server that plenty of self-hosting operators leave facing the open internet. The flaw lets an unauthenticated attacker forge a valid administrator session and reach remote code execution. Rejetto patched it in July. The clock that matters for defenders did not start then.
What the flaw does
CVE-2026-61500 carries a CVSS score of 9.3. The root cause is a cryptographic shortcut: every affected build, 3.2.0 and the 3.0.x and 3.1.x lines before it, derives the signing key for its session cookies from Math.random(), a generator never meant for anything security-sensitive. A weak key alone is bad but fiddly to abuse. The real opening is a second code path that leaks outputs from that same generator to any unauthenticated visitor during login.
Put the two together and the secrecy collapses. An attacker gathers a handful of login responses, reconstructs the generator's internal state, recovers the signing key, and mints an administrator session cookie that HFS treats as genuine. From there the server's built-in scripting feature, the server_code configuration that runs arbitrary server-side JavaScript, turns that admin access into code execution on the host.
Who is exposed
If you run a public Rejetto HFS instance on 3.2.0 or any earlier 3.x build, treat it as reachable. The fix landed in 3.2.1 on July 13, 2026, and the current stable line is 3.3.4. Anything older than 3.2.1 is vulnerable; the attacker needs no account, no password, and no user interaction, only network access to the login page.
This is squarely a self-hosting problem. HFS is popular precisely because it is a single lightweight binary you can stand up in minutes, which is also why so many instances sit directly on the internet with no proxy or VPN in front. Authentication and account-takeover flaws are one of the classes we triage most, 1,248 of them crossed our desk in the last 90 days, so a no-login path to admin on an internet-facing box goes straight to the top of the queue. We flagged the same shape recently in a no-login GitLab session hijack, where self-hosted servers were again the exposed ones.
Patched in July, dangerous since September
The dates carry the point. Rejetto shipped 3.2.1 on July 13, 2026, the same day the CVE was published through the VulnCheck CNA. For eleven weeks very little happened. Then on September 30 Horizon3.ai published a technical breakdown, a public proof-of-concept followed, and VulnCheck's honeypots picked up probing within roughly 48 hours, so far, per VulnCheck, a single address on a China Telecom network testing deployments in Japan and the United States. VulnCheck has characterized the activity as small-scale reconnaissance, not confirmed mass compromise.
That gap is the lesson. "Patched in July" reads as settled; the knowledge needed to exploit it only became public at the end of September. A server you fixed months ago is fine. A server you have been meaning to get to has been on borrowed time since the proof-of-concept dropped, not since the summer.
Why an AI finding this matters
Horizon3 did not stumble onto this by hand. The team ran the HFS code through Anthropic's Mythos model as part of a research effort it calls Project Glasswing, and Horizon3's Zach Hanley is credited with the discovery. What the model did is the part worth sitting with. It did not merely flag the weak random-number generator in isolation. It also located the separate leak path, recognized that the two together were exploitable, and suggested a constraint solver to handle the state-recovery math.
That is the shift. A weak generator feeding a signing key is the kind of flaw a human reviewer might note and move past as too much work to weaponize. Tying it to a second, unrelated-looking code path is exactly the multi-step reasoning that used to keep bugs like this theoretical. When that reasoning gets cheap and automatic, the set of flaws that become working exploits grows, and it grows on the software you run as readily as on anyone else's. We saw the defensive side of the same trend when BeyondTrust's own AI surfaced pre-auth bypasses in its appliances before attackers did.
How you would know you were hit
Here is the operational catch: this attack forges a session rather than logging in, so your authentication logs stay clean. There is no failed-password burst and no new admin login to alert on. The privileged actions simply appear, attached to a session nobody ever signed into.
Hunt for that mismatch instead of a login event. Pair each technique with the trace it leaves on the affected host.
T1190 Exploit Public-Facing App Burst of requests to the HFS login endpoint from one source, with no successful auth, harvesting Math.random() output. T1606 Forge Web Credentials Admin actions (config changes, file ops) in a session that has no matching successful login event. T1059.007 Scripting: server-side JavaScript New or edited server_code / script config, and the HFS process spawning cmd or sh children it never normally does.
If HFS sits behind a reverse proxy, the harvesting step shows up there too: a run of requests to the login path from one address, none of them authenticating. A managed detection setup watching for privileged actions with no matching login, and for the HFS process spawning shells, is the difference between catching this in the reconnaissance window and reading about it in an incident report. We have watched the same forged-credential pattern play out in CoreWCF's SAML handling and in a JFrog Artifactory admin-token forgery, both of which attackers reached without a password.
Upgrade to 3.3.4, then hunt for logins that never happened
Patch first. Move any instance at 3.2.0 or below up to 3.3.4, the current stable release. 3.2.1 closes this specific hole, but there is no reason to stop short of the newest build. If you cannot patch right away, take the server off the public internet, put it behind a VPN or an authenticated proxy, and disable the server_code scripting feature so a forged session has nowhere to go even if it is minted.
Then look back. Because the fix is months old, the easy assumption is that this one is handled, and that assumption is exactly what the scanning is counting on. Check the sessions, not just the version number.