Rejetto HFS is a small HTTP file server that a lot of people run to share files without standing up anything larger. Versions 3.0.0 to 3.2.0 carry CVE-2026-61500, scored 9.8 under CVSS 3.1 and 9.3 under CVSS 4.0, filed under CWE-338 — use of a cryptographically weak random number generator.

It is fixed in 3.2.1. The current stable release is 3.3.4.

Two mistakes, one generator

The session cookies that say who you are signed in as are signed with a secret key. HFS generated that key with JavaScript's Math.random.

That is a known mistake on its own. Node's V8 engine implements Math.random with xorshift128+, which is fast, not cryptographic, and — the part that matters — reversible. Given enough consecutive outputs, the generator's internal state can be reconstructed, and from the state every past and future number follows.

The second mistake is what makes the first one usable. HFS's login handshake, which anyone can start without credentials, hands back values drawn from that same generator.

So the attack writes itself. Start logins, collect the numbers, recover the state, derive the signing key, and mint a cookie that says the user is admin — signed exactly the way the server signs its own. Point it at an admin-only endpoint and the server returns a clean response to someone who never had an account.

Either mistake alone is survivable. A weak key nobody can observe is a bad idea that holds; leaked random numbers with nothing depending on them are noise. The vulnerability is the pairing, which is the same shape as FortiMail's path check disagreeing with its file write and the iCloud parsers disagreeing about where a header ends.

From admin session to code execution

Forging the session is the whole flaw. What follows is a documented product feature.

HFS lets an administrator register a JavaScript snippet that the server runs. It is there so operators can extend behaviour, and it is perfectly reasonable to offer an administrator. An attacker holding a forged administrator session writes a configuration containing their own snippet, and it executes with the privileges of the server process — which, on plenty of installations, is root.

No memory corruption, no exploit chain, no bypass of any hardening. The attacker becomes an administrator and then uses the feature administrators have.

What the model actually contributed

Horizon3 found this, and found it using Anthropic's Mythos model. Its researchers published the technical write-up and a proof of concept on 30 September 2026.

The claim worth looking at is not that a model found a bug. It is what Horizon3 says the model connected. In its own words, Mythos did not just flag the insecure generator in isolation — it simultaneously identified that the application leaked raw Math.random outputs through a separate code path.

That is the real work here. Flagging Math.random used for a secret is something a static analyser does and a reviewer does on sight; it is on every checklist. Noticing that a different, unauthenticated function elsewhere in the codebase hands an attacker the observations needed to exploit it requires holding both halves in mind at once, and that is where human review fails on a codebase nobody has time to read end to end.

So this is a narrow and real capability claim: not invention, but reach across a whole program. It is also one data point from one vendor on its own tool, and worth reading as that.

Days, not months

The write-up and proof of concept went out on 30 September. Within days, VulnCheck reported active probing — reconnaissance from a China Telecom address, aimed at deployments in Japan and the United States.

Nobody has reported a confirmed compromise or post-exploitation activity yet. Scanning is not exploitation, and the gap between them is where defenders still live.

But set the dates beside the figure from Microsoft's report last week, which put the median time from discovery to weaponisation well below 24 hours, against 30 to 60 days of enterprise remediation. This is that arithmetic in one case: a tool that compressed finding, a public proof of concept that removed developing, and the only slow step left is the one the defender owns.

What to do

  • Upgrade to 3.2.1 at minimum, 3.3.4 for current. There is no workaround worth running instead.
  • Take exposed instances off the internet while you do it. HFS is frequently stood up for one transfer and then forgotten, so the risk is not what you run deliberately but what somebody started in 2023.
  • Treat an HFS reachable from outside as suspect. Check the configuration for a server_code snippet nobody added, and look for admin-only endpoints answering requests with no preceding login.
  • If you build software, the lesson is narrower than do not use Math.random. It is that any value an unauthenticated caller can observe has to come from a different generator than anything you sign with.

What is not established

  • Whether anyone has successfully exploited this. Only scanning has been reported.
  • How many internet-facing HFS instances are on affected versions.
  • Who is behind the probing. An address in one country is a starting point, not an attribution.
  • How much of the finding was the model and how much was the researchers framing the question, which only Horizon3 can say.