CVE-2026-61500: Attackers Exploit Rejetto HFS Session Forgery RCE—Upgrade to 3.2.1

The fix is simple. The problem is fixed in release 3.2.1 and later. The timeline is the part that should worry HFS admins: the patch has been out for months, and attackers showed up within about a day of the detailed write-up.

The short version​

• CVE: CVE-2026-61500, "Rejetto HFS < 3.2.1 Session Forgery via Predictable Signing Key"
• Affected: HFS 3.0.0 through 3.2.0, the TypeScript/Node.js rewrite
• Fixed: HFS 3.2.1 and later
• Severity: VulnCheck, the CVE numbering authority, rates it CVSS 3.1 9.8 and CVSS 4.0 9.3, both Critical. It needs no credentials and no user interaction.
• Weakness class: CWE-338, use of a cryptographically weak pseudo-random number generator
• Exploitation: VulnCheck says its Canary Intelligence honeypots began seeing exploitation on October 1, 2026, and it has added the CVE to the VulnCheck KEV catalog.

If you run HFS 3.x anywhere reachable from the internet, upgrade now. The explanation can wait.

A timeline that shows how small the window is​

This was not a zero-day that caught everyone off guard. The patch existed long before the attacks, and that may matter more than the AI angle.

The third-party proof-of-concept says its build is limited to local loopback targets. Its README states that it confirmed "Recover V8 xorshift128+ state from unauthenticated login responses" against official HFS 3.2.0 and that the attack stops before session forgery on official HFS 3.2.1. That independent check is useful. Someone outside Horizon3 reproduced the chain, and the 3.2.1 fix holds against it.

Some vulnerability databases still score the bug using older data. EPSS-based scores were built when nobody had seen exploitation, so a low "probability of exploitation" figure is out of date now. CISA's Vulnrichment field also still showed "none" as of its July entry. Don't let either one push this down your patch queue.

Who saw the attacks, and from where​

VulnCheck researcher Patrick Garrity, who also assigned the CVE after Hanley's team reported it, posted on LinkedIn on Thursday that his company's canaries had caught exploitation. According to The Register, Garrity said the first activity came from a single IP address in China and targeted vulnerable hosts in the US and Japan. On Friday he told the publication he had seen four more hits from two US addresses, 173.239.211[.]248 and 173.239.211[.]249. Both sit in the same subnet, and Garrity said they appear to be coming from a proxy.

Read those indicators carefully. Proxy infrastructure is standard tradecraft, so a US source address tells you nothing reliable about who is running the operation. The Register noted that an April advisory from 10 countries warned that China-nexus operators use proxy networks at scale. The IPs are fine for blocking and log searches. They don't support attribution claims.

VulnCheck's weekly Initial Access report puts the exposure in perspective: its Target Intelligence finds roughly 100 internet-facing HFS instances. That's small next to the tens of thousands of NetScaler boxes in the same report. Still, the attackers seem to be looking for whatever HFS servers they can find, and an HFS box is often a home lab, a small office share or a forgotten file drop that nobody watches.

Section summary: Exploitation is confirmed by VulnCheck's own telemetry. Geographic attribution is reported but unproven. The exposed population is small and probably poorly monitored.

How the attack works​

This is where Mythos and the math come in. Here's the chain in plain terms, based on Horizon3's account.

1. The signing key comes from a weak generator. HFS 3.x runs on Node.js and uses the Koa web framework. Koa signs session cookies with keygrip. Horizon3 says that when no explicit signing key is configured, which it says is the default, HFS builds the key at startup from three consecutive Math.random() outputs.
2. That generator is not cryptographic. In V8, the JavaScript engine inside Node.js, Math.random() uses xorshift128+. It's fast and fine for shuffling a playlist, but its internal state is two 64-bit integers and its operations can be reversed. With enough consecutive outputs you can rebuild the state and step it backwards.
3. HFS leaked values from the same generator. The proof-of-concept README explains that HFS exposed outputs from the same V8 PRNG in the unauthenticated SRP login handshake. The login code put a full-precision Math.random() value into the session, and because the session cookie is signed but not encrypted, a client could decode its own cookie and read the number. Horizon3 says this only requires a valid login-enabled username, not a password. The built-in admin account works.
4. The solver finishes the job. Fed those leaked values as constraints, Microsoft's open-source Z3 solver recovers the generator's state. The state is then stepped back to the startup outputs that formed the signing key. The attacker can check each candidate key offline against the HMAC on their own legitimately issued cookie, so the server never sees a guess.
5. From key to code execution. With the key in hand, the attacker signs a cookie claiming to be admin. Horizon3 says the forged session can also include a flag that defeats HFS's session IP binding. Admin access opens the server_code feature, which runs server-side JavaScript, and that completes the path to remote code execution.

Horizon3's demo sampled the leaky endpoint 12 times. The independent PoC says it sends six unauthenticated loginSrp1 API requests for the known admin account. Either way, the attack takes a handful of requests, not a brute-force flood. That matters for detection, which comes up below.

