CVE-2026-61500: Rejetto HFS Session Cookie Key Derived from Math.random()

Executive Summary

Rejetto HTTP File Server (HFS) versions 3.0.0 through 3.2.0 contains a critical cryptographic weakness (CVE-2026-61500, CVSS 9.8) in its session management. The server derives its session-cookie signing key from Math.random(), JavaScript's non-cryptographic pseudo-random number generator. Worse, the same generator's outputs are disclosed to unauthenticated clients in login responses. A remote attacker who collects a small number of login responses can reconstruct the PRNG state, predict the signing key, and forge arbitrary session cookies — gaining full unauthenticated access to the server and all hosted files.

CVSS Score: 9.8 (Critical)

Vulnerability Overview

Affected Versions

Technical Analysis

Root Cause: Math.random() as a Security Primitive

Math.random() in JavaScript (V8, SpiderMonkey, etc.) is not cryptographically secure. It uses deterministic PRNGs (typically xorshift128+ in V8) whose full internal state can be reconstructed from a small number of observed outputs. HFS 3.x uses Math.random() to generate its session-cookie signing key during startup.

Information Disclosure: PRNG State Leak

HFS 3.x login responses include values derived from the same Math.random() call sequence used for key generation. An unauthenticated attacker making login requests can observe these values and use well-known PRNG state reconstruction techniques to recover the full generator state — and therefore the signing key.

Attack Flow

1. Attacker sends a series of login requests to HFS 3.x server
2. Login responses include Math.random()-derived values (nonces, tokens)
3. Attacker records ~32 consecutive Math.random() outputs
4. Attacker reconstructs the xorshift128+ internal state (well-documented technique)
5. Attacker rewinds PRNG to the point of key generation
6. Signing key is recovered
7. Attacker forges a session cookie signed with the recovered key
8. Server accepts the forged cookie — full admin/file access granted

PRNG State Recovery (Concept)

// V8's Math.random() uses xorshift128+
// With 32+ observed outputs, state recovery is trivial using tools like:
// - Z3 SMT solver
// - Specialized xorshift128+ crackers
// The recovered state lets you predict ALL past and future outputs
 
// Once key is recovered:
const forgedCookie = sign(payload, recoveredKey);
// Server accepts it as legitimate

Impact

Remediation

Step 1: Upgrade or Patch HFS

Check the Rejetto project for a patched release that replaces Math.random() with crypto.randomBytes():

# Check your current HFS version
./hfs --version
 
# Monitor the Rejetto GitHub for security releases
# https://github.com/rejetto/hfs

Step 2: Immediate Mitigations (Until Patch Available)

If you cannot immediately upgrade:

# 1. Restrict HFS access to trusted networks only via firewall
iptables -I INPUT -p tcp --dport 8080 -s 0.0.0.0/0 -j DROP
iptables -I INPUT -p tcp --dport 8080 -s 192.168.1.0/24 -j ACCEPT
 
# 2. Place HFS behind an authenticated reverse proxy (nginx, Caddy)
# nginx example:
# location / {
#   auth_basic "Restricted";
#   auth_basic_user_file /etc/nginx/.htpasswd;
#   proxy_pass http://localhost:8080;
# }

Step 3: Rotate Existing Sessions

Since existing signing keys may have been recovered by attackers:

1. Restart HFS — generates a new (still weak) key; all existing sessions are invalidated
2. Review access logs for unexpected login patterns or file access from unknown IPs
3. Change all HFS user passwords — assume compromised

Step 4: Audit File Access

# Review HFS access logs for anomalous activity
grep -E "(GET|POST|PUT|DELETE)" hfs-access.log | \
  awk '{print $1}' | sort | uniq -c | sort -rn | head -20
 
# Look for access from unexpected IP ranges
grep -v "192\.168\.\|10\.\|127\." hfs-access.log | grep -v "^#"

Detection

For Developers: Secure Session Key Generation

// VULNERABLE — never do this for security keys
const key = Math.random().toString(36);
 
// CORRECT — use cryptographically secure randomness
const crypto = require('crypto');
const key = crypto.randomBytes(32).toString('hex');   // 256 bits, CSPRNG

Post-Remediation Steps

1. Upgrade HFS to a version with crypto.randomBytes() for key generation
2. Rotate all passwords for HFS user accounts
3. Audit file access logs for the full period the vulnerable version was running
4. Network-restrict HFS — it should never be directly exposed to the internet
5. Enable TLS via a reverse proxy to prevent session cookie interception in transit
6. Implement rate limiting on login endpoints to slow PRNG observation attacks

References

• NVD — CVE-2026-61500
• Rejetto HFS on GitHub
• CWE-338: Use of Cryptographically Weak PRNG
• OWASP: Insecure Randomness

Related Reading

• CVE-2026-57433: Perl Storable Integer Overflow via SX_HOOK
• CVE-2026-13221: Perl Regex Trie Overflow — Silent Match Failure
• CVE-2026-58065: Apache Airflow Git SSH Host Key Bypass