Rejetto HTTP File Server (HFS) 3.x is back in the crosshairs: CVE-2026-61500 (CVSS up to 9.8) chains weak session-cookie signing based on `Math.random()` with leakage that lets remote attackers reconstruct the signing key, forge administrator cookies, and reach remote code execution through `server_code`. Horizon3.ai found the chain using Anthropic Mythos; the fix shipped in HFS 3.2.1 on 13 July 2026, but late-September and early-October 2026 technical publicity triggered active scanning.
VulnCheck reported canary hits on 1–2 October from a China Telecom address against honeypots in Japan and the United States — small-scale reconnaissance, not proof of mass exploitation, but enough for VulnCheck KEV listing. CISA had not added CVE-2026-61500 to KEV as of 6 October, meaning no federal due date — yet waiting for KEV is unwise: the flaw is network-reachable, unauthenticated, and hits exposed file servers that rarely patch at firewall pace.
BleepingComputer and SecurityWeek describe the chain: collect a few login responses, invert the PRNG, sign an admin cookie, enable server-side JavaScript. It is a reminder that “small open-source component” is not “small risk” when it sits on a DMZ or internal developer share.
What IT and security leads should do now
Inventory HFS 3.0.0–3.2.0; upgrade to 3.2.1+ or remove internet exposure. Pull admin UI off public networks, restrict source IPs, rotate sessions after patch. Hunt logs for repeated login attempts followed by admin actions and unexpected outbound connections. Treat suspected RCE as host compromise.
Evidence status
Horizon3.ai disclosure (2026-09-30), Rejetto 3.2.1 release notes, VulnCheck canary data, BleepingComputer/SecurityWeek (2026-10-05).
AI-assisted discovery (Mythos) is the news angle, but operationally it matters little: attackers only need a working chain and exposed ports. Many HFS instances are lab or file-drop nodes forgotten when projects ended — ideal recon targets. Because the fix existed in July but scanning rose after September publicity, patch cycles should include “dormant apps” inventory, not only production systems with CMDB owners.
Forensically: preserve web and application logs, compare `server_code` configuration before/after, and hunt for new local users or scheduled jobs on the host. If HFS shares a host with other software, assume lateral movement after RCE. ShinyHunters mentions in some industry commentary reflect interest in the vulnerability class, not necessarily this CVE — keep attribution separate from patch priority.
Run internal attack-surface scanning: HFS often listens on unusual ports in lab networks. Include PRNG/session flaws in your legacy-tools checklist. After upgrading to 3.2.1, rotate all sessions and consider moving file services to managed platforms with central IAM. If HFS runs as a Windows service, review which account it uses — RCE there often means high privilege. Continued scanning without a KEV listing means your risk model must handle critical CVSS without waiting for CISA.
Run internal attack-surface scanning: HFS often listens on unusual ports in lab networks. Include PRNG/session flaws in your legacy-tools checklist. After upgrading to 3.2.1, rotate all sessions and consider moving file services to managed platforms with central IAM. If HFS runs as a Windows service, review which account it uses — RCE there often means high privilege. Continued scanning without a KEV listing means your risk model must handle critical CVSS without waiting for CISA.
Threat intelligence teams should track both vulnerability hype cycles and actual probe volume: canary hits prove intent to find victims, not successful compromise. Still, pair network detections with asset owners — developers often deploy HFS without ticketing. Red-team exercises can validate whether your EDR sees post-exploitation from `server_code` execution. Document upgrade paths for air-gapped lab machines that cannot auto-update.