What Happened
Between July 13 and early August 2026, attackers began scanning for CVE-2026-61500, a critical remote code execution vulnerability in Rejetto HFS (HTTP File Server) versions 3.0.0 through 3.2.0. The flaw comes from using JavaScript's Math.random() function to generate session-cookie signing keys.
This isn't a buffer overflow or injection vulnerability. It's more severe. The server's authentication relies on a predictable pseudo-random number generator. If an attacker predicts the session-cookie signing key, they can forge valid sessions, take over administrator accounts, and execute arbitrary code on the server.
Horizon3 discovered the vulnerability using Anthropic's Mythos AI model and published a proof-of-concept exploit. The vendor released version 3.2.1 with a fix, but scanning activity shows attackers are searching for unpatched instances.
Timeline
July 13, 2026: CVE-2026-61500 publicly disclosed. Horizon3 publishes technical details and proof-of-concept code demonstrating session forgery leading to remote code execution.
July 13, 2026: Rejetto releases HFS 3.2.1, replacing Math.random() with a cryptographically secure random number generator.
Late July - Early August 2026: Active scanning detected across internet-facing HFS instances. Attackers are probing for vulnerable versions, likely using automated tools to test session-cookie predictability.
Which Controls Failed or Were Missing
Secure session management: The application used a non-cryptographic random number generator (Math.random()) for security-critical operations. This violates basic cryptographic hygiene. Math.random() produces predictable sequences that an attacker can reproduce if they know the seed or observe enough outputs.
Vulnerability scanning and patch management: Organizations running internet-facing HFS servers either weren't scanning for known vulnerabilities or weren't acting on scan results quickly enough. The fix was available immediately upon disclosure, yet vulnerable instances remain online weeks later.
Security code review: The Math.random() implementation should have been caught during development or security review. Any code review checklist that includes "cryptographic operations" should flag non-cryptographic RNGs in authentication flows.
Network segmentation: Many affected deployments appear to be internet-facing file servers. If you're running HFS for internal file sharing, it shouldn't be directly accessible from the internet. Defense-in-depth would have limited exposure even with the vulnerability present.
What the Relevant Standards Require
OWASP ASVS v4.0.3, Section 2.3.1: "Verify that the application generates a new session token on user authentication." More critically, Section 3.5.2 states: "Verify that random numbers are created with proper entropy even when the application is under heavy load, or that the application degrades gracefully in such circumstances."
Using Math.random() for session tokens fails this requirement. The function doesn't provide cryptographic entropy. In JavaScript environments, you need crypto.getRandomValues() or equivalent platform-specific secure random generators.
PCI DSS v4.0.1, Requirement 6.2.2: "Bespoke and custom software are developed securely" with specific testing requirements including "Secure coding techniques that address common coding vulnerabilities." The standard explicitly calls out OWASP guidance, which warns against predictable session identifiers.
NIST 800-53 Rev 5, SC-13 (Cryptographic Protection): "The information system implements required cryptographic protections using cryptographic modules." While Math.random() isn't technically a cryptographic module, using it for security-critical random number generation violates the spirit and letter of this control. The control implementation guidance specifically requires FIPS 140-validated random number generators for cryptographic operations.
ISO/IEC 27001:2022, Annex A.8.24 (Use of cryptography): Organizations must define and implement rules for the effective use of cryptography, including cryptographic key management. Session-signing keys fall under this requirement. The control expects you to use appropriate cryptographic implementations, not general-purpose pseudo-random functions.
Lessons and Action Items for Your Team
Audit your random number generation: Search your codebase for Math.random(), rand(), or other non-cryptographic RNGs. If you find them in authentication, session management, token generation, or cryptographic operations, replace them immediately. Every language has a cryptographically secure alternative: crypto.getRandomValues() in JavaScript, secrets module in Python, SecureRandom in Java.
Inventory your open-source dependencies: You're running more open-source file servers, admin panels, and utilities than you think. Create an asset inventory that includes not just your custom applications but every piece of software exposed to your network. HFS is a lightweight file server that teams install for "temporary" file sharing that becomes permanent. Find these deployments.
Set a 72-hour patch window for critical RCE vulnerabilities: CVE-2026-61500 was disclosed and fixed on the same day. If you're still vulnerable weeks later, your patch management process is broken. For any vulnerability that allows unauthenticated remote code execution, you need an emergency patch process that can deploy fixes within 72 hours. Document this process now, including after-hours contact procedures and change-approval shortcuts.
Review your code review checklists: Add a specific item: "Are any random number generators used for security purposes? If yes, are they cryptographically secure?" Train developers to recognize the difference. Math.random() is fine for shuffling a UI element order. It's never acceptable for security.
Test your vulnerability scanning coverage: If you're running vulnerability scanners, they should have detected CVE-2026-61500 within days of disclosure. If they didn't, either your scanners aren't configured to detect this software, or they're not running frequently enough. Verify that your scanning tools cover open-source web applications and that you're scanning at least weekly.
Segment file-sharing infrastructure: File servers don't need to be internet-facing. Put them behind a VPN or zero-trust access gateway. If you must expose them externally, place them in a DMZ with strict egress filtering so that even a successful RCE can't easily pivot to internal systems.
The Math.random() vulnerability in HFS isn't sophisticated. It's a fundamental error that should have been caught during development, code review, or security testing. The fact that it wasn't, and that vulnerable instances remain online weeks after a fix was released, points to systemic gaps in secure development practices and patch management. Fix those gaps, not just this vulnerability.
