CVE-2026-61500: AI-Discovered Rejetto HFS Authentication Bypass Exploited in the Wild

CVE-2026-61500 has become one of the more interesting vulnerability stories of 2026, not just because it gives an unauthenticated attacker a path toward remote code execution, but because of how the flaw was discovered and how quickly the risk moved from research into real-world exploitation.

The vulnerability affects Rejetto HTTP File Server, or HFS, versions 3.0.0 through 3.2.0. At its core, the flaw comes from HFS using JavaScript’s Math.random() in the generation of a secret used to protect authenticated session cookies. Because the application also exposes other values derived from the same pseudo-random number generator to unauthenticated users, an attacker can gather enough information to reconstruct the generator’s internal state, recover the cookie-signing secret, and create a session that HFS accepts as belonging to an administrator.

That would already be a serious authentication failure. In HFS, however, administrator access can be turned into something worse. Horizon3.ai found that authenticated administrative functionality can be used to execute server-side JavaScript, creating a practical chain from an unauthenticated network request to remote code execution. Horizon3

The vulnerability is rated critical, with VulnCheck assigning CVE-2026-61500 a CVSS 4.0 score of 9.3 and classifying it under CWE-338: Use of Cryptographically Weak Pseudo-Random Number Generator. The first fixed version is HFS 3.2.1. VulnCheck

The bigger reason defenders should pay attention now is that CVE-2026-61500 is no longer simply an interesting AI-generated research finding. VulnCheck says its Canary Intelligence infrastructure began observing exploitation attempts on October 1, 2026, one day after Horizon3 published a detailed technical analysis of the vulnerability. VulnCheck has since added the issue to its own Known Exploited Vulnerabilities dataset. Horizon3

What Is CVE-2026-61500?

CVE-2026-61500 is best understood as a session-forgery vulnerability caused by predictable cryptographic material.

Most modern web applications need some way to remember that a user has already authenticated. One common approach is to issue a session cookie and cryptographically sign it with a secret known only to the server. When the browser later sends that cookie back, the application verifies its signature before trusting the session information.

That architecture works only if the signing key remains unpredictable.

If an attacker obtains the signing key, the entire security assumption changes. They no longer need to steal an existing session cookie or discover the administrator password. They can generate their own session data and calculate a valid signature themselves.

According to Horizon3’s research, HFS generated the secret used by the Koa web framework’s cookie-signing mechanism using Math.random(). Koa then relied on that value through Keygrip to sign HFS session cookies. Horizon3

The use of Math.random() is the crucial mistake.

자바스크립트의 Math.random() is designed to produce values that look random enough for normal application tasks. It is not intended to generate passwords, cryptographic keys, authentication tokens, password-reset links, or other secrets whose unpredictability forms a security boundary.

That distinction is what CVE-2026-61500 turns into an exploit.

Why Math.random() Was Dangerous Here

It is important not to oversimplify the vulnerability into “Math.random is insecure.”

Plenty of applications use Math.random() without creating a remotely exploitable security bug. If a website uses it to shuffle a list, vary a UI animation, or generate disposable test data, predictability usually does not matter.

The problem starts when a predictable random-number generator is used to produce security-sensitive information.

Even then, exploitation is not automatic. An attacker normally still needs some way to observe enough information about the pseudo-random number generator to reconstruct its behavior.

HFS provided both sides of that equation.

Horizon3 found that the vulnerable HFS authentication flow exposed values generated from the same V8 pseudo-random number generator used earlier to construct the session-signing secret. That meant an unauthenticated attacker could interact with the login process and collect information about the generator without first having a valid account session. Horizon3

At that point, the issue becomes much more serious.

The application has generated a secret using a deterministic PRNG.

The application later exposes other outputs from the same PRNG.

If the attacker can reconstruct the internal PRNG state from those visible outputs, values that were assumed to be secret may become recoverable.

That is the central idea behind CVE-2026-61500.

Recovering the HFS Session Signing Key

The V8 JavaScript engine used by Node.js has historically implemented Math.random() using deterministic pseudo-random algorithms. Horizon3’s analysis of the vulnerable environment focused on the xorshift128+ behavior involved in the HFS attack chain. Horizon3

A pseudo-random number generator is not truly random in the cryptographic sense. It maintains internal state and calculates new outputs from that state. If an attacker can recover enough information about the state, future—and in some cases earlier—outputs can be reconstructed.

This is where the vulnerability becomes considerably more interesting than a normal insecure-randomness finding.

