Decoding the world of cybersecurity

·

Public exploit raises Rejetto HFS exposure

A public exploit can turn predictable random number generation in vulnerable Rejetto HFS installations into forged administrator sessions and server-side code execution.

Public exploit raises Rejetto HFS exposure
Summary
  • CVE-2026-61500 affects Rejetto HFS versions 3.0.0 through 3.2.0 and is fixed in 3.2.1.
  • Researchers demonstrated recovery of the session signing key, administrator session forgery and server-side code execution.
  • Public exploit code is available, but reliable evidence of successful attacks in production environments has not been established.

Public exploit code for a critical Rejetto HFS vulnerability can recover a server’s session signing key, forge an administrator session and reach server-side code execution without knowing the administrator password.

CVE-2026-61500 affects Rejetto HFS versions 3.0.0 through 3.2.0 and has been corrected in version 3.2.1.

The vulnerability originates in the use of JavaScript’s non-cryptographic Math.random() mechanism when HFS generates the secret used to sign session cookies. Outputs derived from the same pseudorandom number generator are also exposed through the unauthenticated login process.

By collecting a sequence of those values, the published proof of concept reconstructs the generator’s internal state and reproduces the value used as the session signing secret.

An attacker who obtains that secret can create a cookie accepted by HFS as an administrator session, bypassing the need to know or crack the administrator password. The proof of concept then uses legitimate HFS configuration functionality available to an administrator to execute server-side JavaScript.

The researcher validated the chain against an official HFS 3.2.0 container in a controlled Docker environment and confirmed that the same technique stopped before session forgery against version 3.2.1.

Rather than breaking a cryptographic algorithm, the weakness comes from using a predictable random number source where unpredictability is essential. Functions such as Math.random() can be suitable for ordinary application behaviour but are not intended to create secrets whose security depends on an attacker being unable to infer their output.

HFS compounds that weakness by exposing related generator values before authentication. Once enough output is visible, the internal state can be reconstructed and the supposedly secret signing material becomes predictable.

The publication of working exploit material lowers the barrier for abuse because another researcher or attacker no longer has to derive the technique independently. The complete path from unauthenticated requests to an accepted administrator session has been documented and tested against the vulnerable software.

Reliable public evidence of successful attacks against production systems has not been established, however. A working exploit and an exploitable internet-facing product create exposure, but neither should be presented as proof that organisations have already been compromised.

That evidential distinction is particularly important around vulnerabilities that attract rapid scanning once technical details become public. Requests attempting an exploit can show attacker interest without demonstrating that the target was vulnerable, that the exploit succeeded or that persistence followed.

HFS is designed to make files available over HTTP and may therefore be intentionally reachable from the internet. A vulnerable login interface can consequently be exposed directly rather than requiring an attacker to compromise another service first.

Because the exploit forges an authenticated administrator session, simply changing the administrator password does not address the underlying weakness. The attacker is bypassing the ordinary password check rather than guessing the credential.

Updating to version 3.2.1 removes the predictable behaviour used by the published technique. Systems remaining on versions 3.0.0 through 3.2.0 sit within the documented vulnerable range and should be assessed on that basis.

The disclosure also provides a broader example of authentication failing because a general-purpose application function was reused for security-sensitive randomness. Once values from the same generator were visible to an unauthenticated user, the security of the cookie depended on a property the generator was never designed to provide.

For internet-facing HFS installations, the immediate technical issue is therefore straightforward: vulnerable versions have a public, reproducible route to administrator impersonation and code execution, even though the scale of real-world abuse remains unknown.

×