VULNpocalypse
CriticalVulnerabilityPatch available

Rejetto HFS CVE-2026-61500: an AI-found bug attacked the day after its write-up

A predictable session key in HFS 3.0.0 to 3.2.0, found with Claude Mythos, lets attackers forge an admin login and run code. Update to 3.2.1 or later.

Published
Updated
Fixed in
HFS 3.2.1
Exploitation
Yes, probing seen by VulnCheck from 1 October 2026; not in CISA KEV as of 30 October

Live scores

CVE-2026-61500
EPSS
0.019
some chance of attack soon
VEDAS
0.056
little exploit evidence
On CISA KEV
Not listed
Detection rule
None yet
EPSS (chance of attack)
100.1CVE-2026-61500 EPSS over time2026-082026-11-01
VEDAS (exploit evidence)
100.9CVE-2026-61500 VEDAS over time2026-082026-11-01

Thin horizontal line: the “likely” (EPSS 0.10) or “strong” (VEDAS 0.90) threshold. Shaded “no data” areas are periods when cve-scores did not publish.

What happened

HFS (HTTP File Server) is an open-source file-sharing server, rewritten in TypeScript for version 3. In versions 3.0.0 to 3.2.0 it signs session cookies with a key derived from Math.random(), which is not cryptographically secure. The login process also hands raw outputs of that generator to unauthenticated clients. An attacker can rebuild the generator’s state, recover the signing key, forge an administrator session, and run code through the server_code feature. The flaw is rated CVSS v4 9.3 (GitHub advisory).

Zach Hanley of Horizon3.ai found it with Anthropic’s Claude Mythos model. HFS 3.2.1, released on 13 July 2026, fixed it and credited Hanley “working with Claude and Anthropic Research” (HFS release). The CVE was published the same day (GitHub advisory).

On 30 September, Horizon3 published the technical write-up. A cryptography-focused agent flagged the weak key, a second agent confirmed it, and Mythos wrote the proof of concept, including a Z3 solver that recovers the generator’s state from 12 samples (Horizon3.ai). A separate public proof of concept appeared in late September (The Hacker News).

Attacks started the next day. On the evening of 1 October, VulnCheck’s canaries saw an actor in China going after vulnerable hosts in the US and Japan. By Friday, 2 October, it had seen four hits from two US addresses that looked like proxies (The Register). VulnCheck described the activity as small-scale reconnaissance (The Hacker News). The CVE was not in CISA’s KEV catalog as of 30 October (CISA KEV). An older HFS flaw, CVE-2024-23692, has been in KEV since July 2024 and is marked as used in ransomware campaigns.

Am I affected?

You are affected if any HFS 3.x install is older than 3.2.1. From the command line:

bash
# Standalone binary or npm install: print the version
hfs --version

# Installed with npm
npm ls -g hfs

# Official Docker image: what is running, and which image digest
docker ps --filter ancestor=rejetto/hfs --format '{{.Names}} {{.Image}}'
docker image ls --digests rejetto/hfs

A container started from rejetto/hfs:latest before 13 July 2026 is still on the old code until you pull and recreate it. Also check Windows and Linux machines where someone downloaded the standalone binary; those do not show up in package managers.

What to do now

  1. Update to HFS 3.2.1 or later (3.3.4 is the latest on npm), then restart. Pull the new Docker image and recreate the container; pulling alone does not change a running container.
  2. Limit who can reach HFS. Put it behind a VPN, or a reverse proxy that allows only known users, or bind it to a private interface. Blocking only the Admin-panel at /~/admin/ is not enough, because the login and admin API calls go through /~/api/.
  3. Check for a takeover if HFS was exposed after 30 September. Look in the HFS configuration for admin accounts, plugins or custom server code you did not add. Change the admin password. If you find changes, treat the host as compromised and rebuild it.
  4. Set a real admin password on Docker installs. A new configuration created without a password variable gets an admin account with the password please-change (HFS wiki).
  5. If you write JavaScript, audit your randomness. Math.random() is fine for shuffling a list and wrong for anything secret. Use crypto.randomBytes() in Node.js or crypto.getRandomValues() in browsers for keys, tokens, session IDs and reset codes:
bash
grep -rn 'Math\.random' --include='*.js' --include='*.ts' src/

Why this is part of the Vulnpocalypse

This is the clean version of the story everyone has been waiting for: a bug found by a frontier AI model, then exploited in the wild. The detail that matters is the timing. The fix shipped on 13 July and nothing happened for 11 weeks. Attacks began one day after the write-up explained how the exploit works. The patch was not the trigger; the explanation was.

It is also one bug, not a wave. VulnCheck’s first-half 2026 analysis found that 14 of 1,061 vulnerabilities attributed to AI-assisted discovery (1.3%) were confirmed exploited in the wild. That is roughly the same rate as vulnerabilities overall, and VulnCheck concluded the data “does not suggest that AI discovered vulnerabilities are inherently more likely to be exploited” (VulnCheck; Security Boulevard).

So the risk from AI-found bugs is mostly volume, not special danger. More bugs get found, fixed and written up, and each write-up starts a short clock for anyone who has not updated. Teams that update when the fix ships, rather than when attacks are reported, stay ahead of that clock.

Sources