Within days of a public write-up and proof-of-concept, attackers began probing Rejetto HTTP File Server (HFS) for CVE-2026-61500, a CVSS 9.3 flaw that lets an unauthenticated attacker forge an administrator session cookie and then run code on the server. Any HFS 3.x instance between 3.0.0 and 3.2.0 that faces the internet should be upgraded now.
What happened
On October 5, 2026, The Hacker News and BleepingComputer reported that VulnCheck had seen exploitation attempts against its canary and honeypot systems. The Hacker News dates the first detection to October 1. VulnCheck describes the activity as limited so far:
"Activity so far looks to be small-scale reconnaissance only, with a single China Telecom IP probing Canary deployments in Japan and the United States." (VulnCheck, via The Hacker News)
The flaw affects HFS 3.0.0 through 3.2.0 and is fixed in 3.2.1, which The Hacker News says shipped in July 2026. BleepingComputer recommends 3.2.1 as the minimum and 3.3.4, the current stable release, as the preferred target. There are no reports of successful compromises yet.
Horizon3.ai published the technical details on September 30, 2026. It found the bug with Anthropic's Mythos model as part of its work in Anthropic's Project Glasswing. According to Horizon3, HFS 3.x generates its session signing key with JavaScript's Math.random(). In V8 that function is xorshift128+, a non-cryptographic generator whose state can be reversed. The unauthenticated login endpoint then leaks raw Math.random() outputs in the loggingIn session field, which sits in a signed but unencrypted cookie that the client can read. Horizon3's chain samples the login endpoint 12 times, feeds the values into the Z3 constraint solver to recover the generator state, steps back to the signing key created at startup, forges an admin cookie, and then runs arbitrary JavaScript through HFS's custom endpoint feature. The Hacker News describes that last step as abuse of the server_code configuration option.
Why it matters
This is a session-integrity failure, not a password problem. The attacker never guesses or steals a credential. They mint a valid admin session because the secret behind it came from a predictable generator, and the application leaked enough output to rebuild that generator. MFA, password strength and account lockout don't help when the signing key can be recovered. The same review question applies to any internally built app: where do session signing keys, CSRF tokens and reset tokens come from, and is it a cryptographically secure source?
HFS also has a history. The Hacker News notes this is the second critical HFS bug to be exploited, after CVE-2024-23692 (CVSS 9.8) was used in 2024 to deliver cryptocurrency miners and malware including HATVIBE. HFS is often set up quickly by individuals or teams to share files and is rarely tracked as a managed asset, which makes it easy to miss.
The probing also follows the AI-assisted discovery quickly. Horizon3 credits Mythos with spotting that xorshift128+ could be inverted, connecting it to the separate output leak, and proposing the solver-based attack. Once that write-up and a working PoC were public, the gap between disclosure and probing was a matter of days.
What to check in your environment
- Find every HFS instance, including ones running on workstations and lab hosts. Check endpoint software inventory and perimeter scans for HFS 3.x web interfaces.
- Upgrade anything on 3.0.0 through 3.2.0 to at least 3.2.1, and preferably 3.3.4 per BleepingComputer's guidance.
- Take HFS off the internet where there's no business need, or put it behind a VPN or authenticating proxy. VulnCheck saw probing against exposed hosts in the US and Japan.
- Assume admin sessions may have been forged on any exposed instance that ran a vulnerable build after September 30. Review the HFS configuration for unexpected custom endpoint or server-side code entries, and check the host for new files, processes or outbound connections.
- Review web access logs for repeated unauthenticated requests to the HFS login endpoint followed by admin activity from the same source.
- Audit your own apps for
Math.random()or similar non-cryptographic generators used for session secrets or tokens, and flag them for your AppSec owners.