AI-aided HFS flaw moves from crypto finding to active exploitation

What is affected

CVE-2026-61500 affects Rejetto HFS 3.x versions before the fixed release identified in defender guidance as 3.2.1. Windows Forum and Threadlinqs advised upgrading to 3.2.1. Threadlinqs also classified the vulnerability as actively exploited and summarized indicators, affected versions, MITRE ATT&CK mappings and the disclosure-to-exploitation timeline.²³

Rejetto HFS is a lightweight HTTP file server often used in smaller environments, labs, personal infrastructure and edge-adjacent file-sharing workflows.

That profile matters. Projects in this category may be internet-exposed, operationally useful and under-resourced compared with larger enterprise platforms. They also may lack mature vulnerability-management pipelines, making rapid exploit development especially consequential.

How the exploit chain works

The reported issue centers on session signing. HFS used values derived from JavaScript’s Math.random() in a way that made a signing key predictable. If attackers can recover enough of the pseudorandom generator’s state, they can predict or reconstruct material needed to forge an administrator session.²³

Reports credit Mythos with helping Horizon3 reason through the mathematical path: linking weak pseudorandom-number generation to a separate leak, using Z3 to solve the state-recovery problem, and converting the result into a demonstrable exploit chain.⁵ QPulse similarly described the attack path as pseudorandom-number-generator state recovery leading to critical exploitation risk.⁷

Once attackers can impersonate an administrator, the risk extends beyond authentication bypass. HFS administration features can become a bridge to remote code execution, making the flaw dangerous for any internet-facing deployment that remains unpatched.²³

Exploitation timeline narrowed to days

The patch and exploitation timeline is the central operational lesson. Defender-oriented coverage described the fix as available in July, with exploitation monitoring surfacing in October.³ VulnCheck said it began seeing exploitation on October 1. The Register reported that early exploitation infrastructure was China-hosted, with targets in the United States and Japan.¹

LavX News reported the same broad sequence: Horizon3 and Mythos were tied to the exploit-development story, and VulnCheck later detected exploitation activity, including reported IP infrastructure.⁴ DiarioBitcoin also reported U.S. and Japan targeting and noted follow-on U.S. proxy IPs in activity described by VulnCheck.⁶

The result is a short runway for defenders. Once the cryptographic weakness was publicly understood as exploitable, internet-facing instances became candidates for scanning, session forgery and post-authentication exploitation.

Why AI assistance changes the defender model

Security teams have long assumed that some classes of vulnerability require specialized human skill to weaponize. Cryptographic flaws, PRNG state recovery and constraint-solving paths often fell into that category. CVE-2026-61500 challenges that assumption.

According to the reports, Mythos did not merely point to suspicious code. It helped connect implementation details into an exploit strategy. That places it in a different operational category from automated linting or pattern matching.

For defenders, the important shift is that AI systems can reduce the time and expertise needed to move from “this looks weak” to “this can be exploited.”⁵⁷

The Register noted that this is reportedly the second Mythos- or Project Glasswing-linked CVE known to be exploited in the wild, framing the incident as part of a broader pattern rather than a one-off demonstration.¹

Whether or not AI systems independently discover a given vulnerability, their ability to accelerate exploit reasoning may increase pressure on patch windows, especially for smaller open-source projects with limited maintainer capacity.

What security engineering teams should do

Teams running Rejetto HFS should identify all HFS 3.x deployments, prioritize internet-facing systems and upgrade to version 3.2.1 or later where applicable.²³

If immediate upgrade is not possible, teams should remove public exposure, restrict access through VPN or allowlists, rotate relevant credentials and session material where feasible, and review administrative actions for evidence of unauthorized access.

Detection teams should look for suspicious administrator-session creation, unexpected configuration changes, unusual file-server process behavior, child processes spawned by the HFS service, and outbound network activity following admin access. Threadlinqs’ entry includes indicators and MITRE ATT&CK mappings that can be incorporated into threat-hunting workflows.²

More broadly, vulnerability-management programs should treat AI-assisted exploitability analysis as a prioritization factor. Bugs involving weak randomness, authentication tokens, signing keys, serialization, template execution, upload handling or admin-session logic should be triaged aggressively when they affect internet-exposed open-source infrastructure.

Smaller projects face a faster exploit economy

The HFS case shows how AI assistance can compress multiple stages of the vulnerability lifecycle: source review, mathematical reasoning, exploit construction, public awareness and exploitation monitoring.

Smaller open-source infrastructure projects are particularly exposed to that compression because their code is accessible, their deployment footprint can be difficult to inventory, and their users may not track security advisories closely.

For security engineering teams, the lesson is concrete: do not wait for mass exploitation before acting on cryptographic or authentication-bypass flaws in exposed infrastructure.

CVE-2026-61500 shows that once AI-assisted analysis turns a subtle weakness into a working exploit path, defenders may have only days — or less — before exploitation activity appears in telemetry.