Section summary: Neither the predictable key nor the leaked random values is catastrophic alone. Together, plus a constraint solver, they hand an unauthenticated attacker full admin rights.

Where Microsoft fits in, and where it doesn't​

Microsoft Research built Z3, and it's widely used for program verification and analysis. Here it's the attacker's tool, not the cause of the problem. Z3 solves whatever constraints it's given. The flaw is in HFS's design choices, not in Z3, and not in Windows either.

There is a Windows angle all the same. HFS has long been popular with Windows users who want to share a folder over HTTP without setting up IIS. The project's documentation says the current 3.x line needs Windows 10 or Windows Server 2019 at minimum. It also runs on Linux, macOS, FreeBSD and Android. If someone in your organization ran an HFS binary on a desktop "just for a minute" two years ago, now is a good time to find it.

What Horizon3 says Mythos actually did, and how far to trust it​

Project Glasswing is Anthropic's program giving selected partners access to Mythos, which Anthropic says is too capable to release publicly. Horizon3 says it joined in July and has used Mythos in its research pipeline since. According to Horizon3, the work runs through a custom harness that launches specialized agents in parallel, one per vulnerability class. Its cryptographic-weakness agent, driven by Mythos, flagged the problem, and a separate verification agent re-checked the code and confirmed it as a true positive.

Hanley's main claim is that the model found the weak generator, found the separate leak, and saw that the leak supplied exactly the observations needed for state recovery. Horizon3 also says Mythos suggested Z3, implemented the solver constraints and built a working exploit. Hanley admits his team would probably have reached for brute force first, and that they don't recall seeing an SMT solver used this way against a real application to get an authentication bypass. He also points out that his team has seen insecure crypto many times before and usually dropped it, citing a lack of mathematics expertise and the time weaponization takes.

That's an interesting account, but keep some caveats in mind:

• It's the vendor's own story. Horizon3 sells AI-driven penetration testing, and the write-up is its account of its own process. Nobody has published an independent benchmark of Mythos's math ability.
• The harness mattered. Horizon3 used purpose-built agents and a verification step, not a bare chat window. The CVE credit reads Zach Hanley of Horizon3.ai, in collaboration with Claude and Anthropic Research (per the CVE record), which reflects a team effort.
• One bug isn't a trend line. Per the tracker Garrity keeps, Mythos and Glasswing have produced 286 CVEs, and until this week only one of them was known to be exploited. Most AI-found bugs have not been used in attacks.

The more useful point is Horizon3's prediction that cheap automation will change which bug classes attackers bother with. Weak-randomness findings used to be filed as "theoretical, low priority." If a model can turn one into a working exploit in an afternoon, that triage habit needs to change, for defenders as well as attackers.

Not the only HFS problem right now​

Two related items are worth knowing about:

• CVE-2026-61501, also patched in 3.2.1. Rejetto HFS 3.0.0 through 3.2.0 renders log entries in the administration panel as HTML without sanitization. It's rated medium, and it's one reason The Register says 3.2.1 fixes "this and other" flaws.
• The old HFS 2.x line is still dangerous. CVE-2024-23692, the template-injection bug that put HFS on CISA's KEV list in 2024, affected 2.x. VulnCheck's latest report adds CVE-2026-97359, another unauthenticated RCE in the same 2.x macro engine. VulnCheck says the affected line has no vendor fix and no in-the-wild exploitation reported yet. CVE-2026-61500 doesn't affect 2.x because that line is an entirely different Delphi codebase. That's not good news: it means 2.x has its own unpatched problem.

What to do now​

1. Inventory. Look for HFS on Windows desktops, servers, NAS boxes and containers. Pay most attention to anything reachable from the internet.
2. Upgrade 3.x to 3.2.1 or later. That's the fixed release named in the CVE record, and the independent PoC confirms the attack fails against it.
3. Retire 2.x. VulnCheck says the 2.x line has no fix for CVE-2026-97359. Move to a current 3.x release or take it offline.
4. Shrink exposure. If HFS doesn't need to face the internet, put it behind a VPN or firewall rule. The project README also notes that loginSrp1 must be invoked for an existing username, and the default admin account is the obvious target.
5. Assume compromise if you were exposed and unpatched. The following is general incident-response practice, not vendor guidance. Review HFS's server_code configuration, accounts and plugins for anything you didn't add. Check logs for bursts of unauthenticated login-handshake requests followed by admin activity, and for the two IPs VulnCheck shared. A successful attacker gets code execution as the HFS process account, so if you find evidence of compromise, rebuild the host rather than just patching it.
6. Watch for localhost shortcuts. The HFS README says that by default the Admin panel doesn't require a login from localhost, and you can turn that off with the console command config localhost_admin false. It isn't part of this bug, but it's a sensible hardening step.

Bottom line​

CVE-2026-61500 gets a lot of attention because of the AI story, but the lesson for admins is familiar: a fix for a critical, automatable bug sat available from July while exposed servers stayed unpatched, and attackers moved within about a day of a detailed public write-up. Whether Mythos is a mathematical genius or a well-harnessed, very fast intern, the fix is the same: upgrade to 3.2.1 or later.