It's like a casino broadcasting the seed of its shuffle machine to every passerby, then being surprised when someone predicts every hand
CVE-2026-61500 affects Rejetto HFS 3.0.0 through 3.2.0, the TypeScript/Node.js rewrite of the popular HTTP File Server. The application derives its session-cookie HMAC signing key from JavaScript's Math.random(), which in V8 (the engine behind Node.js) uses the xorshift128+ PRNG — a fast, deterministic generator that is *not* cryptographically secure. Worse, HFS leaks outputs from the same generator instance to unauthenticated clients during the loginSrp1 SRP handshake flow. An attacker who collects roughly six login responses can mathematically reconstruct the full 128-bit PRNG state, rewind it to recover the signing key, and forge a valid administrator session cookie. Once admin, the attacker writes arbitrary JavaScript into the server_code configuration field, achieving full remote code execution as the HFS process user — no authentication, no user interaction, no special conditions.
The vendor CVSS 3.1 score of 9.8 and the CVSS 4.0 score of 9.3 are both technically accurate. This is a textbook unauthenticated network-reachable RCE with zero complexity barriers. The only reason to nudge the reassessed score toward the 4.0 figure rather than 3.1 is the tiny global installed base: VulnCheck Target Intelligence finds roughly ~100 internet-facing HFS instances, making fleet-wide blast radius small for most enterprises. But for any organization actually running HFS 3.x, the severity is genuinely critical — the PoC is public, automated, and exploitation began within 24 hours of the Horizon3.ai write-up. Historical precedent reinforces this: CVE-2024-23692 (HFS 2.x, CVSS 9.8) was weaponized for cryptocurrency miners, RATs, and the HATVIBE malware framework. Attackers know this software and will exploit it quickly.
6 steps from start to impact.
Identify exposed HFS instance
HFS server header) make identification trivial. VulnCheck reports ~100 internet-facing instances globally.- Target runs HFS 3.0.0–3.2.0
- HFS is network-reachable (internet or internal)
- Only ~100 public instances exist globally per VulnCheck Target Intelligence
- Enterprise deployments are rare — HFS is primarily a hobbyist/small-team tool
http.title:"HFS" or Server: HFS. Nuclei template expected post-disclosure. GreyNoise tags for HFS scanning.Harvest PRNG outputs via loginSrp1
loginSrp1 API requests for the known admin account (or any valid username). Each response contains a server-generated value derived from Math.random(). These values leak 53 visible bits per double from the V8 xorshift128+ generator. No authentication or valid credentials are needed — the SRP handshake leaks the random values before password verification. The PoC by aramosf automates this collection.- Network access to HFS HTTP port
- Admin account exists (default configuration)
- None — this is unauthenticated and automatic
loginSrp1 requests from a single source. IDS signature for burst SRP handshake attempts.Reconstruct xorshift128+ state
- At least 5-6 consecutive PRNG outputs collected
- Computational resources (a laptop suffices)
- None — the math is well-understood and the PoC automates it entirely
Recover signing key and forge admin cookie
randomId(30) that form the HMAC signing key. The attacker then crafts a session cookie for the admin user, signs it with the recovered key, and validates it against the observed HMAC. The forged cookie grants full administrative access.- Recovered PRNG state from step 3
- None — deterministic computation
Execute arbitrary code via server_code
set_config API to inject arbitrary JavaScript into the server_code configuration field. HFS evaluates this code in the Node.js runtime, giving the attacker full OS-level command execution as the HFS process user. The aramosf PoC includes a reverse-shell demo (demo.sh). Historically, attackers have used this vector to deploy crypto miners, RATs, and backdoors.- Forged admin session cookie from step 4
- Process runs as whatever user launched HFS — often not root/SYSTEM, but frequently a privileged user on personal machines
/bin/sh, cmd.exe, powershell.exe). File integrity monitoring on HFS config files.Post-exploitation: pivot or persist
- RCE achieved in step 5
- Network position for lateral movement
- EDR on the host may detect post-exploitation tooling
- Network segmentation limits pivot radius
Math.random() with crypto.randomBytes() for key generation, eliminating the root cause. This is the definitive fix. Deploy within 3 days given active exploitation — do not wait for the 90-day remediation window. If you cannot upgrade immediately, apply the network restriction above first.server_code field in HFS configuration for injected JavaScript. Look for reverse shells, file drops, or persistence mechanisms. Review HFS data directories for unauthorized file modifications.loginSrp1 requests from a single source within 60 seconds. This raises the bar for PRNG output harvesting but does not eliminate the vulnerability — a patient attacker can space requests. Useful as defense-in-depth, not a standalone mitigation.node or node.exe spawning shell processes (/bin/sh, /bin/bash, cmd.exe, powershell.exe). This detects post-exploitation but does not prevent session forgery or admin takeover. Useful for detection of compromise, not prevention.- MFA / strong passwords — The attack bypasses authentication entirely by forging a signed session cookie. Password strength and multi-factor are irrelevant because the attacker never needs to know or guess the password.
- TLS/HTTPS — Encrypting transport does not help. The PRNG leak occurs in the application-layer response body, not via network sniffing. The attacker initiates the requests themselves.
- Session timeout reduction — Shortening session TTL doesn't help because the attacker can forge a *new* cookie at will, as many times as needed, using the recovered signing key.
- Disabling the admin account — HFS requires at least one admin account to function. Even if renamed, the attacker can enumerate valid usernames via the SRP handshake response timing.
The supporting signals.
| In-the-Wild Exploitation | Active. VulnCheck Canary Intelligence detected targeted reconnaissance from a China Telecom IP probing honeypots in Japan and the US starting October 2, 2026 — one day after PoC publication. Later attempts routed through US proxies. Small-scale but confirmed. |
|---|---|
| Proof-of-Concept | Public and weaponized. aramosf/CVE-2026-61500 by Alejandro Ramos (@aramosf) — Python 3.10+ exploit with Docker lab, reverse-shell demo, and verification script. Also listed in asvorg/CVE-2026-PoCs and XZ1r0/cve-2026-poc-collection. |
| EPSS | 0.00987 (~99th percentile for a newly disclosed CVE). Score was computed before active exploitation was observed — real-world risk is higher than EPSS suggests. |
| KEV Status | Not in CISA KEV as of 2026-10-06. Added to VulnCheck KEV catalog. Given confirmed exploitation, CISA KEV addition is likely imminent. |
| CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (9.8). CVSS 4.0: 9.3. Network-reachable, no auth, no interaction, full CIA impact. The vector accurately reflects the technical reality. |
| Affected Versions | HFS 3.0.0 through 3.2.0 (the TypeScript/Node.js rewrite). HFS 2.x is a separate codebase and is NOT affected by this specific CVE (but had its own critical: CVE-2024-23692). |
| Fixed Version | HFS 3.2.1 (released July 13, 2026). Current latest stable is 3.3.4. Upgrade to 3.3.4 recommended. |
| Internet Exposure | VulnCheck Target Intelligence: ~100 internet-facing HFS instances globally. Small footprint, but historically HFS instances are disproportionately targeted due to ease of exploitation. |
| Discovery | Found by Zach Hanley (Horizon3.ai) using Anthropic's Mythos AI model as part of *Project Glasswing*. Mythos independently identified the PRNG weakness, the information leak, and proposed using Z3 to solve the constraint system — without human prompting between steps. |
| Historical Precedent | CVE-2024-23692 (HFS 2.x, CVSS 9.8) was weaponized for cryptocurrency miners, trojans, and HATVIBE malware. Threat actors actively monitor HFS for new vulns. Expect rapid weaponization escalation. |
Sources.
- GitHub Advisory (GHSA-xxrm-3f86-v97j)
- aramosf PoC — CVE-2026-61500 exploit and Docker lab
- The Hacker News — Attackers Target Rejetto HFS Flaw
- Security Affairs — Anthropic Mythos Finds Rejetto HFS Bug
- BleepingComputer — Rejetto HFS Servers Actively Scanned
- DEV Community — Exploited a Day After Write-up
- TechTimes — Anthropic Mythos Finds Rejetto HFS Flaw
- Bellator Cyber — CVE-2026-61500 Under Active Attack
Why this verdict
- Zero-friction attack chain: The entire exploit — from first contact to RCE — requires *zero* authentication, *zero* user interaction, and runs against the default configuration. The PoC automates the full chain in a single Python script. There is no prerequisite that narrows the reachable population among HFS 3.x users.
- Active exploitation with weaponized PoC: Exploitation began October 2, 2026, within 24 hours of the Horizon3.ai write-up. The aramosf PoC provides a turnkey Docker lab and reverse-shell demo. The barrier to entry for attackers is near zero.
- Historical targeting pattern: CVE-2024-23692 in HFS 2.x was rapidly weaponized for crypto miners and RATs. Threat actors have HFS in their target lists. The same pattern is repeating.
- Role multiplier: HFS is a lightweight file-sharing utility, not a canonical high-value-role component (not an IdP, hypervisor, CI/CD system, or network edge). In its *typical role* as a personal or small-team file server, compromise yields host-level access + file exfiltration — significant but host-scoped. In a *worst-case enterprise role*, an HFS instance on an internal network could serve as an initial foothold for lateral movement, but this doesn't reach domain-takeover or fleet-compromise scale inherently. The blast radius is host → local network segment. No deployment-role floor override applies because <1% of HFS installs occupy high-value roles.
- Small installed base is context, not a downgrade: Only ~100 internet-facing instances exist globally. For enterprises managing 10,000 hosts, HFS is unlikely to be in the fleet — but *if it is*, it's a guaranteed compromise. The tiny footprint doesn't reduce the technical severity; it reduces the *probability of relevance* to a given org. We hold CRITICAL because the chain is frictionless and actively exploited.
Why not higher?
The score is already at the ceiling of the CRITICAL band. A 10.0 would require scope change (S:C in CVSS terms) — e.g., sandbox escape or cross-tenant impact — which this vulnerability does not provide. The blast radius is contained to the HFS host and its served files.
Why not lower?
Downgrading below CRITICAL would require meaningful friction in the attack chain or a prerequisite that limits exploitability. There is none: the attack is unauthenticated, remote, automated, and actively exploited with a public PoC. The small installed base is a *fleet relevance* consideration, not a *severity* consideration. If you're running HFS 3.x, you are trivially owned.
Crowdsourced verification payload.
Run this script from any Linux/macOS workstation (or WSL) that has network access to the target HFS instance. Invoke with: bash check_hfs_cve_2026_61500.sh <host:port>. No special privileges required — it makes standard HTTP requests. Replace <host:port> with the HFS address (e.g., 192.168.1.50:8080).
#!/usr/bin/env bash
# check_hfs_cve_2026_61500.sh — Detect CVE-2026-61500 (Rejetto HFS PRNG session forgery)
# Usage: bash check_hfs_cve_2026_61500.sh <host:port>
# Exit codes: 0=VULNERABLE, 1=PATCHED, 2=UNKNOWN
set -euo pipefail
if [ $# -lt 1 ]; then
echo "Usage: $0 <host:port>"
echo "Example: $0 192.168.1.50:8080"
exit 2
fi
TARGET="$1"
BASE_URL="http://${TARGET}"
echo "[*] Checking HFS instance at ${BASE_URL} for CVE-2026-61500..."
# Step 1: Confirm it's HFS and get version
VERSION_RAW=$(curl -sS --max-time 10 "${BASE_URL}/~/api/get_status" 2>/dev/null || true)
if [ -z "$VERSION_RAW" ]; then
# Try alternative endpoint
VERSION_RAW=$(curl -sS --max-time 10 -o /dev/null -w '%{http_code}' "${BASE_URL}/" -D - 2>/dev/null || true)
if echo "$VERSION_RAW" | grep -qi 'HFS'; then
echo "[*] HFS detected via headers, but could not determine version."
else
echo "[!] Target does not appear to be a Rejetto HFS instance."
echo "UNKNOWN"
exit 2
fi
fi
# Try to extract version from API response
VERSION=$(echo "$VERSION_RAW" | grep -oP '"version"\s*:\s*"\K[0-9]+\.[0-9]+\.[0-9]+' 2>/dev/null || true)
if [ -z "$VERSION" ]; then
# Try extracting from HTML title or body
HTML=$(curl -sS --max-time 10 "${BASE_URL}/" 2>/dev/null || true)
VERSION=$(echo "$HTML" | grep -oP 'HFS\s+\K[0-9]+\.[0-9]+\.[0-9]+' 2>/dev/null || true)
fi
if [ -z "$VERSION" ]; then
echo "[!] Could not determine HFS version. Manual verification needed."
echo "UNKNOWN"
exit 2
fi
echo "[*] Detected HFS version: ${VERSION}"
# Step 2: Parse version components
IFS='.' read -r MAJOR MINOR PATCH <<< "$VERSION"
# Step 3: Check if version is in vulnerable range (3.0.0 - 3.2.0)
if [ "$MAJOR" -eq 3 ]; then
if [ "$MINOR" -lt 0 ]; then
echo "[*] Version ${VERSION} is below affected range."
echo "PATCHED"
exit 1
elif [ "$MINOR" -eq 0 ] || [ "$MINOR" -eq 1 ]; then
echo "[!] Version ${VERSION} is in the vulnerable range (3.0.0 - 3.2.0)."
echo "VULNERABLE"
exit 0
elif [ "$MINOR" -eq 2 ] && [ "$PATCH" -eq 0 ]; then
echo "[!] Version ${VERSION} is in the vulnerable range (3.0.0 - 3.2.0)."
echo "VULNERABLE"
exit 0
elif [ "$MINOR" -eq 2 ] && [ "$PATCH" -ge 1 ]; then
echo "[+] Version ${VERSION} is patched (>= 3.2.1)."
echo "PATCHED"
exit 1
elif [ "$MINOR" -gt 2 ]; then
echo "[+] Version ${VERSION} is patched (> 3.2.x)."
echo "PATCHED"
exit 1
fi
elif [ "$MAJOR" -lt 3 ]; then
echo "[*] HFS 2.x detected — not affected by CVE-2026-61500 (but check CVE-2024-23692)."
echo "PATCHED"
exit 1
else
echo "[+] Version ${VERSION} is above affected range."
echo "PATCHED"
exit 1
fi
echo "UNKNOWN"
exit 2