Skip to content

Back to the catalog

lee1981 (@lee1981b) on X
x.comwriteup

lee1981 (@lee1981b) on X

CyberForge CVE-of-the-Day #070 on CVE-2026-61500 in Rejetto HFS 3.0.0–3.2.0. The default Koa session-signing key came from Math.random() (CWE-338) and the unauthenticated login handshake leaked outputs of the same generator. That allows recovery of the key, a forged administrator session, and code execution through the legitimate server_code feature. It covers scoring (CVSS 9.8/9.3, EPSS, KEV status), the 3.2.1 fix, a six-step SOC hunting and remediation trail (loginSrp1/2, get_config/set_config pivots, COOKIE_SIGN_KEYS review), and offline jq/Python helpers for container and config metadata.

TL;DR Analysis of CVE-2026-61500, a Rejetto HFS weak-PRNG session-key forgery that leads to RCE via server_code, with fix guidance and a SOC hunting trail.
Document

What it is

CVE-2026-61500 is a session-forgery-to-RCE flaw in Rejetto HFS 3.0.0–3.2.0 (CWE-338), covered in CyberForge's CVE-of-the-Day #070. The page states this is an older disclosed issue (fix released 13 July 2026) with public research, not a new October zero-day.

How it works

  • The default Koa session-signing key was generated with Math.random().
  • The unauthenticated login handshake exposed outputs of that same generator, so the key can be recovered and an administrator session forged.
  • The administrator then abuses server_code, a legitimate HFS feature that loads JavaScript. It runs inside the HFS process, so a hunt that looks only for spawned shells can miss it.
  • No password guessing is needed. Public research describes knowing an existing account name.

Preconditions / Affected

  • HFS 3.0.0 through 3.2.0 that is reachable by untrusted users. First fixed: 3.2.1. Latest stable at retrieval: 3.3.4.
  • The page says not to import HFS 2.x exploit mechanics or indicators.
  • Impact is execution as the HFS process. The researcher's lab image ran as root inside a container. That does not establish host root, container escape or SYSTEM on Windows. Check the real process identity, writable mounts and reachable services.

What to do

  1. Scope. Inventory every serving instance, including replicas and alternate listeners. A patched download beside an old process is not remediated. The version field in config.yaml is not proof of the running binary.
  2. Preserve evidence before changing anything. Keep logs, rotations and config history. 3.2.1 source defaults are logs/access.log and logs/access-error.log, but confirm the configured paths. Do not enable debug logging, because it can expose parameters. Default logging excludes loopback, API logging can be off, and timestamps are at request completion.
  3. Hunt request sequences. Pivot on loginSrp1/loginSrp2 followed by get_config/set_config/set_config_text under /~/api/ (adjust for proxy prefixes). Also look for administration with no visible login. hfs_http/hfs_https are normal cookie names, not indicators. HTTP 200 does not prove forgery.
  4. Correlate config to execution. Review server_code privately with the owner against the change ticket, and look for HFS-originated connections, writes or child processes near the change. A clean-looking file does not prove a clean running state.
  5. Remediate. Upgrade every instance to 3.2.1 or later (the page suggests a suitable stable build) and verify the running executable or image. Review COOKIE_SIGN_KEYS: explicit overrides bypass the patched fallback, and Koa/Keygrip verifies against multiple keys, so a retained compromised old key keeps old signatures valid. Retire suspect keys. A strong independent override is only a researcher-attributed mitigation, and the full patch is preferred because it also changes the exposed login identifier to a UUID.
  6. Verify. Reconcile each instance's build, effective config, key decision and evidence. Record coverage gaps. An empty result means no matches in the examined sources only.

The page supplies three offline helpers, all unrun against live systems:

  • A jq filter for ONE container's docker inspect output. It reports image ID, configured user and whether a COOKIE_SIGN_KEYS override is present or blank, without printing the key. Run with docker inspect <container> | jq -e -f hfs_container_metadata.jq.
  • A PyYAML script, hfs_config_metadata.py, reporting only whether server_code is present and nonempty in a config copy.
  • A jq filter, hfs_api_pivots.jq, selecting the five API names from an analyst-normalised JSON array.

Their code is on the page. It is not reproduced here.

Caveats

  • Scores. CVSS v3.1 is 9.8 and v4.0 is 9.3, both attributed to VulnCheck as CNA. NVD is deferred with no NIST score.
  • Exploitation status. The retrieved CISA KEV had no exact match (catalogue of 4 October). The only KEV label is VulnCheck's own, and its supporting feed returned 401, so incident dates, actors and victims are unverified. EPSS is 0.987% (61.1th percentile, 5 October).
  • Public research. A repo reports lab testing on 26 September against 3.2.0. The 3.2.1 negative control stopped at the changed login identifier and did not attempt forgery. The author did not run the exploit.
  • IOCs. No CVE-specific malicious IPs, domains or hashes were verified. The API names and server_code are behavioural pivots only.
  • Limits of repair. Patching does not undo earlier accounts, plugins, config or file changes.
  • Helper tests. The helpers passed 26 synthetic offline scenarios, which is not a detector test.

Organisations named here

  • COOKIE_SIGN_KEYS
  • CWE-338
  • loginSrp1
  • loginSrp2
  • server_code

CVEs named here

  • CVE-2026-61500

Technologies named here

  • FIRST EPSS — exploitation probability scoring
  • NVD — vulnerability record
  • Koa/Keygrip — multi-key cookie verification behaviour
  • Rejetto HFS
  • Docker
  • jq
  • Python
  • VulnCheck
  • CISA KEV
  • Koa

Standards and laws named here

  • EPSS

Techniques named here

  • Weak PRNG
  • Hunt request sequences
  • Correlate configuration changes to execution
  • Evidence preservation
  • Scope the serving system