Vulnerabilities

Rejetto HFS flaw found by AI, exploited within a day

By Yaali. October 6, 2026, 6 min read, Vulnerabilities, Patching, Threat intel.

CVE-2026-61500 lets anyone forge an HFS admin cookie from a predictable key and run code. Exploitation began a day after the write-up. Fix: 3.2.1.

Rejetto HTTP File Server (HFS) versions 3.0.0 to 3.2.0 sign their session cookies with a key built from JavaScript's Math.random(), and the login step hands outputs of that same generator to any client that connects. That combination lets an unauthenticated attacker rebuild the signing key, forge an administrator session cookie and then run their own code through HFS's server_code setting. The flaw is CVE-2026-61500, rated 9.3 under CVSS 4.0 by VulnCheck, which assigned the CVE, and 9.8 under the older CVSS 3.1 scale.

The fix, HFS 3.2.1, shipped on July 13. The details only went public on September 30, when Horizon3.ai's Zach Hanley published a write-up showing how Anthropic's Mythos model found the bug. VulnCheck's honeypots caught the first exploitation attempt within about a day. If you run HFS 3.x anywhere reachable from the internet, a home-office file share or a quick file-drop box included, check the version today.

How it works

HFS 3 is a Node.js application built on the Koa web framework. Koa signs its session cookies with an HMAC (a keyed hash) stored in a companion cookie named hfs_http.sig; the session cookie itself is base64-encoded JSON, signed but not encrypted. Whoever holds the signing key can produce a cookie that names the admin account and have the server accept it. In the affected versions that key is derived at startup by a helper called randomId(30), which draws its randomness from Math.random().

Math.random() is built for shuffling a list, not for keys. In V8, the JavaScript engine inside Node.js, it runs an algorithm called xorshift128+ whose internal state is recoverable from a small run of its outputs and can then be stepped backwards. On its own that is a theoretical weakness, because an outside attacker never normally sees those outputs. The problem is a second code path that leaks them: the first step of HFS's Secure Remote Password (SRP) login stores a fresh Math.random() value in the session, and since the cookie is readable JSON, the raw number is handed back to the client. No valid password is needed to reach it.

With enough of those leaked values an attacker can reconstruct the generator's state, wind it back to the point where the signing key was created, and confirm the recovered key against the HMAC on a cookie the server legitimately issued them. Horizon3 used Z3, a well-known constraint solver from Microsoft Research, to do the state recovery. From there the attacker mints a cookie that says admin, and the admin panel treats them as logged in. The last step is HFS's own server_code configuration option, which runs operator-supplied JavaScript in the server process in the same way a plugin does. An attacker who controls the admin session can write code into that setting and the host executes it, with the privileges of the HFS process.

Why this one is worth noticing

Mythos is the model Horizon3 has been running under Project Glasswing since July 2026. According to Hanley, it flagged the weak generator and, without follow-up prompting, recognised that a separate endpoint leaked the raw Math.random() outputs, which are exactly what a state-recovery attack needs.

The timing matters for defenders. The patch had been out since July, but exploitation did not begin on patch day. It began the day after the mechanism was described in public, which is the pattern to plan for.

What attackers are doing

VulnCheck's Patrick Garrity reported that the firm's Canary Intelligence honeypots recorded the first exploitation attempt on October 2, 2026, a day after Horizon3's write-up. The early activity came from an IP address in China targeting real vulnerable hosts in the United States and Japan, and VulnCheck saw further hits over the next 48 hours routed through United States proxies (173.239.211.248 and 173.239.211.249). The volume so far is small and looks like reconnaissance rather than a mass campaign. A public proof-of-concept and a Docker test lab are already on GitHub, so wider scanning should be expected.

HFS has history here. CVE-2024-23692, a template-injection flaw in the older 2.3m line, was mass-exploited through 2024 to drop cryptocurrency miners and other malware, and it still sits in CISA's Known Exploited Vulnerabilities catalog. Internet-exposed HFS boxes are a known target, and this new flaw hands over the admin panel and code execution in one move.

What to do

1. Upgrade

Update to HFS 3.2.1 or later; the current 3.3.x builds are the better target if nothing you depend on breaks. The fix replaces the cookie signing key with 32 bytes from Node.js randomBytes(), a cryptographically secure source, and swaps the leaked numeric login identifier for randomUUID(), so the generator's output no longer reaches clients. Only versions 3.0.0 through 3.2.0 are affected; the old 2.x line uses different code and is out of scope for this CVE, though it has critical flaws of its own and should not be run.

2. If you cannot upgrade immediately

Take the server off the open internet. Put it behind a VPN, or restrict the listening port to known admin addresses with a host or network firewall. HFS also has an admin_net setting in config.yaml that limits which source addresses can reach the admin panel; setting it to your management network reduces who can use a forged cookie, though it does not close the leak and anyone on an allowed network can still exploit it. Treat these as stop-gaps until the upgrade is in.

3. Check whether you were hit

• Open config.yaml (it sits next to hfs.exe on Windows, or in $HOME/.hfs on other systems; HFS prints the working directory in the first lines of its console) and read the server_code value. If you did not put JavaScript there, anything present is a strong sign of compromise. Remove it and rebuild on a clean install.
• Review the access log (access.log by default, in the same working directory) for bursts of repeated /~/api/loginSrp1 calls from a single address, especially followed by set_config calls. That sequence is what forging and then planting code looks like from the outside.
• In the admin panel, list the accounts under the Accounts section and remove any admin you did not create. Change the admin password.

4. If you find signs of compromise

Assume code ran as the HFS process. Rebuild the host rather than cleaning in place, reinstall HFS on a fixed version, and restore configuration from a backup taken before the suspicious activity. Rotate any credentials, keys or tokens that were stored on or reachable from that machine, and review what the server could reach on the internal network.

The wider lesson

The root cause is one wrong choice repeated: a general-purpose random function used where a cryptographic one was required, and then that function's output exposed to clients. Any value that protects something, a session key, a token, a password reset code, has to come from a cryptographically secure generator (crypto.randomBytes or crypto.randomUUID in Node, not Math.random), and raw generator output should never reach a client.

Our web application penetration testing looks for exactly this class of flaw, weak randomness, forgeable sessions and admin features that run code, and our red team and code review work traces how one of them turns into full control of a host. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

Sources: Horizon3.ai disclosure, SecurityWeek, BleepingComputer, Security Affairs, TechTimes, The Register, HFS config documentation.