Horizon3 reports that Anthropic’s Mythos system identified not only the unsafe use of the PRNG for cookie-signing material, but also a separate mechanism through which values from the same PRNG stream could be exposed.

The research then used mathematical constraint solving to bridge the two behaviors. Horizon3 describes the use of the Z3 solver to recover the relevant PRNG state and work backward toward the random value created when the HFS process started. Horizon3

The result was recovery of the secret used to protect HFS sessions.

Independent public reproduction work has since confirmed the underlying chain against vulnerable HFS 3.2.0 and shown that the same technique stops working against the patched HFS 3.2.1 behavior. GitHub

This is an important distinction: the researchers were not simply guessing an administrator cookie.

They were reconstructing the secret that allowed HFS itself to decide whether a cookie should be trusted.

From Session Forgery to Administrator Access

Once the attacker knows the cookie-signing key, traditional authentication largely stops mattering.

The attacker can construct session information representing an administrator, sign it correctly, and send it to the target server. Because the signature is valid, HFS has no cryptographic reason to distinguish the forged session from one issued after a legitimate login.

VulnCheck summarizes CVE-2026-61500 as allowing a remote attacker to gather a small amount of information from login responses, reconstruct the PRNG state, recover the signing key, and forge a valid administrator session. VulnCheck

Notice what the attack does not require.

It does not require the administrator password to be weak. It does not depend on credential stuffing. It does not require phishing. It does not require a legitimate low-privileged account.

The attacker goes underneath the password check and attacks the mechanism that represents authenticated state after login.

That also means simply changing the administrator password is not sufficient remediation for CVE-2026-61500. If the vulnerable HFS version remains exposed, the underlying session-signing weakness remains present.

Why CVE-2026-61500 Can Become Remote Code Execution

An authentication bypass is only as valuable as the privileges it unlocks. In HFS, those privileges are significant.

During the research, Mythos and Horizon3 identified HFS administrative functionality capable of defining custom server behavior and executing JavaScript. Horizon3 specifically describes the administrative API as exposing functionality through which arbitrary JavaScript can ultimately be executed. Horizon3

That transforms the impact of CVE-2026-61500.

Conceptually, the attack chain becomes:

Unauthenticated access → PRNG information leakage → internal state recovery → signing-key reconstruction → forged administrator session → access to administrative functionality → server-side code execution

This is why describing CVE-2026-61500 simply as an “authentication bypass” understates its operational significance.

The immediate weakness is session forgery.

The realistic end result can be remote code execution.

For an internet-facing file server, that means successful exploitation should be treated as potential compromise of the host rather than merely compromise of an HFS account.

Once arbitrary code can be executed, the security boundary has moved beyond the web application. Depending on the privileges and environment of the HFS process, an attacker may be able to access locally stored files, credentials, mounted shares, environment variables, other services, or network-accessible systems.

Why the AI Discovery of CVE-2026-61500 Matters

The AI angle is not just marketing attached to an otherwise ordinary CVE.

Horizon3 joined Anthropic’s Project Glasswing in July 2026 and incorporated Mythos into its vulnerability research pipeline. According to Horizon3, its harness launches specialized research agents targeting different vulnerability classes across a codebase. A cryptographic weakness analysis agent driven by Mythos identified the HFS authentication issue. Horizon3

What happened afterward is arguably more interesting than the initial finding.

Spotting Math.random() near an authentication mechanism is something an experienced security engineer might do during code review. That alone does not establish a critical vulnerability. A human researcher would still need to determine whether any related PRNG outputs are observable, understand how the runtime implements the generator, model its internal state, determine whether the state can be reconstructed, work backward toward the signing key, and then establish meaningful security impact.

That is a long research chain.

Horizon3 says Mythos independently identified the other PRNG leak needed to turn the theoretical weakness into an exploitable condition and investigated the mathematical approach required to solve it. Horizon3

That is the part of CVE-2026-61500 that deserves attention from the wider security industry.

AI vulnerability research is moving beyond finding obviously dangerous functions or reproducing conventional bug patterns. Systems are increasingly capable of maintaining a hypothesis over a longer investigation and connecting individually unimpressive weaknesses into an attack path.

In this case, insecure randomness by itself was not enough.

PRNG leakage by itself was not enough.

Administrator functionality capable of running JavaScript was not enough.

The vulnerability emerged because those components could be chained together.

AI Changes the Economics of Vulnerability Research

Horizon3 also makes a useful point about why a flaw such as CVE-2026-61500 might historically have remained unexplored.

