Tom Hundley
Popular security writing fixates on "the bug" — a vulnerability gets a name, a CVE, a breathless headline, as if finding the flaw were the whole story. For the targets that actually matter, it isn't. On a modern Linux kernel, finding a single bug is the easy part. Doing something with it — turning a flaw into root access on a hardened machine — usually takes several bugs, used together, in a deliberate order. That assembly step is where real exploitation lives, and it has historically required a scarce kind of human: someone who can hold an entire exploit in their head and plan across it.
So the genuinely notable line in Anthropic's Frontier Red Team writeup on Claude Mythos Preview — the unreleased frontier model behind Project Glasswing — is not that the model found kernel bugs. It's that it chained them. The Red Team reports "nearly a dozen examples of Mythos Preview successfully chaining together two, three, and sometimes four vulnerabilities" into a working Linux-kernel privilege-escalation exploit. That is a harder capability than spotting a flaw, and it's worth understanding why.
Here is the thing that surprises engineers who haven't done exploitation: most kernel vulnerabilities, on their own, are nearly useless to an attacker. As the Red Team explains it, a single vulnerability usually grants just one disallowed action — reading kernel memory, say, or writing to it — and on its own, with all the kernel's defenses in place, that one capability isn't enough to be very useful.
Picture the two most common primitives an attacker might win from a single bug:
That second point is the whole reason chaining exists, and the map-hider has a name: KASLR, kernel address-space layout randomization. Every boot, the kernel loads itself and its data structures at randomized addresses. A write primitive is only dangerous if you know the address of something worth overwriting — say, the structure that records your process's privileges. KASLR makes you guess from a space so large that blind guessing crashes the machine long before it succeeds. A write you can't aim is a brick, not a key.
The Red Team's own illustration of the escape is the cleanest way to see chaining. An adversary who also holds a separate read vulnerability can chain the two: use the read bug first to bypass KASLR, then use the write bug to change the data structure that grants elevated privileges. The read bug doesn't grant privilege. The write bug can't be aimed. Put them in sequence — read to learn the address, write to hit it — and two individually-weak flaws become one root exploit. Neither half is the exploit. The combination is.
The two-bug version is the teaching model. What Mythos built in the field was richer; the Red Team walks through one example, and it's worth tracing in the source's own order, because the ordering is the skill. In this case Mythos used four ingredients:
Chain all four, and — in the Red Team's words — the sequence ends by "ultimately granting the user root permissions." A normal local user becomes root on a fully-defended kernel.
Map that onto the three-part anatomy every exploitation primer teaches and it lines up exactly: an info-leak / KASLR bypass (steps 1–2) defeats randomization and reads state; a memory-corruption primitive (step 3) provides the write; and heap grooming (step 4) makes the write reliable. The "nearly a dozen" Mythos examples are variations on this skeleton — sometimes two bugs, sometimes three, sometimes four — but the logic is the same every time: combine a way to see with a way to write, and arrange memory so the write lands where it counts.
It is tempting to read "the model found bugs" and "the model chained bugs" as the same news at different volumes. They are not — and the gap between them is the gap between pattern recognition and planning.
Finding a bug is, at its core, recognition: scan code or a binary, notice a shape that looks wrong, flag it. Impressive at scale, but local — each finding stands alone, and you can be good at it while having no idea what the bug is for. Chaining is the opposite. To build the four-step exploit above, you have to reason about state that persists across steps: the address you leak early is the input to the write later; the heap you groom in step four must be arranged before the write fires, anticipating where it will land. You hold a model of the machine's memory in your head, form a multi-stage hypothesis about how to move it from "unprivileged user" to "root," and execute the stages in an order where each one sets up the next. That is planning across steps, not spotting one flaw — and historically it is what separates a vulnerability report from a working exploit.
The Red Team's framing of why this is dangerous in particular isn't about raw cleverness — it's about friction. Many kernel mitigations were never meant to be unbreakable walls; they were meant to be tedious, to make the chaining so slow and finicky that few humans bother. As the writeup puts it, when run at scale "language models grind through these tedious steps quickly," so "mitigations whose security value comes primarily from friction rather than hard barriers may become considerably weaker against model-assisted adversaries." A defense whose protection was really just "this is annoying enough that nobody will do it" loses that protection when the adversary doesn't get bored, doesn't get tired, and can try a thousand times for the cost of a laptop.
Here is the part that keeps this from being a doom story, and it comes straight from the source rather than from spin. Mythos's kernel successes were local privilege escalation — an attacker who already has a foothold (an account, a sandboxed process) climbing to root. The far scarier prize would be remote kernel compromise: rooting a machine you've never touched, over the network.
Mythos went looking for that too, and the Red Team is candid that it largely failed. It found remotely-triggerable kernel write primitives — but, after several thousand scans, the kernel's "defense in depth measures" left it "unable to successfully exploit any of these." That cuts both ways. Pessimistically: such flaws exist, and a more capable model or a determined human might finish what Mythos couldn't. Optimistically — and this is what the result actually demonstrates — defense-in-depth held. Thousands of attempts by a frontier model, against real remotely-reachable flaws, did not produce a remote kernel exploit, because the kernel layers multiple independent protections and the model could not chain through all of them at once.
That tells defenders exactly where to spend. The Red Team draws the line itself: mitigations that work by friction are eroding, but "defense-in-depth techniques that impose hard barriers (like KASLR or W^X) remain an important hardening technique." KASLR is precisely what forced the chain to spend a whole step on a leak. W^X (memory that is writable or executable, never both) is precisely the kind of hard barrier that blocks an entire move rather than slowing it. So the defensive implication isn't only "patch faster" — it's architectural: invest in protections that make a step impossible, not merely inconvenient, because the inconvenient ones are the first to fall to a tireless machine. The encouraging counterweight is the one the report itself demonstrates — defense-in-depth, built in real layers, made a frontier model fail to go remote-to-root on the most-attacked kernel in the world. Layered, independent, hard defenses still win, and they are now the part of your security posture that has to do the most work.
What does "exploit chaining" actually mean?
Combining several distinct vulnerabilities — each individually limited — into one working attack, where each bug does a job that sets up the next. A single flaw might only let you read kernel memory, or only write to it; chain a read bug (to learn where to aim) with a write bug (to change a privilege-granting structure) and the combination becomes a root exploit that neither bug is on its own.
Why isn't a single kernel bug enough to get root?
Because modern kernels layer defenses so one primitive can't finish the job. KASLR randomizes where everything lives, so a write primitive is blind — you can corrupt memory but not aim it — until a separate leak reveals the addresses. That forced separation between "being able to write" and "knowing where to write" is why attackers chain, and why a lone bug usually buys far less than its severity rating suggests.
What did Mythos's example chain actually do, step by step?
Four ingredients in order: one vulnerability to bypass KASLR, a second to read the contents of an important kernel struct, a third to write to a previously-freed heap object, and a heap spray that placed a structure exactly where that write would land — "ultimately granting the user root permissions." The leak defeats randomization, the read learns the state, the write corrupts, and the spray makes the corruption reliable instead of lucky.
Why is a model chaining bugs more significant than a model finding bugs?
Finding a bug is recognition — noticing one wrong-looking thing in isolation. Chaining is planning across steps: the address leaked early is the input to the write later, and the heap must be groomed before the write fires. That multi-stage planning has historically been the human bottleneck in exploitation, which is why a model doing it autonomously — "nearly a dozen" times — is the part worth attention.
Could Mythos use this to remotely take over machines?
No — and the report is honest about it. Its kernel chains achieved local privilege escalation (climbing from an existing foothold to root). When it hunted for remote compromise it found remotely-triggerable write primitives but, after several thousand scans, the kernel's "defense in depth measures" left it "unable to successfully exploit any of these" — a real-world demonstration that layered hard barriers still work.
What's the defensive takeaway for my own systems?
Stop rating vulnerabilities only in isolation: two "medium" bugs that compose can be a "critical." And prioritize hard barriers over friction — the Red Team notes that friction-based mitigations get "considerably weaker" against a model that grinds through tedious steps tirelessly, while hard barriers like KASLR and W^X "remain an important hardening technique."
Discover more content:
