Reading Anthropic's Report on How LLMs Speed Up N-day Exploits
I read "Measuring LLMs' impact on N-day exploits," published by Anthropic's Frontier Red Team in June 2026. The team handed models already-public security patches and measured how fast they could turn them into exploits, on Firefox and on the Windows kernel. Here are four insights from it.
Before we start — key terms
N-day / patch gap — An N-day is a vulnerability that has been publicly disclosed and patched, but the patch hasn't reached every device yet. It sits on the opposite side from a zero-day, which even the software's maintainers don't know about. The window between a patch shipping and it actually landing on devices is the patch gap, and attackers target the systems still sitting in it. Insights 1 and 3 compare the length of that window directly with how long the models took to build exploits.
Insight 1: An exploit within an hour of the patch
Comparing code before and after a patch to find what changed, then working back to the bug, is called patch diffing. The study gave models only public information for 18 patches to Firefox's JavaScript engine, SpiderMonkey, such as the diffs and builds from before and after each fix, and let them do the rest.
Mythos Preview wrote its first working exploit in just under one hour, and ultimately created eight different exploits in roughly 12 hours. (...) To put these results into perspective, Mythos Preview had its first exploit within an hour of Mozilla issuing the patch for it—while it would've been 18 days before the patched Firefox 148 was even released.
Firefox auto-updates, applies a fix with a single restart, and recently moved its point releases from monthly to roughly weekly. The authors call it close to the best case for defenders. The experiment reuses the harness and grader from Anthropic's earlier work with Mozilla.
Even under those near-best conditions, the first exploit arrived within an hour of the patch. Between model generations, the number of patches turned into a crashing PoC also went from 2 to 11 (Opus 4.5 to Opus 4.8). Seeing those two numbers, I think AI-assisted hacking is only going to increase.
Insight 2: Kernel privilege escalation from binaries alone
With no Windows source available, the models worked from stripped binaries and Ghidra decompilations, with no variable names or types. The goal was to go from a low-privilege user all the way to SYSTEM, the highest privilege on the machine.
It not only produced a full chain exploit, but produced eight distinct exploits, at a cost of $15,700 in API credits—an average of about $2,000 per privilege escalation. The binding constraint to N-days is now just a few thousand dollars and API access, which expands the pool of capable N-day attackers dramatically.
One bug Microsoft rated "Exploitation Unlikely" was escalated all the way. The authors note that the rating system is calibrated to human researchers and may need to change.
Software that people all over the world use every day, like Windows, was broken this way from binaries alone, without source. Software like that can't be considered safe, and finding vulnerabilities from binaries looks like something there's no way to stop.
Insight 3: Exploits finish before the patch reaches devices
Using Windows Autopatch timelines as a reference (as it's likely on the faster side of patching management today), it typically takes seven days before a patch is shared out to 90% of enrolled devices in a fleet. And it is only on day 11 that devices are given a forced reboot. At this speed, Mythos Preview would have finished creating all eight full chain exploits before any of the Windows devices had received the patch as an update.
In Korea, KISA's Boho portal posts advisories urging people to apply major vendors' security updates (boho.or.kr). The paper's conclusion says today's playbook of monthly releases and multi-week staged rollouts no longer holds.
That week it takes for a patch to reach devices doesn't exist on the web. The web can deploy continuously, around the clock, with zero downtime; shipped software and binaries can't. So it feels like we need some alternative.
Insight 4: The conclusion: cut the supply of bugs
A more durable fix would attack the supply of bugs, rather than the speed of patching them. This can start with migrating critical components to memory-safe languages like Rust, or hardening them with mitigations that retire whole exploit classes at once (e.g. Control Flow Guard, hardware shadow stacks). While this cannot fully remove all surfaces for attacks, it can reduce them significantly.
Control Flow Guard and shadow stacks block attacks that use a memory bug to redirect a program's execution somewhere it shouldn't go. The idea that fixing bugs is the bottleneck also came up in my earlier post on Glasswing.
As Insight 3 showed, patches can't be shipped fast anyway, so reducing the bugs themselves seems like a good direction. But even after moving to memory-safe languages, something like authentication still has to hide a key somewhere, so there's always going to be a hole. Do we need to build some new kind of authentication protocol for that? I keep going back and forth on it.
In its conclusion, the paper says the term "N-day" has become dangerously misleading, and that "N-hour" is closer to the reality we now operate in.