Human vulnerability researchers operate under time constraints. Finding a suspicious cryptographic implementation is one thing; spending hours or days proving that it can actually be exploited is another.

A researcher looking at Math.random() may recognize immediately that the design is questionable, yet still decide not to pursue it. Proving the real impact could require knowledge of JavaScript engine internals, PRNG behavior, mathematical state reconstruction, cryptographic signing, application logic, and exploit development.

There is no guarantee that the investigation will succeed.

From a human research perspective, that makes the opportunity cost high.

Horizon3 explicitly notes that its own researchers had previously abandoned cryptographic weaknesses because they lacked the necessary mathematical specialization or because the time required to prove exploitability did not make economic sense. The company argues that Mythos changes that calculation because the system can pursue those technically expensive branches without the same human-time constraints. Horizon3

That may turn out to be the biggest long-term implication of CVE-2026-61500.

AI does not need to invent entirely new classes of vulnerabilities to transform security research. It can make existing hard-to-investigate bug classes cheaper to pursue.

That potentially changes which vulnerabilities become economically viable to weaponize.

From Public Research to Active Exploitation

The timing around CVE-2026-61500 makes the story more consequential.

Horizon3 published its detailed technical analysis on September 30, 2026. The following day, October 1, VulnCheck Canary Intelligence began observing activity associated with exploitation of the vulnerability. Horizon3

It would be too strong to claim that Horizon3’s publication directly caused those attacks. Attackers could have developed the vulnerability independently, obtained knowledge elsewhere, or already been experimenting with it.

What the timeline does show is how dangerous it has become for defenders to rely on a comfortable gap between disclosure and exploitation.

That gap may now be extremely short.

Once a technical explanation establishes the important components of an exploit, modern tooling makes it easier to transform research into repeatable attack infrastructure. AI-assisted coding and security systems can compress that process further.

VulnCheck consequently added CVE-2026-61500 to its KEV dataset after observing exploitation. VulnCheck Documentation

For organizations still running a vulnerable HFS instance, the question should therefore no longer be whether somebody eventually develops an exploit.

That stage has passed.

How Large Is the Rejetto HFS Attack Surface?

Rejetto HFS is not deployed at anything approaching the scale of Microsoft Exchange, Citrix NetScaler, Ivanti appliances, or major enterprise VPN products.

VulnCheck estimated that its Target Intelligence system could identify roughly 100 internet-facing HFS instances around the time it reported active exploitation. VulnCheck Documentation

That number should not be read as a definitive count of vulnerable servers worldwide. Internet-scanning visibility changes constantly, and different datasets will identify different populations.

It does, however, suggest a relatively compact target set.

That does not necessarily make exploitation less attractive.

For an attacker, a small number of targets can still be worthwhile if vulnerable servers are easily identifiable and exploitation can be automated. A remotely reachable service with an unauthenticated path toward administrator access and code execution requires much less effort than an attack that depends on social engineering or valid credentials.

HFS also has history here. Horizon3 notes that the older CVE-2024-23692 affecting HFS became a known exploited vulnerability and involved unauthenticated template injection leading to RCE. Horizon3

Attackers therefore already have reason to monitor internet-facing HFS deployments.

What Changed in HFS 3.2.1?

HFS 3.2.1 is the first release that fixes CVE-2026-61500.

Independent validation of the patch shows two particularly important changes. Instead of generating the signing key using Math.random(), the fixed implementation uses Node.js cryptographic randomness through randomBytes(). The exposed numeric login identifier was also replaced with a UUID-based mechanism. GitHub

Those changes address both sides of the attack chain.

The security-sensitive key is no longer derived from the predictable PRNG, and the authentication flow no longer provides the same useful observation point for reconstructing that generator.

This is the correct kind of fix. Increasing the number of calls to Math.random() or making the generated value longer would not solve the fundamental problem. A cryptographic secret needs to originate from a cryptographically secure source.

Administrators running HFS 3.0.0 through 3.2.0 should therefore upgrade immediately to at least 3.2.1, and preferably to an appropriate current HFS release rather than remaining on the minimum patched version. The upstream Rejetto project continues to publish newer 3.x releases. GitHub

Detecting Possible CVE-2026-61500 Exploitation

CVE-2026-61500 is not the easiest vulnerability to detect solely from a single malicious request because the attacker interacts with legitimate HFS authentication mechanisms before the forged session appears.

Defenders should therefore think in terms of behavior and sequence rather than searching only for one exploit string.

Repeated unauthenticated interactions with the login flow from an unfamiliar internet address can be useful context, particularly when they are followed by an administrator session that cannot be correlated with a legitimate login.

