Rejetto HFS CVE-2026-61500

Exploitation requires that the HFS instance (versions 3.0.0-3.2.0) be network-reachable and that its login endpoint be accessible to the attacker, because the attack depends on collecting the Math.random() outputs disclosed in login responses to reconstruct the signing key. No credentials, user interaction, or non-default configuration are needed (CVSS PR:N/UI:N) - the weak-PRNG key derivation is inherent to affected versions. Reaching full RCE additionally relies on the server_code configuration feature being present, which is the built-in path from forged admin session to code execution. Limiting factors: the attacker must be able to observe enough login responses to solve the generator state (so instances whose login/admin surface is firewalled or proxied to trusted IPs are not exploitable from the open internet), and the flaw is fixed in 3.2.1, so only 3.0.0 through 3.2.0 are at risk.

The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H, score 9.3) rates this critical with no authentication and full confidentiality/integrity/availability impact, consistent with unauthenticated forgery leading to RCE. I would nuance attack complexity: collecting sufficient login samples and reconstructing the Math.random() state is a deliberate, non-trivial step, so a defensible assessment is AC:H rather than AC:L - the outcome is reliable but the technique is not a single trivial request. No EPSS score, KEV listing, or public POC is present in the provided data, so real-world exploitation signals are currently absent; the primary risk driver is the combination of a network-reachable, unauthenticated path to RCE and a credible disclosure by VulnCheck in collaboration with Horizon3.ai. There is no conflict between the CVSS vector and the description - both indicate remote, pre-auth exploitation. Bottom line: a genuine high priority for any exposed HFS 3.x instance, tempered only by the absence of confirmed in-the-wild activity.

An attacker who can reach an internet-exposed HFS 3.x login page sends a small number of unauthenticated login requests and records the Math.random()-derived values leaked in the responses. Using those samples they reconstruct the generator's internal state offline, regenerate the session-cookie signing key, and forge a signed administrator cookie; presenting that cookie grants full admin access, after which they use the server_code configuration feature to execute arbitrary commands on the host. No public exploit is identified at time of analysis, though the technique is well understood for Math.random() state recovery.