In short: CVE-2026-61500 is a critical (CVSS 9.3) authentication bypass in Rejetto HTTP File Server (HFS) 3.x. Because the server’s session-signing key comes from a predictable random number generator that also leaks its output during login, an attacker can rebuild the key, forge an administrator cookie and then run code on the server. A fix has been available since July 2026 (HFS 3.2.1), but VulnCheck honeypots started seeing probes in early October, shortly after a public proof of concept was released.
Affected and fixed versions
| Product | Affected | Fixed |
|---|---|---|
| Rejetto HFS 3.x | 3.0.0 – 3.2.0 | 3.2.1 (latest stable recommended) |
Root cause: Math.random() used for a secret
HFS is written in JavaScript (Node.js). The vulnerable versions derive the session-cookie signing key from Math.random(), which in V8 uses the xorshift128+ algorithm. That generator is fast but not cryptographically secure: if you observe enough consecutive outputs, you can recover its internal state and predict every past and future value.
The second mistake made it practical. During login, HFS sent raw values from that same generator to unauthenticated clients. The full attack looks like this:
- Send a small number of login requests and collect the generator outputs leaked in the responses.
- Reconstruct the xorshift128+ state from those values.
- Recover the session-cookie signing key.
- Forge a valid cookie for an administrator account.
- Abuse the documented
server_codeconfiguration feature, which runs custom server-side JavaScript, to execute commands on the host.
From there an attacker can read, steal or delete files, install malware, or use the server as a pivot into the internal network.
Discovered with an AI model
Horizon3.ai researchers found the issue in June 2026 using Anthropic’s Mythos model, which reasoned that the leaked Math.random() values could be reversed to obtain the signing key. Rejetto shipped HFS 3.2.1 on July 13, 2026, and Horizon3 published technical details and a proof of concept on September 30.
Exploitation status
In early October, VulnCheck reported probes against its canary systems in Japan and the United States, coming from a single China Telecom IP address. The activity looked like small-scale reconnaissance, and no successful compromise or post-exploitation activity had been reported at the time. With a public PoC available, wider exploitation is a realistic next step.
What to do now
- Upgrade to HFS 3.2.1 at minimum, ideally the latest stable release.
- Do not expose HFS directly to the internet unless you need to; put it behind a VPN or an authenticating reverse proxy.
- Review admin activity and the
server_codesetting for changes you did not make. - Hunt in logs for bursts of login requests from one IP followed by an admin session from that same address.
Lesson for developers
Never use Math.random() for tokens, keys or session identifiers. In Node.js, use the crypto module instead:
const crypto = require('crypto');
// 32 random bytes from a CSPRNG, hex-encoded
const signingKey = crypto.randomBytes(32).toString('hex');And never return internal random values to clients. Weak session handling is a classic web security failure; our OWASP Top 10 guide covers the related categories, and our Burp Suite tutorial shows how to inspect cookies and session tokens during an authorized test.