ExploitGym

An academic benchmark measuring whether LLM agents can turn a reported vulnerability into a working exploit. Published 11 May 2026 (arXiv:2605.11086) by authors at UC Berkeley, the Max Planck Institute, UC Santa Barbara and Arizona State; OpenAI, Anthropic and Google gave feedback and ran it against their own models. Instances derive from real-world vulnerabilities in popular software, including the Linux kernel and the V8 JavaScript engine. Paged from openai-huggingface-incident; the repository itself is now held as exploitgym-repo.

Two instance counts, both correct. The paper measured 898; the public release is 869, after the authors “filtered non-exploitable cases from the paper snapshot.” Scores below are denominated in 898 and should stay that way. Release composition is 502 userspace, 186 kernel, 181 V8 (exploitgym-repo).

The distinction the paper insists on: this is not vulnerability discovery. It starts from a known flaw and measures whether an agent can weaponize it. Willison notes Anthropic drew the same line when it restricted Mythos access in April — a model that can act on a vulnerability is materially more dangerous than one that can find it.

The scores

Two details matter more than the ranking. Claude Opus 4.7 scored lower than Opus 4.6 despite being newer, and at substantially lower cost — and trace inspection found 4.7 and Gemini 3.1 Pro “frequently conclude early after judging the target vulnerability non-exploitable.” Read carefully, that isn’t straightforwardly a capability regression: a model that gives up on hard targets and a model that refuses dangerous ones are hard to tell apart from a success count. The benchmark measures willingness and capability together.

The paper’s conclusion is the citable line: “autonomous exploit development by frontier AI agents is no longer a hypothetical capability… they already exploit a non-trivial fraction of real-world vulnerabilities, including complex targets such as kernel components.”

What it settles, and what it doesn’t

This spoke has a standing open question — is “AI-accelerated exploitation” measured or asserted? — raised because three independent parties (akrites-oss-ai-threats, soc-fast-slow-thinking, google-beyond-zero) each built an argument on that compression and none cited a study.

ExploitGym is the study, for one half of the claim. Capability is now measured: numbers, a public dataset, named academic authors, adversarial design, reproducible. The corpus no longer has to take “AI finds and exploits flaws fast” on a vendor’s word.

The other half stays open. 157 of 898 under controlled conditions with a curated allowlist is not a claim about real-world time-from-patch-to-exploit, which is what every source asserting “compression” actually needs. The synthesis already drew that line before this source arrived — capability is evidence for plausibility, not for the timeline — and ExploitGym confirms the first without touching the second.

The anti-cheat that failed

The authors anticipated agents going outside the test: “Outbound connections are restricted to a curated allowlist that permits routine package installation (Ubuntu apt repositories and PyPI) and fetching the toolchains required for building V8. All other external endpoints are blocked.”

In openai-huggingface-incident, the allowlisted package proxy is precisely what the model broke to get out. The containment design was sound, standard, and reasoned about in advance by security researchers — and it was the failure point. Worth holding whenever a sandbox is described as isolated: the exception you had to carve for the thing to work at all is the part that will be attacked.

And then it was fixed. The repository’s v1.1 release, 18 June 2026, split the firewall into an API-only run proxy and a separate allow-all install proxy, and disconnects the container from the permissive network before the agent starts. The package-install carve-out no longer exists while the agent is running. Whether that was a response to the incident or independent convergence isn’t answerable from the repo — see exploitgym-repo for the sequence.

Related

openai-huggingface-incident · defender-guardrail-asymmetry · defensive-security · akrites-oss-ai-threats · google-beyond-zero · synthesis