Defending Against AI-Generated Exploits

A vulnerability is not an attack until someone weaponizes it. For decades that step needed a human expert, and the scarcity of those people is what capped how fast bugs became breaches. AI has removed that scarcity.

The bugs were never the bottleneck. Anthropic's Project Glasswing flagged more than 10,000 high or critical severity zero-days in a single month, and Claude Opus 4.6 validated over 500 in production code. Assume the exploitable bug is there, known or unknown. The open question is who turns it into a working exploit first.

ExploitGym: AI can build the exploit now

A group led by UC Berkeley, with co-authors from Anthropic, OpenAI and Google, built ExploitGym to answer how far agents have come at weaponizing vulnerabilities autonomously. It is a benchmark of 869 real-world vulnerabilities. For each one the agent gets source code and a live runtime, and has to turn a crash into a working end-to-end exploit that captures a protected flag, proving arbitrary code execution.

Within a two-hour budget, OpenAI's GPT-5.6 Sol produced working exploits for 216 of the 869 instances, Anthropic's Mythos Preview for 157 and OpenAI's GPT-5.5 for 129. Every one of those is a multi-stage exploit, where the agent chains several primitives to escalate a crash into full code execution.

While the success rate should concern every security professional, the main insight of the research is the step increase in capability. One generation ago GPT-5.4 solved 61 instances, and Claude Opus 4.6 and Opus 4.7 solved 16 and 12. The next generation, GPT-5.5 and Mythos Preview, solved 129 and 157, and GPT-5.6 Sol then took that to 216. For Anthropic that is close to a tenfold jump in a single generation.

METR finds the length of task an agent can complete has doubled roughly every seven months for six years. At that pace, the targets agents still fail on today will be within reach of the next generation.

Hack one, hack all

Why does one exploit compromise an entire fleet?

The impact of AI-assisted exploitation can already be observed in the real world. Verizon's Data Breach Investigations Report has exploitation of public-facing software climbing from 14% of breaches in 2024 to 20% in 2025, passing phishing and credential abuse, then to 31% in 2026. That is the first time in the report's nineteen-year history that exploitation ranks first as the initial access vector.

The fastest-growing target inside that trend is the identical edge fleet. The same report puts edge and VPN devices at 22% of exploitation activity, up almost eightfold from 3% the year before. Google's threat intelligence group found security and networking appliances alone made up more than 60% of enterprise zero-day exploitation.

Those systems ship hundreds to tens of thousands of units running one software image. Every unit shares the same internal code structure, the same memory layout, code layout, control structures and gadgets. An exploit depends on exactly those structure-specific details. So one working exploit becomes a master key to the entire fleet. Hack one, hack all. The same efficiency that makes a fleet cheap to ship and maintain is what makes it possible to break at scale.

They also run on C and C++, where memory corruption is about 70% of serious vulnerabilities, and 86% of critical severity bugs in Android. That is the class that depends on predictable layout. And the static defenses meant to stop it ship identically on every device, so a bypass that works on one works on all.

2025 recorded 48,185 CVEs, roughly 131 a day and about 21% up on the prior year. The cumulative total passed 300,000, and in April 2026 NIST moved the National Vulnerability Database to a triage model. Scanning cannot close that gap, because only about 1% of CVEs are ever exploited and nobody can tell in advance which 1%.

Remove the shared structure

What is software diversification?

Software diversification is a compiler technique that turns a single source tree into many functionally identical but structurally unique binaries. The binaries behave identically, but none share the internal structure an exploit depends on: each build gets its own code layout, memory layout, control structures and gadgets, so the building blocks an exploit relies on are placed differently or are simply incompatible across builds.

Variant Security applies this inside the compiler. No source changes, no workflow changes, low overhead, and every build is seeded and fully reproducible.

AI builds working exploits fast enough to overwhelm static defenses that ship identically across every device, and it can target any system it is able to study beforehand. Defending against AI-generated exploits by hardening one shared binary only raises a bar that a capable agent keeps clearing. Removing the shared structure takes away what the agent prepares against, and with it the property that lets one exploit run across an entire fleet.

Software diversification is not ASLR

ASLR randomizes where one identical binary is loaded. The binary itself is the same on every device, so an attacker who works out how to leak an address and exploit one device reuses that same technique on the rest. We change the binary's structure differently on every device, so there is no shared structure to learn once and exploit repeatedly.

ASLR has been standard in mainstream operating systems for about two decades. Over that same period memory corruption stayed the dominant class of serious vulnerability in C and C++ code, and exploitation became the leading way attackers get in. Randomizing where an identical binary loads raises the cost of building one exploit without changing what that exploit is worth across a fleet.

How Variant fits the build pipeline

Integration is a compiler plugin and a compiler wrapper. No source changes, no workflow changes, and it runs alongside whatever hardening you already have rather than replacing it. Every variant is deterministic and derived from a seed, so passing the same seed twice reproduces the identical binary. The only random element in the whole process is the seed itself, which means builds stay reproducible and a specific field unit remains debuggable long after it shipped.

Testing the defense against AI-generated exploits

We rebuilt the ExploitGym targets with our toolchain and measured what happened to the exploits the agent produced. We used GPT-5.5 as the exploiting agent, given current restrictions on Mythos and Fable, and ported the user space targets to Ubuntu 24.04 and Clang 21. The agent got the clean target environment, an initial crash report, source code and vulnerability descriptions.

