← Back to Feed CACHED · 2026-10-06 13:43:50 · CACHE_KEY CVE-2026-61500
CVE-2026-61500 · CWE-338 · Disclosed 2026-07-13

Rejetto HFS Predictable PRNG Session-Cookie Signing Key Leading to Unauthenticated RCE

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

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.

"Unauth RCE via PRNG state recovery — active exploitation, patch now"
02 · The Attack Path

6 steps from start to impact.

STEP 01

Identify exposed HFS instance

The attacker scans for Rejetto HFS 3.x instances using Shodan, FOFA, or direct HTTP fingerprinting. The default HFS landing page and response headers (HFS server header) make identification trivial. VulnCheck reports ~100 internet-facing instances globally.
Conditions required:
  • Target runs HFS 3.0.0–3.2.0
  • HFS is network-reachable (internet or internal)
Where this breaks in practice:
  • Only ~100 public instances exist globally per VulnCheck Target Intelligence
  • Enterprise deployments are rare — HFS is primarily a hobbyist/small-team tool
Detection/coverage: Shodan dork: http.title:"HFS" or Server: HFS. Nuclei template expected post-disclosure. GreyNoise tags for HFS scanning.
STEP 02

Harvest PRNG outputs via loginSrp1

The attacker sends six unauthenticated 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.
Conditions required:
  • Network access to HFS HTTP port
  • Admin account exists (default configuration)
Where this breaks in practice:
  • None — this is unauthenticated and automatic
Detection/coverage: WAF rules detecting rapid sequential loginSrp1 requests from a single source. IDS signature for burst SRP handshake attempts.
STEP 03

Reconstruct xorshift128+ state

Using the harvested doubles, the attacker converts five consecutive outputs to their 53 visible bits and brute-forces the 11 omitted low bits per sample. The aramosf PoC implements this mathematically; the original Horizon3.ai research used Z3 (Microsoft's SMT solver) to solve the constraint system. Either approach recovers the full 128-bit internal PRNG state in seconds on commodity hardware.
Conditions required:
  • At least 5-6 consecutive PRNG outputs collected
  • Computational resources (a laptop suffices)
Where this breaks in practice:
  • None — the math is well-understood and the PoC automates it entirely
Detection/coverage: No network-visible signature at this stage — computation is local to the attacker.
STEP 04

Recover signing key and forge admin cookie

With the PRNG state recovered, the attacker rewinds the generator to the initialization point and reproduces the three base-36 chunks from 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.
Conditions required:
  • Recovered PRNG state from step 3
Where this breaks in practice:
  • None — deterministic computation
Detection/coverage: Server-side session anomaly detection could flag a session cookie appearing without a completed authentication flow, but HFS has no such logging by default.
STEP 05

Execute arbitrary code via server_code

Authenticated as admin, the attacker calls the 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.
Conditions required:
  • Forged admin session cookie from step 4
Where this breaks in practice:
  • Process runs as whatever user launched HFS — often not root/SYSTEM, but frequently a privileged user on personal machines
Detection/coverage: EDR/HIDS detecting child process spawned by Node.js (e.g., /bin/sh, cmd.exe, powershell.exe). File integrity monitoring on HFS config files.
STEP 06

Post-exploitation: pivot or persist

With code execution, the attacker establishes persistence (cron, scheduled task, systemd timer), exfiltrates files served by HFS, and pivots into the local network. The HFS data directory is immediately accessible. On Windows hosts, credential harvesting (SAM dump, LSASS) enables lateral movement.
Conditions required:
  • RCE achieved in step 5
  • Network position for lateral movement
Where this breaks in practice:
  • EDR on the host may detect post-exploitation tooling
  • Network segmentation limits pivot radius
Detection/coverage: EDR behavioral detection. Network IDS for C2 traffic. SIEM correlation of new outbound connections from HFS host.
03 · Compensating Control

1
CRITICAL 9.3→LOW 2.0
SEVERITY REDUCED
Block or restrict network access to HFS immediately — Place HFS behind a VPN, firewall, or reverse proxy with IP allowlisting. The entire attack chain requires unauthenticated HTTP access to the HFS port. Removing network reachability completely breaks step 1. Deploy within 3 days per the noisgate mitigation SLA for CRITICAL. If internet-facing, do this within hours given active exploitation.
2
CRITICAL 9.3→IGNORE 0.0
SEVERITY REDUCED
Upgrade to HFS 3.2.1+ (preferably 3.3.4) — Version 3.2.1 replaces 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.
3
CRITICAL 9.3→HIGH 7.0
SEVERITY REDUCED
Audit server_code configuration for tampering — If your HFS instance was internet-reachable before patching, assume compromise. Check the 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.
4
CRITICAL 9.3→HIGH 7.5
SEVERITY REDUCED
Deploy WAF rule blocking rapid loginSrp1 requests — Rate-limit or block sequences of >3 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.
5
CRITICAL 9.3→CRITICAL 8.5
Monitor for child processes spawned by Node.js — Configure EDR to alert on 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.
What doesn't work
  • 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.
04 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationActive. 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-ConceptPublic 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.
EPSS0.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 StatusNot in CISA KEV as of 2026-10-06. Added to VulnCheck KEV catalog. Given confirmed exploitation, CISA KEV addition is likely imminent.
CVSS VectorCVSS: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 VersionsHFS 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 VersionHFS 3.2.1 (released July 13, 2026). Current latest stable is 3.3.4. Upgrade to 3.3.4 recommended.
Internet ExposureVulnCheck Target Intelligence: ~100 internet-facing HFS instances globally. Small footprint, but historically HFS instances are disproportionately targeted due to ease of exploitation.
DiscoveryFound 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 PrecedentCVE-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.

  1. GitHub Advisory (GHSA-xxrm-3f86-v97j)
  2. aramosf PoC — CVE-2026-61500 exploit and Docker lab
  3. The Hacker News — Attackers Target Rejetto HFS Flaw
  4. Security Affairs — Anthropic Mythos Finds Rejetto HFS Bug
  5. BleepingComputer — Rejetto HFS Servers Actively Scanned
  6. DEV Community — Exploited a Day After Write-up
  7. TechTimes — Anthropic Mythos Finds Rejetto HFS Flaw
  8. Bellator Cyber — CVE-2026-61500 Under Active Attack
05 · The Call

Final Verdict
= UNCHANGED to CRITICAL (9.3/10)

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.

06 · Verification

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).

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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