An AI model found a critical Rejetto HFS flaw, attackers exploited it almost immediately. What CVE-2026-61500 means if you run a lightweight file server.
Table of Contents
Vulnerability Entity Data: CVE-2026-61500
- Affected Software: Rejetto HTTP File Server (HFS) versions 3.0.0 through 3.2.0
- Vulnerability Type: Remote Code Execution (RCE) via Session-Cookie Forgery
- CVSS Score: 9.3 – 9.8 (Critical)
- Root Cause: Cryptographically weak generation using JavaScript’s
Math.random() - Patch Version: 3.2.1 (Released July 2026)
What is CVE-2026-61500? It is a critical remote code execution vulnerability (CVSS 9.3–9.8) affecting Rejetto’s HTTP File Server (HFS) versions 3.0.0 through 3.2.0. The bug allows unauthenticated attackers to collect login responses, use a constraint solver to reverse session-cookie signing keys generated by JavaScript’s weak Math.random(), and forge administrator cookies to execute server-side code.
A small business running a quick internal file drop rarely thinks about it as exposed infrastructure. That’s exactly the kind of software Rejetto’s HTTP File Server (HFS) is built for: a lightweight, no-database way to share files from a folder over HTTP, popular with freelancers, small IT shops, and anyone who needed something simpler than a full web server. It’s also now the subject of one of the more unusual vulnerability disclosures of 2026, because of who found the bug and how fast it got weaponized afterward.
Technical Mechanics of CVE-2026-61500 and the Math.random() Flaw
CVE-2026-61500 affects HFS versions 3.0.0 through 3.2.0. The root cause isn’t exotic: the server derives its session-cookie signing key from JavaScript’s Math.random(), a generator built for simulations and games, not cryptography, and then discloses some of that same generator’s output to unauthenticated visitors during the login flow. An attacker only needs to collect a handful of login responses. From there, a constraint solver called Z3 can reconstruct the generator’s internal state, recover the signing key, and forge a valid administrator session cookie. Once authenticated as admin, HFS has a configuration feature called server_code that executes server-side code, turning a forged login into full remote code execution.
None of that requires guessing a password, phishing anyone, or finding a second bug. It’s a straight line from “watch a few login attempts” to “run code as admin,” and that line is short enough that security researchers rated it 9.3 to 9.8 out of 10 depending on the scoring method.
The AI Discovery Factor and Rapid Exploitation in the Wild
Horizon3.ai’s Zach Hanley has said the flaw was originally surfaced by Anthropic’s Mythos model, which applied mathematical reasoning to recognize that HFS’s “random” session tokens weren’t truly unpredictable. It’s the same category of weakness that’s broken custom crypto implementations for decades, just found this time by a model built for general-purpose reasoning rather than a tool purpose-built to audit random-number generators.
That detail matters less for your server’s security posture than what happened next: a public technical write-up went out, and within roughly a day, real exploitation attempts showed up in the wild. A Python proof-of-concept circulated publicly in late September, and VulnCheck detected real exploitation attempts beginning October 2, the day after the technical write-up went public, tracing back to an IP address in China and targeting vulnerable servers in the US and Japan. The gap between “here’s how it works” and “here’s it being used against real servers” keeps shrinking, and AI-assisted vulnerability research, on both sides of that fight, is part of why.
The actual good news: Rejetto HFS was already patched
Here’s the detail that’s easy to miss in the headlines: Rejetto shipped HFS 3.2.1 back in July 2026, months before the public write-up and the exploitation wave that followed it. Anyone who updated promptly when that release came out was never exposed to the attacks happening now. This isn’t a zero-day with no fix available. It’s an old patch that a meaningful number of HFS installs apparently never applied, which is a far more common failure mode than it gets credit for. A fix existing doesn’t help anyone who never installs it.
If you or a client is running HFS anywhere, on a VPS, a home server exposed for convenience, or an internal file-sharing box that somehow ended up with a port forwarded to it, checking the version number takes thirty seconds and should happen before anything else on this list.
Why this matters even if you’ve never heard of HFS
The specific software here is niche. The pattern is not. A huge amount of small-business infrastructure runs utility tools exactly like HFS: lightweight, single-purpose, installed once by whoever needed it at the time, and then left running with nobody tracking whether it ever gets security updates. Nobody puts “monitor HFS for CVEs” on a recurring calendar reminder, because nobody remembers it’s still running in the first place.
Shared, unmanaged hosting often gives you zero visibility into exactly this kind of risk. If you’re managing your own VPS or dedicated server, you’re the one responsible for knowing what’s actually listening on it. That’s worth sitting with for a minute: do you have a current inventory of every piece of software exposed to the internet on your own server, or would you only find out something like this was running from a log full of forged login attempts?
A practical checklist for anyone running exposed file-sharing software
A few concrete steps, in rough priority order:
- Check what’s listening. Run
netstat -tulpnon Linux, or check your firewall’s open-port list, and account for every service you find, not just the ones you remember installing. - If you find HFS specifically, confirm it’s on 3.2.1 or later. Versions before that are vulnerable regardless of how obscure or internal-only the install seems.
- Don’t expose file-server admin interfaces directly to the public internet if you can avoid it. Put them behind a VPN, an SSH tunnel, or at minimum an IP allowlist, so a session-forgery bug like this one has nothing to reach.
- Treat any software that handles authentication with its own custom logic, rather than a well-audited library, as higher risk by default.
Math.random()-based session tokens are a known anti-pattern; if you’re evaluating any lightweight server tool, it’s a fair question to ask whether it was designed with real cryptographic randomness in mind. - Set a recurring reminder, genuinely, to re-check exposed services for pending updates. The gap between a patch existing and a patch being applied is where almost every exploited-in-the-wild story like this one lives.
The broader lesson for anyone managing their own server
AI-assisted vulnerability discovery is going to keep finding bugs like this faster than it used to get found, which compresses the window between disclosure and exploitation on both the attacker and defender side. That’s a real shift, but it doesn’t change the fundamentals of running a server responsibly: know what’s exposed, patch promptly, and don’t let convenience software quietly become your least-monitored attack surface. Whoever got hit here wasn’t undone by a sophisticated nation-state campaign. They were undone by a free file-sharing tool nobody updated, even though the fix had been out for months.
If you’re not sure what’s currently exposed on your own VPS or dedicated server, that’s a worthwhile afternoon project, not a someday item. The alternative is finding out the way some Rejetto HFS users just did.
This isn’t HFS’s first severe flaw, and that’s a pattern worth weighing
CVE-2026-61500 isn’t an isolated bad week for Rejetto HFS. A prior critical flaw, CVE-2024-23692, carried a 9.8 CVSS score and saw widespread exploitation back in July 2024, with attackers using it to deliver malware and cryptocurrency miners onto compromised servers. Two separate, severe, remotely exploitable vulnerabilities in the same small, largely unmaintained utility within roughly two years is a legitimate signal about the software’s overall security posture, not just bad luck twice.
Lightweight, free utility software written by a small team or a single maintainer tends to get far less ongoing security scrutiny than a mainstream web server or a widely-used CMS, right up until a researcher or an AI model happens to look closely. If you’re choosing file-sharing software for anything beyond a strictly temporary, firewalled, internal use case, it’s worth weighing that history against the convenience. For anything facing the public internet long-term, a more actively maintained alternative, or a managed file-transfer feature built into your hosting control panel, carries a meaningfully different risk profile than a tool that’s now had two RCE-capable flaws in two years.
One more practical note: if you inherited a server from a previous admin, freelancer, or agency, don’t assume you know everything running on it. A quick audit of installed services and open ports after any handover, not just after a breach scare, catches exactly this kind of forgotten utility before it becomes someone else’s headline.