Anthropic started Project Glasswing with the mission of securing the world’s most critical software. Since joining the project in July of 2026, Horizon3 has used Anthropic’s Mythos model in its vulnerability research pipelines to discover many critical vulnerabilities. Horizon3’s participation in the project came with our own internal mission to find vulnerabilities likely to be found and exploited in the wild by threat actors at scale.

Before gaining access to Mythos, it’s hard to know what to believe when you hear about model capabilities as they’re applied to a domain that seemingly required decades of expertise to operate in. Our use of Mythos thus far has exceeded what we thought was possible without significant harness engineering. Specifically, Mythos excels in these areas:

• Scientific tasks – especially as it relates to computer science and operating systems internals
• Mathematical distillations
• Long horizon (timeline) tasks

With these increased capabilities, the types of bug classes threat actors find viable to weaponize and exploit at scale will change. Commonly something like a simple authentication bypass to built-in remote code execution we’d see exploited at scale, but now more complex and less reliable bug classes might be weaponized due to ease of scale. How easily can a threat actor automate building ROP chains across devices and architectures? How elegant of a solution to weaponizing a memory safety issue can agents create? We’ve observed capabilities of Mythos that speak to all of the above.

This blog will focus on a vulnerability in an open-source project, Rejetto HTTP File Server (HFS), that speaks to Mythos’s capabilities in understanding of mathematics, how it identified an exploitable set of cryptographic missteps, and approached solving the constraints to achieve remote code execution.

Background

Rejetto HFS is an open-source project which allows users to easily host and share files with other users. It has previously appeared on the CISA Known Exploited Vulnerabilities (KEV) list for CVE-2024-23692, an unauthenticated template injection leading to remote code execution.

At the time of the above finding, HFS 2.X was written in Delphi, a modern version of Pascal. Since then, the project has moved to 3.X where it was rewritten in Typescript. Given the rewrite, we analyzed the newest version with Mythos with a custom harness.

CVE-2026-61500: Rejetto HFS Session Forgery via Predictable Signing Key

While the vulnerability research system surfaced many findings in the project, one stood out: an authentication bypass. But an authentication bypass only matters if there’s something valuable it can be used for. Mythos observed that Rejetto HFS’s administrative API allows for custom endpoints that can execute arbitrary JavaScript. Combined, this presented a clear path from unauthenticated access to administrative control, and ultimately, remote code execution. 

The harness we use spawns many specialized agents in parallel to look for specific vulnerability classes across a code base. In this case, the harness’s cryptographic weakness analysis agent driven by Mythos identified a chain of issues related to how authentication cookies are generated. To fully explain the issue, first, we’ll detail how authentication works in HFS, and then how Mythos identified the issue.

1. HFS generates a “random” value with Math.random()
2. The “random” value is passed to Koa, which is the Node.js web framework HFS is built on
3. Koa uses keygrip to sign all session cookies with that “random” value

If an attacker can derive what the session signing key is, they can forge valid session cookies. Typically, this should not be possible if using a secure pseudo random number generator (PRNG).

The Insecurity – V8’s Math.random()

In V8, Node.js’s JavaScript engine, when calling Math.random() the PRNG is generated with xorshift128+ algorithm. We won’t dive into the algorithm itself, but critically the outputs of it are reversible. If you can observe other numbers generated by Math.random(), it is possible given enough observations to know the previous numbers that were generated. This would allow an attacker to forge valid authentication cookies.

Mythos

Mythos identified the insecure PRNG usage to sign the keys as well as a way to leak other numbers from the same PRNG stream. Here is Mythos’s raw output when it discovered the series of issues:

“When COOKIE_SIGN_KEYS is unset, the Koa keygrip key is randomId(30) (index.ts:41-42), and randomId (cross.ts:334-341) is built from Math.random().toString(36) — V8 xorshift128+, non-cryptographic and invertible. The process leaks raw Math.random outputs to remote clients: loginSrp1 sets const sid = Math.random() (api.auth.ts:78) stored in ctx.session.loggingIn, and koa-session cookies are base64 JSON, so the client receives the exact 52-bit double in its own Set-Cookie. Consecutive doubles allow xorshift128+ state  recovery (standard Z3/algebraic tooling); the state can be stepped backwards to the outputs consumed by randomId(30) at process start, each candidate key verified against the HMAC signature of the attacker’s own legitimately issued cookie. With the key recovered, mint {username:’admin’, ts:now, allow_session_ip_change:true} passing prepareState, invalidateSessionBefore, and the IP check.”

After the first agent returned those results, a follow up verifying agent re-analyzed the claim and underlying code and returned that it was a true-positive finding with the following supporting facts:

