Mythos Preview as part of Project Glasswing

 Cloudflare in its blog wrote thus about Project Glasswing:

--------------------

For the last few months, we've been testing a range of security-focused LLMs on our own infrastructure. These LLMs help identify potential vulnerabilities in our own systems, so we can fix them – and they also show us what attackers are going to be able to do with the latest models.

None of these LLMs has captured more attention than Mythos Preview, from Anthropic. A few weeks ago, we were invited to use Mythos Preview as part of Project Glasswing. We soon pointed it at more than fifty of our own repositories – to see what it would find, and to see how it works.

This post shares what we observed, what the models did well and what they didn't, and how the architecture and process around them needs to change, so they can be used at scale.

Mythos Preview is a real step forward, and it's worth saying that plainly before getting into anything else. We've been running models against our code for a while now, and the jump from what was possible with previous general-purpose frontier models to what Mythos Preview does today is not just a refinement of what came before.

It's a different kind of tool doing a different kind of work, and that makes a clean apples-to-apples comparison to earlier models difficult. So rather than trying to benchmark Mythos Preview against general-purpose frontier models, it's more useful to describe what it can actually do, and two features that stood out across the work we did with Mythos Preview:

Exploit chain construction - A real attack rarely uses one bug. It chains several small attack primitives together into a working exploit. For instance, it might turn a use-after-free bug into an arbitrary read and write primitive, hijack the control flow, and use return-oriented programming (ROP) chains to take full control over a system. Mythos Preview can take several of these primitives and reason about how to combine them into a working proof. The reasoning it shows along the way looks like the work of a senior researcher rather than the output of an automated scanner.

Proof generation - Finding a bug and proving it's exploitable are two different things, and Mythos Preview can do both. It writes code that would trigger the suspected bug, compiles that code in a scratch environment, and runs it. If the program does what the model expected, that's the proof. If it doesn't, the model reads the failure, adjusts its hypothesis, and tries again. The loop matters as much as the bugs it finds, because a suspected flaw without a working proof is speculation, and Mythos Preview closes that gap on its own.

Some of what we describe above is not entirely unique to Mythos Preview. When we ran other frontier models through the same harness, they found a fair number of the same underlying bugs, and in some cases they got further than we expected on the reasoning side too. Where they fell short was at the point of stitching the pieces together. A model would identify an interesting bug, write a thoughtful description of why it mattered, and then stop, leaving the actual chain unfinished and the question of exploitability open. What changed with Mythos Preview is that a model can now take those low-severity bugs (which would traditionally sit invisible in a backlog) and chain them into a single, more severe exploit.

--------------

Let's understand in layman's terms what this quote means: 

'A real attack rarely uses one bug. It chains several small attack primitives together into a working exploit. For instance, it might turn a use-after-free bug into an arbitrary read and write primitive, hijack the control flow, and use return-oriented programming (ROP) chains to take full control over a system. Mythos Preview can take several of these primitives and reason about how to combine them into a working proof. The reasoning it shows along the way looks like the work of a senior researcher rather than the output of an automated scanner.'

Here's what that's saying, in plain terms:

The core idea: hacking usually isn't one bug = one hack

Let's think of a piece of software as a house with many small flaws — a window that doesn't latch properly, a lock that's a bit loose, a floorboard that creaks and shifts. Any single one of these flaws alone might not let a burglar into the house. But a clever burglar can combine them: use the loose floorboard to reach the window latch, use the window to get to the loose lock, and now they're inside and can move freely.

That's an "exploit chain" — attackers rarely find one giant bug that hands over full control. Instead, they find several small, seemingly minor bugs and stitch them together, where each one enables the next step.

The technical example translated in layman's terms:

Use-after-free bug: A program frees up a piece of memory (analogy could be clearing out a filing cabinet) but then accidentally still tries to use it later. This creates an opportunity for an attacker to sneak their own data into that "empty" space.

Arbitrary read/write primitive: Turning that mistake into a general-purpose ability to read or write almost any memory location in the program  It is like going from "found one unlocked drawer" to "now I can open any drawer in the building."

Hijack control flow: Once you can write anywhere, you can trick the program into running instructions of your choosing instead of its own code. It is like slipping fake instructions into someone's to-do list and having them followed exactly.

ROP chains (return-oriented programming): A technique where an attacker doesn't inject new malicious code, but instead stitches together tiny existing fragments of the program's own code (like assembling a ransom note out of cut-up letters from a newspaper) to make the program do something it was never intended to do.

Therefore what Mythos Preview is doing is this:

The claim is that this AI model can look at a handful of these individual small flaws and figure out, on its own, how to link them together into a complete, working attack. And that its step-by-step reasoning while doing this reasoning resembles how an experienced human security researcher thinks through the problem, rather than just mechanically trying random combinations like a basic automated tool would.