Leaked random values sampled in the attack chain: 12 (Source: Horizon3.ai attack research (September 30, 2026))
Horizon3.ai says its researchers repeatedly dropped insecure-cryptography leads. Proving them took too long and needed maths they lacked. Then, in one project, Anthropic's Mythos model did that work. Horizon3 says Mythos removed both obstacles in this case. This article argues that the real barrier was never the code. It was human time. That argument is ours, not Horizon3's.
What Horizon3 found
Horizon3 joined Anthropic's Project Glasswing in July 2026. Its researchers have since used Anthropic's Mythos model in their vulnerability research pipelines. In a September 30 write-up, they describe one result in Rejetto HTTP File Server (HFS), an open-source tool for sharing files. It is tracked as CVE-2026-61500, "Rejetto HFS Session Forgery via Predictable Signing Key."
HFS has a history. Its older 2.X version appeared on the CISA Known Exploited Vulnerabilities list for CVE-2024-23692. The project was later rewritten in TypeScript as version 3.X. Horizon3 pointed Mythos at that newer code with a custom harness, which runs many specialised agents in parallel.
How the attack works
When you log in to a website, it hands your browser a signed cookie. The signature proves the cookie is real. If an attacker learns the secret signing key, they can print their own valid cookies, including one for the administrator.
Horizon3 says HFS builds that key from Math.random(), a JavaScript function that is not meant for secrets. In V8, the engine inside Node.js, it uses an algorithm called xorshift128+. Its outputs can be worked backwards. Given enough of them, you can recover the internal state and rewind to earlier numbers.
That alone is only a theory. The second half of the chain made it real. Horizon3 reports that HFS's login step also stores a Math.random() value in the user's own cookie. The cookie is encoded, not encrypted, so the client can read it. Reaching that step needs only a valid username, not a password.
Horizon3 lists the resulting steps. Confirm the admin account exists. Collect 12 leaked values. Feed them into Z3, a public solver from Microsoft that checks which values fit a set of constraints. Rewind to the key created at startup. Forge an admin cookie. Then use HFS's own admin feature, which lets administrators add endpoints that run JavaScript, to run code on the server.
The lead nobody had time to prove
The most useful part of the report is not the bug. It is the researchers' admission. Horizon3 says it has spotted insecure cryptography many times. After the first several encounters, it abandoned that kind of research for two reasons. The team lacked deep maths backgrounds. And flaws that take long to understand and exploit are not prioritised for weaponisation.
Neither reason is about the flaw itself. Both are about the hours and skills a person must spend. Horizon3 describes its own habits, not the industry's, and it gives no timeframe for them. Still, the pattern is easy to recognise. Many security teams rank findings partly by how hard they look to exploit. That ranking works only while proof stays expensive.
Horizon3 says Mythos negated both reasons. It found the separate leak on its own, without follow-up prompting. It researched how to solve the maths, built a working exploit and ran a command on the target.
Horizon3 also draws a wider conclusion. Attackers have tended to exploit simple flaws at scale, such as an authentication bypass that leads straight to code execution. The researchers say more complex and less reliable flaws might now be weaponised, because automation makes scale easier. That is Horizon3's expectation, not a measured trend.
The lesson is that "too hard to exploit" can describe the effort a human must spend rather than any strength in the code. If a machine can spend that effort, a ranking built on it loses its footing. The flaw was there all along. What changed, in this account, is who could afford to prove it.
Limits worth stating
This report describes one project. Horizon3 does not say this flaw was exploited in the wild. The account of Mythos's abilities comes from the vendor-partner that used it, not from an independent test. Horizon3 also notes that the harness still matters, especially for well-reviewed projects. Its researchers say their value lies in judgement: which projects deserve a specialised harness, and which underpin so much software that a flaw would be catastrophic.
What to ask your team
Ask which internal tools and vendor products handle sessions or keys, and how they generate their secrets. A random function meant for games or shuffling should not sign anything that grants access.
Ask whether any team runs HFS, and which version. Then check the status of CVE-2026-61500 with the maintainers. The report does not describe a fix.
Ask what your security prioritisation assumes about attacker effort. If a finding was ranked low because it was "hard to exploit," ask what the ranking would look like if proof were cheap. Start with cryptography and session handling, the areas where Horizon3 says its own team gave up.
A flaw ranked low for being tedious to prove is not a small flaw. It may only be an unpaid one.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Horizon3.ai.
