HFS could accept a forged login even when nobody knew the password

A password can be long, unique and carefully guarded, yet fail to protect an account if the application trusts a forged record of a successful login. That is the uncomfortable lesson in a recently detailed HFS vulnerability. The problem sits in the machinery that lets a website remember who you are after sign-in, a part of security that most people never see.

VulnCheck’s advisory for CVE-2026-61500 covers the file-sharing software Rejetto HTTP File Server versions 3.0.0 through 3.2.0. It describes an authentication bypass involving predictable session-signing secrets, with potential administrative access and remote code execution: making the host computer run unauthorized code. The corrected release is 3.2.1. This concerns the 3.x product line; it should not be confused with separate vulnerabilities in older HFS software.

VulnCheck’s HFS vulnerability advisory

The login is only the beginning of the conversation

A browser usually does not ask you to type your password for every page. After authentication, a web application uses a session to connect later requests with the same signed-in user. A cookie is one way the browser carries the information needed for that continuity. OWASP explains why session security is part of authentication: someone able to impersonate a valid session can acquire the access attached to it.

OWASP’s session management guidance

Think of arriving at a conference, showing identification and receiving a badge. The identity check happens at registration; staff at the meeting rooms rely on the badge afterward. If convincing badges can be manufactured elsewhere, making the registration desk demand a better passport does not solve that separate problem. A web session serves a similar convenience, although the actual protection is mathematical rather than a badge's appearance.

Some session systems keep their authoritative records on the server. Others place information in the browser and attach a cryptographic signature so the server can detect unauthorized changes. A signature is a check on authenticity, not a promise that the attached information is hidden. For a shared-secret signing scheme, protecting the secret is what prevents an outsider from making information look server-approved.

Koa’s documentation for signed cookies and signing keys

Zach Hanley’s September 30 Horizon3.ai research describes HFS using a value from JavaScript’s Math.random() as its cookie-signing key. The team demonstrated that the weakness could defeat session authentication and reach code execution through administrative functionality. Horizon3 credits research using Anthropic’s Mythos model. This establishes a demonstrated vulnerability; the research publication alone is not evidence that a business was breached.

Zach Hanley’s original HFS research

Looking random is not the same as protecting a secret

Random values have many ordinary uses in software: choosing a visual variation, distributing a simulation or varying a nonsecurity task. Those jobs do not necessarily require the same guarantees as creating a secret. Mozilla’s JavaScript documentation explicitly says Math.random() is unsuitable for cryptographic security.

Mozilla’s documentation of Math.random()

The useful distinction is between something that looks irregular to a person and something designed to resist prediction by an adversary. A shuffled playlist can be perfectly satisfactory even if a determined observer can work out its pattern. The secret used to approve an administrator's session has a much harder job. Its value must remain impractical to predict even when someone understands how the software was written.

Adding more impressive-looking digits does not, by itself, fix the choice of generator. The question is where the uncertainty comes from and whether the tool was designed for security. Node.js provides cryptographic random-data generation for this purpose. That gives developers a supported building block; it does not mean every use of randomness in an application should be assembled into a homegrown authentication design.

Node.js cryptographic random-data documentation

For a business buying or deploying software, there is a practical way to discuss this without becoming a cryptographer. Ask whether authentication and session handling use maintained framework facilities and security-specific randomness. A reassuring demonstration of the normal login screen cannot answer that question. Normal use checks that the intended path works; the design also has to reject convincing-looking claims that did not come through that path.

July’s fix and October’s warnings describe different events

The maintainer released HFS 3.2.1 on July 13, 2026, warning that security defects in earlier releases could allow administrative access. The release credited Hanley, Claude and Anthropic Research. That is the date of the published fix, not a new update issued after the September research article.

HFS 3.2.1 release notes

In its October 2 report, VulnCheck said its Canary Intelligence network began observing exploitation activity for this CVE on October 1. That provides a direct observation from the company operating the sensors. The report does not identify a successfully compromised customer or establish the number of real installations that suffered damage.

VulnCheck’s October 2 activity report

Taken together, the dates describe an available repair, a later detailed explanation and subsequently reported attack activity. Calling the flaw newly discovered in September would erase the earlier advisory and release. Calling every observed attempt a successful intrusion would make a different mistake. A sensor seeing someone try a technique is enough reason to take the exposure seriously, but it is not a count of victims.

The file server may have a bigger job than its name suggests

HFS serves files from the computer running it and offers an administration interface and a plugin system. The project supports several operating systems, including Windows, Linux and macOS. That makes it useful for straightforward file sharing, but it also means the deployment may be a regular workstation rather than a dedicated appliance.

The HFS project’s product documentation

Picture a small office using a spare computer to send large project files to clients. If that computer also has access to other working folders or business services, the consequences of control over its file-sharing software deserve closer attention. This is an illustrative setup, not a reported HFS victim. The point is to evaluate the permissions of the process running the server, rather than assuming the visible download folder is the limit of an incident.

For an affected installation, move to a current release that includes the 3.2.1 fix. Treat 3.2.1 as the minimum correction for this particular issue, not a promise that an old build is the best version to deploy today. If updating cannot happen promptly, limiting network access or taking the service offline reduces immediate exposure while a replacement sharing arrangement is prepared.

If there are signs of unauthorized administration, preserve available records and involve whoever handles incident response before treating a restart as recovery. Review unexpected configuration changes and the host's condition, and address potentially exposed credentials and sessions in a coordinated containment plan. An update corrects vulnerable software; it cannot prove that earlier administrative access left nothing behind. Changing only the human administrator's password would also leave the central session-trust question unanswered.

Source check: October 8, 2026. ShortCircuit reviewed the maintainer release, VulnCheck’s advisory and sensor report, Horizon3’s research, and the linked technical documentation. Publicly observed attempts are distinguished from confirmed customer breaches. The examples and operational reasoning are our analysis.