Rejetto HFS signed admin session cookies with Math.random(), enabling host takeover

Rejetto HFS, a lightweight file server often installed on spare office machines to hand files to colleagues or clients, shipped a serious session-management flaw across versions 3.0.0 through 3.2.0. The signing key for its administrative session cookie was derived from JavaScript's Math.random(), a general-purpose generator that offers no cryptographic security. The issue is tracked as CVE-2026-61500; VulnCheck's advisory rates it 9.3 on the CVSS 4.0 scale and maps it to CWE-338, use of a cryptographically weak pseudo-random number generator. A fix shipped in version 3.2.1.

How the cookie forgery works

The advisory notes that the generator's output is not only used to build the signing key — it is also sent to unauthenticated clients as part of the login exchange. That combination turns a theoretical weakness into a practical attack.

A weak generator used in isolation would still leave an attacker guessing at an unknown key. But pseudo-random generators in JavaScript engines are deterministic state machines: a single output is hard to predict, while several consecutive outputs can be enough to reconstruct the internal state computationally rather than by brute force. An attacker who collects a handful of login responses can recover the state, derive the signing key, and then mint valid cookies rather than steal them — including cookies claiming administrator privileges. No password needs to be guessed and no user needs to be phished.

From forged cookie to code execution

Administrative access to HFS is more than a way to browse shared folders. The product's server_code configuration feature executes server-side JavaScript supplied through the administration interface. A dev.to analysis of the flaw points out that an attacker holding a forged admin cookie can use that feature to run code under whatever account operates the file server — which, on the small machines where HFS typically runs, is frequently a local administrator.

Reachable, but hard to count

HFS installations turn up on branch-office machines, engineering workstations distributing build artifacts, and servers a managed service provider set up years ago and never revisited, according to the analysis. Sizing the exposed population is difficult. ZoomEye queries run on 23 October 2026 for the write-up returned 9,998 hosts for the application fingerprint app=“HFS”, 50,263 for a body match on the product's signature string, and 61,861 for a plain title match — but none of these queries separate HFS 2.x from HFS 3.x, and the title query also catches unrelated pages. The figures show the family is widely reachable on the open internet, not how many hosts run a vulnerable build; reliable inventory has to come from internal configuration data.

What operators should check

• Version: builds 3.0.0 through 3.2.0 are affected; 3.2.1 contains the fix. HFS 2.x is a separate codebase not covered by this advisory, but it should not be assumed safer by default.
• Exposure: the administration interface does not need to be reachable from arbitrary internet addresses. Restricting it to a management network or VPN, and keeping file sharing separate from administration, removes most of the risk.
• Privileges: a dedicated low-privilege service account means the next flaw in the same code does not immediately become a full host compromise.
• Sessions: the signing key changes with the fix, but cookies minted before the upgrade were created under a key an attacker may already know. Restart the service and review logs for administrative actions nobody on the team performed.
• server_code: if the feature is not needed, disabling it removes the final step of the attack chain even on an unpatched host.

Detection after the patch

Because patching does not evict an attacker already inside, the write-up recommends behavioural monitoring. Flag authenticated calls to administrative endpoints from addresses that never completed an interactive login flow — a forged cookie produces an authorized request with no failed attempts and no multi-step login sequence behind it. On the process side, a shell, script host or download utility appearing as a child of the HFS executable is a strong signal, since server_code abuse has to run somewhere.

Why it matters

The flaw is a compact demonstration of how session security collapses when two mistakes meet: a signing key drawn from a non-cryptographic source, and a code path that leaks that source's output to strangers. Applications that answer “is this user logged in” with a signature need a cryptographic generator and a key that never leaves the server. It is equally a reminder that convenience software on forgotten machines carries real cost — the reachable HFS population is large, most hosts cannot be version-fingerprinted from outside, and the path that starts with a predictable cookie ends with code execution on the host, not read-only access to shared folders.