Attackers have begun targeting CVE-2026-61500, a critical authentication flaw in Rejetto HTTP File Server that allows an unauthenticated remote attacker to reconstruct the server’s session-signing key, forge an administrator session cookie, and ultimately execute code on the underlying server. The vulnerability affects HFS 3.0.0 through 3.2.0 and was fixed in version 3.2.1, released in July 2026. VulnCheck rates the issue critical with CVSS 9.3 under CVSS v4, while the CVE record also carries a 9.8 CVSS v3.1 score because exploitation requires no authentication, no user interaction, and has high confidentiality, integrity, and availability impact.

The flaw is unusually interesting because the failure is not a broken password check or an exposed admin endpoint. It is a cryptographic design error around session generation. HFS generated the secret used to sign session cookies with JavaScript’s Math.random(), a generator that was never designed for security-sensitive purposes. Worse, unauthenticated login exchanges exposed values generated from the same underlying V8 pseudo-random number generator. An attacker who collects a small number of those responses can reconstruct the generator’s internal state and predict enough of its output to recover the session-signing key. Once the key is known, the attacker can create a cookie that HFS accepts as a valid administrator session.

The attack path can therefore be summarized as: unauthenticated login requests → PRNG outputs collected → internal Math.random() state reconstructed → session-signing key recovered → administrator cookie forged → HFS accepts attacker as admin → server_code configuration abused → arbitrary server-side JavaScript executed → remote code execution. There is no password cracking in that sequence. The attacker simply recreates the secret the application relies upon to decide whether a session is legitimate.

That distinction matters because changing the administrator password alone would not have fixed the vulnerable design while the affected code remained in place. If the signing key can be mathematically recovered from observable PRNG output, the attacker does not need to know the administrator’s password in the first place. The vulnerability effectively turns authentication into a prediction problem.

The root cause is classified as CWE-338, Use of a Cryptographically Weak Pseudo-Random Number Generator. This weakness is familiar in principle but particularly dangerous when the output controls authentication. Pseudo-randomness is sufficient for simulations, animation, randomized UI behavior, or other non-security tasks. It is not sufficient for cryptographic keys, session identifiers, password-reset tokens, CSRF secrets, or anything else where predictability becomes equivalent to authorization.

Horizon3’s technical research showed that the flaw was especially exploitable because the same PRNG that influenced the signing key also produced values observable through the unauthenticated SRP login process. That combination converts weak randomness from a theoretical weakness into a practical state-recovery attack. A poor random generator is dangerous; a poor random generator whose outputs are simultaneously leaked to the attacker is much worse.

The administrative functionality available after session forgery makes the authentication bypass immediately useful. Horizon3 noted that HFS allows administrators to define custom endpoints through the server_code configuration feature, which can execute arbitrary JavaScript on the server. Once an attacker has forged an administrator session, this legitimate feature becomes the final step from authentication bypass to operating-system compromise.

That is an important broader security principle: vulnerabilities become more dangerous when they cross into powerful administrative features that are behaving exactly as designed. The RCE does not necessarily require a second memory-corruption bug or another exotic exploit. The application already gives legitimate administrators a code-execution mechanism. The attacker’s job is therefore simply to convince the application that they are an administrator.

This makes the practical attack chain much shorter than many enterprise compromises. A vulnerable Internet-facing HFS instance can potentially move from no credentials to administrative application access to server-side code execution without phishing, malware delivery, password reuse, or local privilege escalation. The complexity lies in reconstructing the PRNG state, but once public exploit logic exists, that complexity is largely transferred from the attacker to the exploit code.

That change is exactly why the timing matters. The vulnerability was patched in July, but a public Python proof of concept was released in late September, followed by Horizon3’s detailed technical publication on September 30. VulnCheck says its infrastructure observed exploitation attempts on October 1, just one day later, including an actor in China targeting real vulnerable systems in the United States.

That timeline illustrates the increasingly short gap between technical disclosure and active exploitation. Once a vulnerability has three characteristics, the attacker’s economics become extremely favorable: Internet reachable, unauthenticated, and reliable post-authentication code execution. Public exploit code then removes much of the remaining research cost.

The lesson for vulnerability management is straightforward: the meaningful deadline was not when exploitation was confirmed. It was when the patch became available.

Organizations still running HFS 3.2.0 or earlier after the public exploit release should assume that opportunistic scanning is likely. The product is specifically designed as an HTTP file server, which means many deployments are intentionally reachable from external networks. That natural exposure makes inventory and patching especially important.

Administrators should upgrade to HFS 3.2.1 or later immediately. Where immediate upgrade is impossible, the vulnerable service should be removed from Internet exposure or restricted behind VPN, network ACLs, or another trusted access layer until remediation is complete.

Because exploitation has already been observed, exposed systems should also receive compromise assessment, not merely version upgrades. If an attacker successfully forged an administrator session before the system was patched, upgrading afterward closes the original vulnerability but does not reverse configuration changes or remove anything deployed through server_code.

Administrators should review HFS configuration for unexpected server_code entries, unfamiliar administrator accounts, newly added custom endpoints, and other unauthorized administrative changes. Access and authentication logs should be examined for repeated unauthenticated login requests followed by administrator activity from the same or related source addresses.

That behavioral sequence is valuable because a successful exploit may leave an unusual pattern: numerous login interactions used to collect PRNG output followed by an apparently valid administrator session even though no legitimate administrator authenticated. From the application’s perspective the forged cookie can look legitimate because the attacker has recovered the correct signing secret. The suspicious part may therefore lie in the sequence around the session rather than in the cookie itself.

