Asked to avoid vulnerabilities, coding agents still shipped exploitable code in more than a third of real CVE tasks

How often the exploit still worked

Every task is a real project at the version just before a security fix: Firefly III, Snipe-IT, OpenEMR, Grav, MLflow and fourteen more. The function the fix changed is removed, and the agent is asked to fill it back in. The prompt even tells it to "make every effort to avoid introducing security vulnerabilities". Then the project's tests run, and the exploit for the original vulnerability runs against the agent's version.

Even with that instruction, the exploit worked in 35% to 40% of runs.

What they got wrong

Most of the mistakes were missing checks: on where a request may come from, on where a file path may lead, and on who may use a page.

All three agents together, all 38 tasks, no security tool.

Seven tasks caught every agent on every run. In MLflow, every agent rebuilt an experiment's artifact check that a crafted path walks straight out of. In Firefly III, every agent restored routes that change data on a plain link click, so another site can trigger them for a logged-in user. In OpenEMR, every agent rewrote the patient amendments page without the permission check the fix added. Code injection and file upload flaws were rare. What the agents kept shipping was code that works but is missing a check.

With LeoPrevent

LeoPrevent is the security tool we build. It reviews what the agent wrote when the agent finishes its turn and tells the agent what it found. It doesn't block anything. We ran the same tasks with it, in the same sealed setup.

With LeoPrevent, all three agents shipped exploitable code much less often: Claude Opus 5.5 63% less (46 runs to 17), GPT-6 Astra 45% less (40 to 22) and GPT-6.1 Sol 42% less (43 to 25). We fixed in advance that each task counts once, by the majority of its three runs: on that test LeoPrevent made 10 tasks safe for Opus 5.5, 7 for Astra and 6 for Sol, and made no task worse for any of them.

How we measured it

• Benchmark. A.S.E (AICGSecEval, paper), from Tencent with Fudan, Peking, Shanghai Jiao Tong, Tsinghua and Zhejiang universities. Each task is a real project at the commit before a CVE fix, with the function behind the CVE removed. Of the 144 distinct tasks, 38 can be measured: 70 are C or C++, which LeoPrevent does not cover yet; 29 have an exploit that never exercises the agent's code; and 7 can no longer run because their image or repository is gone. We report all 38.
• Agents. Claude Opus 5.5 in Claude Code, and GPT-6 Astra and GPT-6.1 Sol in the Codex CLI at medium effort. Claude Code used A.S.E's own tool settings. Each got A.S.E's own prompt, in an isolated container, three times per task.
• Sealed history. A.S.E removes the function but leaves the original in the repository's git history, and agents with a shell can read it back. We sealed every repository so its history holds only the version with the function removed.
• Grading. A.S.E's own checks, unchanged: the project's tests must pass, then the exploit for the original CVE runs against the agent's version. The exploit decides: if it works, the run counts as vulnerable.
• Analysis. We fixed the comparison in advance, on all 38 tasks: each task counts once, by the majority of its three runs, with a two-sided sign test on tasks that got better against tasks that got worse.

What we found in the benchmark

Running A.S.E carefully turned up problems in the benchmark itself, which would have skewed results in both directions. We reported them upstream as nine issues and four pull requests, and worked around each one here. None has been answered yet; the repository has had no changes since May 2026.

• The answer was in the git history. The removed function was still in the repository's last commit, and later commits held the official fix. Before we sealed the repositories, agents with a shell sometimes read it.
• Some verdicts do not depend on the agent's code. In 29 tasks the exploit never runs the function the agent writes, the removed code is not on the exploited path, the check is a static heuristic, or the exploit falls back to a simulated result. We left those tasks out.
• Two tasks could never produce a verdict because of bugs in the harness rather than in the tasks, and tasks whose images only ship for Intel could not run on Apple Silicon at all. Both are fixed in our copy, with the fixes offered upstream.

Data

Every run's verdict is published so the numbers above can be recomputed:

• cells.csv: one row per run (684), with the task, its CVE, project, language and weakness, the cycle, the model and agent, the arm and the verdict.
• analysis.txt: every count and p-value on this page, computed from that file.