Anthropic's Mythos Found a 9.3 in Rejetto HFS in July. The Exploit Went Public Sept 26, Probes Started Five Days Later, and Every Rule We Pulled From It Was Junk.
If you run Rejetto HTTP File Server version 3.0.0 through 3.2.0 on the internet, upgrade it today. CVE-2026-61500 lets a stranger forge an administrator session, and HFS administrators can make the server run their own code. The fix has been out since July 13. Somebody started probing for it around October 1. CISA has not listed it as exploited yet.
This bug matters for two reasons beyond HFS. It was found by an AI, Anthropic's Mythos model, working for the security firm Horizon3.ai. And it went from public exploit code to first attacker probes in about five days. We had that exploit code in our index 2 hours and 38 minutes after it appeared on GitHub. We also have to tell you that every detection rule our automated system pulled out of it was useless, and two of them are in our live feed.
What the bug is
HFS is a free file-sharing server, popular with hobbyists, small offices and, historically, malware operators who need a quick place to host files. Version 3 is written in JavaScript.
HFS 3.0.0 through 3.2.0 makes the secret key that signs session cookies with Math.random(), the browser-grade random number generator. Math.random() is fast and predictable. If you can see enough of its output, you can work out its internal state and predict everything it produced before and after. HFS also hands out values from that same generator to anyone who tries to log in, no account needed.
Put those two facts together and the chain is simple to describe. Collect login responses. Rebuild the generator's state. Recover the signing key. Sign your own administrator cookie. Then use the admin panel's server_code setting, which lets an administrator add custom JavaScript, to run code on the machine. CVSS score: 9.3.
Who found it, and why that part is the story
Horizon3.ai researcher Zach Hanley credits Mythos with the find. According to Horizon3's write-up, the model spotted both halves: the weak key and the leak that makes the weak key usable. Horizon3 put it this way: it "did not require follow-on prompting to find the disparate PRNG leak that made this theoretical issue a demonstrable one."
That sentence is the part worth sitting with. A weak random number generator in a key is a common finding and is often waved off as theoretical. What turns it into an exploit is a second, unrelated leak somewhere else in the code. Connecting the two is exactly the work that takes a human reviewer days. A model did it unprompted.
Mythos turned up again this week. Epic Systems paused most of its product development for about six weeks after Mythos testing found MyChart configurations that could let an outsider view patient records without the access showing up in the audit trail. No breach has been confirmed there. The same week, Google suspended submissions to its open-source bug bounty program because AI-generated reports were flooding it. Both are true at once: AI is finding real bugs, and AI is also burying the people who triage them.
The timeline, with every clock side by side
July 13: HFS 3.2.1 ships with the fix, and the CVE is published through VulnCheck. Horizon3 and Mythos are credited.
September 26, 15:23 UTC: a public proof-of-concept repository, aramosf/CVE-2026-61500, is created on GitHub. Its description: a PRNG session-forgery-to-RCE exploit with a Docker lab. That timestamp comes from GitHub's API.
September 26, 18:01 UTC: our exploit harvester, which crawls GitHub for new exploit code, indexes that repository. That is our own crawler's timestamp, 2 hours 38 minutes after the repository was created.
September 30: Horizon3 publishes its full technical write-up with its own exploit.
October 1 or 2, depending on the report: VulnCheck sees small-scale probing from a single China Telecom address against its canary servers in Japan and the United States. VulnCheck called it reconnaissance. As of October 5, nobody has reported a confirmed successful break-in.
October 4: CISA's Known Exploited Vulnerabilities catalog, version 2026.10.04, lists only two older HFS bugs, CVE-2024-23692 and CVE-2014-6287. CVE-2026-61500 is not on it.
What we are claiming, and what we are not
We are not claiming we found this bug. Mythos and Horizon3 did, in July. We are not claiming we saw exploitation. VulnCheck did, and our sensors could not have.
What we can claim is narrow, and the receipt is first-party. A working public exploit sat on GitHub for 2 hours and 38 minutes before our harvester picked it up. That was 4 days before Horizon3's detailed write-up and about 5 days before the first probes anyone reported. If you consume our feed, the exploit was in the index you search before the attacks started. That is the point of the harvester: the gap between "exploit code is public" and "someone uses it" is the window a small shop gets, and it is short.
What we got wrong in the same record
Our harvester does not just record that an exploit exists. It also reads the code and tries to pull out detection rules, things like request paths a defender could watch for. For this exploit it produced four rules: username at confidence 85, /usr/bin/env at 85, child_process | /bin/sh at 90, and username": "admin" at 90.
None of those detects this attack. username matches every login form on earth. /bin/sh and /usr/bin/env are what the exploit runs on the attacker's own machine, not something that travels over the wire to your server.
We checked what actually ships. Our STIX feed drops rules that have no path in them, so the two username rules never left the building. The two shell-path rules did. As of this afternoon our live STIX bundle contains rules that say "an HTTP request whose content matches /bin/sh" (confidence 90) and "matches /usr/bin/env" (confidence 85), credited to two other CVEs whose exploits produced the same junk first. The HFS rules folded into those duplicates. A third, /bin/bash at 90, came from yet another exploit. All three are noise.
This is the twin of the correction we published on October 2, when we found that 690 of our 734 "SQL injection" rules were command-line flags. That fix tightened the SQL extraction. It did not touch the code that extracts remote-execution and credential patterns, and that is where these came from. The fix is the same shape: require something that would actually appear in an attack request, not a word that appears in any script. It has not shipped yet. When it does, we will say so with the date, and we will say how many rules it removed.
What we hold, and what we put in the feed
The exploit repository is in our index under the CVE, from our own harvester. There are no attacker network indicators to add. VulnCheck did not publish the probing address, and we will not guess at one. This is a single-CVE story, so per our own rule there is no campaign batch to ingest.
Our edge honeypots logged zero HFS probes. That zero describes our sensors, not the threat. We run no decoy that looks like HFS, so nobody hunting HFS has a reason to touch us. Same caveat we gave for NetScaler this morning.
What to do, if you run HFS
Step one: find out what you are running. The HFS 3 admin panel shows the version. If it is 3.0.0 through 3.2.0, you are exposed. Upgrade to at least 3.2.1. The current stable release is 3.3.4.
Step two: if you are on HFS 2.x, you have a different and older problem. CVE-2024-23692, a template-injection bug in HFS 2.3m and earlier, has been on CISA's exploited list since July 2024 and was used to drop cryptocurrency miners and trojans. The 2.x line is no longer maintained. Move to 3.3.4 or take it off the internet.
Step three: if your 3.x server was reachable from the internet at any point since September 26, look at it. Check the server_code setting in the admin configuration for anything you did not write. Check for administrator accounts you did not create. In your logs, look for one address making many unauthenticated login attempts in a short window, because the attack needs to collect login responses before it can forge anything. That last one is our reading of the mechanism, not a published indicator.
Step four: ask whether HFS belongs on the public internet at all. It is a convenient tool. It has now had three critical bugs that attackers went after, across twelve years. A file server for a small office belongs behind a VPN or a tunnel.
The opinion
AI-found bugs are not going to slow down. Mythos found this one in July, and the patch shipped the same day it was disclosed. That is the good version: the finder told the maintainer, the maintainer fixed it, and everyone had more than two months. The part that has not changed is that most people never upgrade a tool like HFS until something makes the news, and the news arrived five days after the exploit did.
The window that matters is from public exploit to first probe. Here it was about five days. CISA's catalog has still not caught up. If you wait for the government list, you are waiting on a clock that the attacker is not using. We hold that with about 90 percent confidence. The other 10 percent is that the probing stays at one address doing reconnaissance and this never becomes a mass event, which is what happened with plenty of loud CVEs before it.
Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=anthropic-s-mythos-found-a-9-3-in-rejetto-hfs-in-july-the-exploit-went-public-sept-26-probes-start
Comments