The most important signal comes after authentication.

Administrators should review HFS configuration history, administrative API activity, and any unexplained changes to functionality capable of executing server-side code. Horizon3 specifically identified HFS’s server_code functionality as the final mechanism through which forged administrative access could be translated into code execution. Horizon3

Host telemetry matters as well.

If a vulnerable server was exposed to the internet during the exploitation window, defenders should investigate unexpected processes, outbound connections, modifications to application configuration, newly created files, unusual scheduled tasks, unexplained persistence mechanisms, and suspicious access to credentials or mounted storage.

The absence of an obvious exploit payload in web logs is not sufficient evidence that the system was not compromised.

Incident Response Should Go Beyond Changing the Password

One of the easiest mistakes to make with CVE-2026-61500 would be to treat it as a stolen-credential incident.

Changing the HFS administrator password is good hygiene after suspected compromise, but it does not repair this vulnerability.

The attacker does not need to know that password.

They are creating authentication state that the server itself accepts because it carries a valid signature.

The vulnerable software therefore needs to be upgraded.

If exploitation is suspected, existing sessions should be invalidated and the investigation should determine whether the attacker reached administrative functionality or achieved server-side code execution.

Once RCE becomes plausible, the scope of incident response must expand beyond HFS itself.

Secrets available to the process, files accessible to the account running HFS, connected storage, API credentials, authentication tokens, and reachable internal systems may all need to be reviewed.

In other words, a confirmed successful CVE-2026-61500 exploitation attempt should be handled as a potential host compromise, not merely an application login anomaly.

CVE-2026-61500 Is a Warning About AI-Assisted Exploitation

There is a larger security lesson hiding behind the Rejetto HFS bug.

Much of the conversation around AI and cybersecurity has focused on whether models can discover zero-days. That question is increasingly becoming less interesting than what happens afterward.

The harder problem is often connecting a bug to meaningful impact.

A suspicious line of code might generate thousands of findings. What matters is whether an attacker can construct a reliable path from that weakness to authentication bypass, privilege escalation, data access, or code execution.

Horizon3’s experience with Mythos suggests that AI systems are becoming better at performing exactly that kind of long-horizon reasoning. The company has separately argued that the major change introduced by systems like Mythos is not necessarily a new vulnerability taxonomy, but a compression of the time and cost required to turn vulnerabilities into usable attack paths. Horizon3

CVE-2026-61500 is a particularly clean example.

A human auditor might flag Math.random().

A more determined researcher might notice that related outputs are visible.

Another specialist might understand how the V8 PRNG can be modeled.

Someone else might connect the recovered signing key to session forgery.

Finally, an application-security researcher might notice that authenticated administrative functionality exposes code execution.

Mythos helped connect those ideas into one coherent exploitation story.

That changes the economics of vulnerability research.

Weaknesses that previously sat in the uncomfortable category of “probably insecure, but too expensive to prove” may receive considerably more attention when autonomous research systems can pursue dozens of those hypotheses at once.

Final Assessment

CVE-2026-61500 should now be treated as a critical, actively exploited Rejetto HFS vulnerability, not merely an interesting demonstration of AI-assisted vulnerability discovery.

The affected HFS 3.x releases use a non-cryptographic pseudo-random number generator in the creation of session-signing material while exposing related PRNG output through unauthenticated authentication behavior. That combination allows the generator state to be reconstructed and the cookie-signing key to be recovered. An attacker can then forge an administrator session without knowing the administrator password. Horizon3

Because HFS administrative functionality can execute server-side JavaScript, the authentication bypass can ultimately provide a route to remote code execution.

HFS 3.2.1 fixes the issue, and organizations still running versions from 3.0.0 through 3.2.0 should upgrade rather than relying on password changes or perimeter defenses alone. VulnCheck

But CVE-2026-61500 is likely to remain interesting long after vulnerable HFS installations have been patched.

It demonstrates a change in vulnerability research that is becoming difficult to ignore. AI did not merely point to an obviously dangerous API call. In this case, it helped connect weak randomness, leaked PRNG outputs, mathematical state reconstruction, session forgery, administrative privilege and server-side code execution into a complete attack path.

Horizon3 published the technical research on September 30. VulnCheck began seeing exploitation on October 1. Horizon3

That one-day transition is the part defenders should remember.

The vulnerability itself is serious. The speed at which vulnerabilities like CVE-2026-61500 can move from complicated research problem to operational attack technique may be the bigger story.