How we counted a stopped exploit

An exploit can fail for reasons that have nothing to do with our technology, so we ran every exploit through three controls before counting it.

1. The exploit had to replay in a fresh container, so that nothing in the population rests on a stale environment or on luck.
2. It had to survive a clean recompile of the target with stock Clang, so that exploits tied to one particular build setup fall out here.
3. It had to keep working when the target was built through our toolchain with diversification switched off, so that our integration itself is not what breaks it.
4. Only then did we turn diversification on and see what broke.

Anything that fell over earlier is a control failure and does not count in our favor. The exploits that cleared that gate are the population both experiments run on, and rebuilding their targets with diversification on stopped 91.7% of the memory-corruption exploits among them. The whitepaper reports how many exploits survived each of these steps.

What the numbers cover

Every number on this page comes from the benchmark's user-space targets, rebuilt on Ubuntu 24.04 with Clang 21, with GPT-5.5 as the exploiting agent. A stopped exploit is one that worked against the build it was made for and failed against a diversified build of the same target. The class in scope is memory corruption, the class where exploits depend on binary structure, and the scope section further down reports what the three surviving exploits relied on instead.

The fleet result: 96.6% stopped on an unseen variant

We next test whether an attacker who already holds several variants of a target can use them to compromise another variant they cannot access. In practice this is someone with several devices from a fleet, obtained for example through physical access, who wants to attack a device they cannot reach directly.

So we gave the agent three variants of the same target, each compiled with a different seed, and told it to build one exploit that works across all three and across builds it had not seen. Then we ran that exploit against a fourth variant it never had access to.

Nothing in the experiment restricts how the agent attacks, and the visible variants give it full material to study how our diversification reshapes each build. A surviving exploit must rest on a structural invariant our diversification failed to randomize, re-derive the hidden layout at runtime through an information leak, or lean on intended program behavior.

An exploit here is a script that makes many attempts against the target, not a single one-shot payload. The agent compromised at least one visible variant on 48 targets, and built 38 exploits that worked across all three visible variants. Those are the attacker's own builds.

The exploit reached the hidden variant three times, a 96.6% rate of exploits stopped.

Zero-day immunization for the most exploited bug class

All three survivors relied on target-level semantic behavior that stays available across seeds, specifically intended command execution and file-read paths. None of them defeated the diversification. They went around it, through functionality the program was built to offer. We report those two results separately rather than collapsing them into a single claim.

Diversification never inspects the vulnerability. It needs no signature, no patch, no CVE, and no knowledge that the bug exists at all. It removes the predictable structure the exploit is built on, so an unknown bug is contained on exactly the same terms as a known one. That is what makes it immunization instead of reacting with a patch, because the protection is already in place before the vulnerability is found and does not lapse while a fix is being written.

The scope is one class of bug. Diversification contains exploits whose success depends on predictable binary structure, including stack and heap overflows, out-of-bounds reads and writes, use-after-free, and type confusion leading to control-flow hijack. That is the same class as the 70% and 86% above, it is roughly 70% of the vulnerabilities Microsoft fixes and assigns a CVE, and Google Project Zero's root-cause analysis found it behind 67% of the zero-days exploited in the wild in 2021. Logic flaws and intended capabilities reached without memory corruption, such as command injection, weak authorization, or a legitimate file-read path reached through unsafe input, are untouched.

Diversification runs alongside secure development, vulnerability discovery, patching, memory-safe languages, ASLR, control-flow integrity and incident response rather than replacing any of them. What it changes is how far one working exploit travels. Against an identical deployment it reaches every device. Against a diversified one it reaches the build it was made for.

Defend the fleet, not one fixed binary

AI will keep reducing the time and expertise needed to weaponize a vulnerability. Slowing the agent down buys time, but it leaves the multiplier in place, because one successful exploit still travels across every identical unit.

Variant removes that multiplier. One source tree becomes many reproducible binaries, the software keeps the same behavior, the delivery workflow stays intact, and every deployed unit becomes a separate intelligence problem for the attacker. A working exploit reaches the device it was built for and stops there.

Frequently asked questions

About the authors

Johannes Willbold

Co-Founder and CEO

Johannes Willbold is co-founder and CEO of Variant Security and holds a PhD from Ruhr University Bochum. His doctoral research on the security of satellite flight software was published twice at IEEE S&P, received a Distinguished Paper Award and was featured in WIRED, and he founded the SpaceSec Workshop at NDSS, the first academic venue dedicated to space cybersecurity. He has presented his work at Black Hat USA, DEF CON, ESA and NASA JPL.

Nico Schiller

Founding Compiler Engineer

Nico Schiller is a founding compiler engineer at Variant Security and a co-author of ExploitGym, the benchmark this page reports on. He holds a PhD from Ruhr University Bochum, where he worked on software security and fuzzing, and was a postdoctoral researcher at the Max Planck Institute for Security and Privacy. His research has been published at NDSS, USENIX Security, IEEE S&P and ACM CCS, with several papers receiving Distinguished Paper Awards, and his security analysis of DJI's DroneID protocol was featured in WIRED.