The presence of apparently valid authentication after abnormal unauthenticated probing is a useful lesson far beyond HFS. Security monitoring often assumes that successful authentication is inherently less suspicious than failed authentication. In attacks involving token forgery, stolen sessions, compromised signing keys, or SSO abuse, that assumption fails completely. The attacker’s session may validate perfectly because the trust mechanism itself has been compromised.

Organizations should therefore correlate authentication success with surrounding behavior: where the session came from, what preceded it, what actions followed it, and whether that identity normally performs those administrative tasks.

HFS administrators should also invalidate active sessions after upgrading and rotate relevant administrative credentials, even though password theft is not required for this exploit. That helps remove any residual attacker access established before remediation and provides a clean trust boundary after the vulnerable session mechanism has been replaced.

If there is evidence that server_code was modified or arbitrary JavaScript was executed, incident response needs to expand beyond the HFS application. At that point the attacker may have obtained server-level execution, meaning responders should review processes, persistence, scheduled tasks, newly created users, outbound network connections, filesystem changes, credentials stored on the host, and any additional services reachable from that system.

The server should no longer be treated merely as a compromised file-sharing application. It should be treated as a potentially compromised operating system.

That distinction matters particularly because file servers often contain exactly the information an attacker wants after gaining execution: internal documents, backups, software packages, customer files, credentials stored in scripts, and archives copied there because somebody once decided a convenient share was an acceptable long-term storage strategy.

CVE-2026-61500 is also noteworthy because Rejetto HFS has already experienced serious exploitation activity in the past. CVE-2024-23692, a critical template-injection flaw affecting earlier HFS deployments, was exploited by multiple threat actors to deliver cryptocurrency miners, trojans, and HATVIBE malware. The recurrence reinforces the need to treat exposed file-sharing services as high-value perimeter systems rather than simple utilities.

The new vulnerability is technically different. CVE-2024-23692 involved template injection; CVE-2026-61500 attacks the session trust model through predictable randomness. But operationally, both reach a similar outcome: an Internet-facing file server becomes a direct route to attacker-controlled execution.

One especially interesting aspect of this vulnerability is its discovery. Horizon3 says the authentication weakness was identified using Anthropic’s Mythos model as part of Project Glasswing. Their research harness used multiple specialized agents to search for vulnerability classes, with a cryptographic-weakness agent identifying the Math.random() authentication problem and the chain into administrative code execution.

The responsible lesson from that is not that AI can magically discover every vulnerability. It is that AI-assisted vulnerability research is beginning to reduce the cost of identifying subtle security relationships across source code. Here, the useful insight required connecting several separate facts: a non-cryptographic generator, output leakage during login, session signing dependent on that generator, and an administrative API capable of arbitrary code execution.

None of those pieces alone necessarily produces the full attack.

The vulnerability exists in the chain.

That is similar to how human vulnerability researchers operate, but AI systems increasingly allow multiple lines of investigation to be pursued in parallel. For defenders and software vendors, this means the practical lifetime of latent vulnerabilities may shorten as automated research becomes better at connecting implementation weaknesses that have existed unnoticed for years.

This also raises the bar for secure software development. Developers can no longer assume that an implementation mistake is safe merely because discovering a reliable exploit requires substantial specialist effort. The economics of vulnerability discovery are changing.

The underlying coding lesson remains wonderfully old-fashioned, however: do not use Math.random() for cryptographic secrets.

Security-sensitive randomness should come from a cryptographically secure random-number generator designed to resist prediction even when an attacker observes other output from the system. In Node.js environments, that generally means APIs backed by the crypto module rather than application-level pseudo-random functions intended for ordinary programming tasks.

The deeper architectural lesson is equally important: avoid allowing the same randomness source to influence sensitive secret material while exposing related outputs to unauthenticated users. Even strong primitives can be undermined when state is reused carelessly across security boundaries.

The incident also illustrates why session-signing keys deserve the same protection as passwords and private keys. Applications often treat them as an internal implementation detail, but if an attacker obtains the signing secret, they can potentially manufacture identities the application has no way to distinguish from legitimate ones.

A compromised session-signing key changes authentication from:

“Did this user prove their identity?”

to:

“Can the attacker construct a token that passes our mathematical check?”

Once the answer to the second question is yes, the application’s normal authorization logic becomes almost irrelevant.

The full attack can therefore be summarized as: Internet-facing HFS 3.0.0–3.2.0 → unauthenticated login requests expose predictable PRNG output → attacker reconstructs V8 Math.random() state → session-signing key recovered → administrator cookie forged → admin API accessed → server_code feature modified → arbitrary JavaScript executed → server compromise.

The vulnerability is a useful reminder that authentication systems are only as strong as the secrets underneath them. HFS could correctly verify every cookie it received and still fail completely because the attacker learned how to generate a cookie that was cryptographically valid according to the application’s own rules.

That is what makes CVE-2026-61500 particularly instructive.

The attacker does not break the authentication check.

They learn how to pass it legitimately with a session that should never have existed.

For exposed HFS deployments, the response should therefore be immediate: upgrade to 3.2.1 or later, remove vulnerable systems from public reach until patched, invalidate existing sessions, inspect administrative configuration, and investigate any system that was exposed after public exploit details became available.

The patch closes the weakness.

The logs determine whether someone already used it.

A critical security flaw impacting Rejetto HTTP File Server (HFS) is witnessing active exploitation attempts, according to VulnCheck. The vulnerability in question is CVE-2026-61500 (CVSS score: 9.3), a case of session forgery stemming from the use of a weak pseudo-random number generator (PRNG) that can lead to a predictable key, which an attacker can then use to gain unauthorized access and

Source: Attackers Target Rejetto HFS Flaw That Enables Admin Session Forgery and RCE via The Hacker News — published 05 Oct 2026.