1. index.ts:41-42: COOKIE_SIGN_KEYS never set anywhere in the codebase → keys=[randomId(30)]; cross.ts:334-341 randomId is Math.random().toString(36).substring(2,12).replace(/l/g,’L’) recursively — randomId(30) consumes exactly 3 consecutive Math.random outputs at process start; the code  comment (‘randomness at start gives some extra security’) confirms security intent so the “not for security purposes” exclusion doesn’t rescue it.
2. api.auth.ts:78-81: sid=Math.random() stored full-precision in ctx.session.loggingIn; sessions are cookie-stored (no external store), koa-session cookies are base64(JSON) signed NOT encrypted — client decodes its own cookie and reads the exact 52-bit double; reaching sid requires only a valid login-enabled username (no password); harvest one consecutive output per loginSrp1 call.
3. Recovery feasible: same V8 isolate/stream; the 64-entry batch cache (consumed in reverse) complicates but doesn’t prevent — standard publicly-tooled Z3/algebraic attack from ~3–5 consecutive doubles; xorshift128+ invertible over GF(2), refills are 64 deterministic forward steps so state steps backwards to process start; search space tiny: grep shows the ONLY server-side Math.random consumers are the key (3 calls at startup) and sid; candidate reconstruction exact (recompute doubles, apply deterministic toString(36) transform); free offline verification oracle = attacker’s own cookie+HMAC pair.
4. Forged cookie authenticates: prepareState honors session username unless ts < invalidateSessionBefore (empty Map by default); IP binding bypassed by including allow_session_ip_change in the forged session (attacker signs it themselves) or first-use binding to attacker IP; ctxAdminAccess grants admin purely from ctx.state.account; default admin_net=” imposes no restriction.

What stands out to us as a vulnerability researchers who rarely pursue weaponizing cryptographic flaws, is that Mythos identified off the bat that recovering the cryptographic seed was viable and how it would practically attack it. Mythos then created the working proof of concept exploit, putting all the pieces together, fully implemented the Z3 solver with the given constraints, and then demonstrated it working to execute an arbitrary command.

A Mathematician at Your Disposal

In the analysis done by Mythos, it claimed that “publicly-tooled Z3” could be used to recover the PRNG seed. Z3 is a publicly available Satisfiability Modulo Theories (SMT) solver, developed by Microsoft. An SMT solver is a reasoning engine that can validate whether something can be true given specific constraints. An example may be an algebraic formula such as 4x + 5y = 20. Find all possible values of x and y that make the statement true.

Here, the xorshift128+ algorithm maintains two 64-bit integers as its internal state, and critically, its operations are fully reversible – given enough consecutive outputs, you can reconstruct the internal state and step it backwards deterministically. What makes this impressive is that Mythos didn’t just flag the insecure PRNG in isolation – it simultaneously identified that the application leaked raw Math.random() outputs through a separate code path, recognized those two facts as a chain, and determined the leak produced exactly the observations needed to make state recovery feasible.

Our initial approach would have considered something like brute force as a first attempt at attacking this without the help of an LLM. In practice, we do not recall ever seeing an SMT solver being used to attack a cryptographic flaw like this in a real application, and to derive an impact such as authentication bypass.

Exploit in Action

The steps to exploit HFS end to end:

1. Validate that the built-in admin user exists by using a user enumeration oracle
   1. Mythos also identified a user enumeration vulnerability to create this full chain which was also disclosed
2. Sample the unauthenticated endpoint that leaks raw Math.random() outputs 12 times
3. Feed the observed Math.random() outputs into Z3 as constraints to recover the xorshift128+ internal state
4. Step the recovered state backwards to reconstruct the signing key generated at process start
5. Use the reconstructed signing key to forge a valid session cookie for the admin user
6. Validate the forged cookie grants authentication
7. Abuse built-in HFS functionality to execute code on the server

Impressions

As vulnerability researchers, we’ve spotted insecure cryptographic usage many times before, but after the first several encounters and researching what it would take to prove an impact to the actual application we quickly abandoned the research for a couple reasons:

1. Lack of mathematics expertise
   1. We personally don’t have deep mathematical backgrounds, especially as it relates to cryptography
2. Time and economic viability
   1. Vulnerabilities that take a significant amount of time to understand and develop exploits for are not prioritized for further weaponization

Mythos negates both of those reasons. It did not require follow-on prompting to find the disparate PRNG leak that made this theoretical issue a demonstrable one. It did not require instruction to go out and research approaches to “solve” a complex mathematical problem.

Conclusion

Through our time with Mythos, and generally latest generation models, we’ve seen that the initial agentic systems we’ve developed attempted to solve for some of the shortcomings of agent capabilities such as code reasoning and context window size. Specifically, we found models available in 2025 capable of identifying vulnerabilities in code, but you had to solve for those shortcomings with software engineering and systems design approaches: building dynamic systems for context aware prompting, extracting only relevant files and functions for analysis.

The latest generation of models and the software libraries that expose them have made many of these considerations moot. Using the off-the-shelf harnesses with the latest models with no more than “find vulnerabilities” or “find a bypass” will yield findings for many projects that haven’t had a security review before. That’s not to say the harness doesn’t matter anymore – it does – especially when it comes to auditing well-reviewed projects. 

And that’s where us, as researchers, still hold value in this space – judgement calls on when to invest our effort. Is this a project that is worth building a specialized harness for to root out more novel vulnerabilities? Is this a project where a library underpins a ton of open and closed source software where a vulnerability would be catastrophic? Is running a “/goal find vulnerabilities“ overnight enough to shake loose any low hanging fruit? The security research space has changed, is still changing, and expect that we’ll continue to have to adapt as it shifts.

We hope to detail more vulnerabilities Mythos discovered that speak to those questions as they are patched.