A file server that runs on a spare machine in an office corner rarely gets a threat model. Rejetto HFS is exactly that kind of software: a single executable, a browser administration page, and a directory of files shared with colleagues or clients. CVE-2026-61500 shows what happens when such a tool builds its session security on a random number generator that was never meant to keep secrets.
What the advisory says
The CVE record describes HFS 3.0.0 through 3.2.0. In those releases the signing key for the session cookie is derived from JavaScript's Math.random(), a general-purpose generator with no cryptographic properties. The same generator's output is also exposed to unauthenticated clients during the login exchange.
That combination matters more than either half. A weak generator used in isolation is still an unknown value to an attacker. A generator whose output an attacker can observe is a solvable puzzle. Put them together and the search space collapses from "guess a key" to "reconstruct a state from a handful of samples".
The published severity is high: VulnCheck's advisory lists CVE-2026-61500 with a CVSS 4.0 score of 9.3 and classifies the weakness as CWE-338, use of a cryptographically weak pseudo-random number generator. The fix shipped in HFS 3.2.1.
Why observing generator output is enough
Pseudo-random generators used by JavaScript engines are deterministic state machines. Given one output they are unpredictable in practice; given several consecutive outputs, the internal state can often be recovered by computation rather than brute force. The advisory's description follows exactly that path: collect a small number of login responses, reconstruct the generator's state, recover the signing key.
Once the key is known, the cookie is no longer a credential that has to be stolen. It can be minted. An attacker crafts a cookie that claims administrator rights, signs it with the recovered key, and presents it to the server. There is no password to guess, no phishing step, and no need to sit in the same network segment for long.
From an administrator cookie to code on the host
Administrative access to HFS is not a read-only outcome. The product exposes a server_code configuration feature that runs server-side JavaScript supplied through the administration interface. An attacker who holds a forged administrator session can therefore move from "I can see your shared folders" to "I can execute code under the account that runs the file server".
That escalation path is what turns a weakly generated cookie into a full host compromise. Whether the process runs as a service account, as SYSTEM, or as an interactive user decides how far the attacker gets next. On the small servers where HFS typically lives, that account is frequently a local administrator, because the tool was installed quickly and convenience won.
Who carries the exposure
HFS installations are not concentrated in one industry. They appear on branch-office machines, on engineering workstations used to hand out build artifacts, and on servers that a managed service provider set up for a client years ago and never revisited.
ZoomEye can be used to size the population, with a caveat that matters. A query for the application fingerprint app="HFS" returned 9,998 matches when executed for this article on 23 October 2026, while a body match on the product's signature string http.body="HttpFileServer" returned 50,263, and a plain title="HFS" query returned 61,861. None of these queries distinguish HFS 2.x from HFS 3.x, and the title query also matches unrelated pages. The numbers describe how widely the family is reachable on the public internet. They do not measure how many hosts run a vulnerable build.
The practical reading: a very large pool of instances speaks the product's protocol on the open internet, and only a fraction can be identified by version from the outside. Inventory has to come from your own configuration data, not from a search engine.
What to check first
Start with the version, then with exposure, then with evidence of use.
Confirm the build. Anything in the 3.0.0 to 3.2.0 range is affected; 3.2.1 contains the fix. HFS 2.x is a separate codebase and is not covered by this advisory, but it has its own history and should not be treated as safer by default.
Decide whether the interface belongs on the internet. An administrative file server reachable from arbitrary addresses is a design choice, not a requirement. Restrict it to a management network or a VPN, and keep the file-sharing function separate from the administration page.
Drop the service account's privileges. If the process that answers HTTP requests is a local administrator, every future flaw in the same code becomes a full compromise. A dedicated low-privilege account bounds the blast radius.
Treat sessions as suspect after upgrading. The signing key changes with the fix, but any cookie minted before the upgrade was minted under a key an attacker may already know. Restart the service and review the access log for administrative actions that no one in the team performed.
Detection ideas that survive the patch
The useful signals are behavioural rather than version-based, because the version will eventually be correct on paper while the host stays compromised.
Watch for authentication successes on the administration endpoint from addresses that never completed a login form. A forged cookie produces a request sequence that skips the usual interactive steps: no failed attempts, no multi-request login flow, just an authorized call to a privileged endpoint from a new source.
Watch what the service spawns. On Windows, a child process created by the HFS executable is unusual, and a child shell, script host, or download utility is a strong signal. On Linux, the process tree of the file server should be nearly empty; a shell appearing under it is the equivalent alarm. This is also the layer where server_code abuse becomes visible, because the code has to run somewhere.
Watch the file server's own configuration. The server_code feature is powerful by design. If it is not needed, disabling it removes the final step of the chain even on an unpatched host, and any change to it deserves a review.
The underlying lesson is broader than one small product. Cookie signing keys assembled from a general-purpose random source, and any code path that reveals that source's output, defeat the entire session model without touching a password. Applications that answer "is this user logged in" with a signature need a cryptographic generator, a key that never leaves the server, and a review process that notices when neither is true.
References
CVE.org record for CVE-2026-61500: https://www.cve.org/CVERecord?id=CVE-2026-61500
VulnCheck advisory, "Rejetto HFS < 3.2.1 Session Forgery via Predictable Signing Key": https://www.vulncheck.com/advisories/rejetto-hfs-session-forgery-via-predictable-signing-key
Rejetto HFS release 3.2.1: https://github.com/rejetto/hfs/releases/tag/v3.2.1
ZoomEye queries executed 23 October 2026:
app="HFS",http.body="HttpFileServer",title="HFS"