Why AI-generated vulnerability patches still require expert human review

We studied what happens when Large Language Models (LLMs) generate vulnerability patches for recently disclosed, complex vulnerabilities. Our data shows that LLMs produce Fix-Like Artifacts with Embedded Defects (FLAWED) 53.9% of the time when complex patches are required.

By sharing the results of our research, our goal is to provide defenders with the tooling and methodology necessary to improve vulnerability remediation outcomes at scale. Along with this blog, we are releasing our tooling, datasets, and an in-depth research paper to share what we’ve learned.

With models and agentic harnesses now performing impactful vulnerability discovery at scale, as recently witnessed with Anthropic’s Project Glasswing, defenders are naturally turning to AI agents to generate vulnerability patches. Indeed, this exact response made headlines in June with OpenAI’s announcement of Project Daybreak in collaboration with a number of partners who aim to “Patch the Planet”.

But how effective are LLMs at producing patches without altering the application’s behavior? Do the patches they generate actually mitigate the vulnerabilities in question? And how frequently might those patches introduce new vulnerabilities? We set out to answer these questions as the inaugural research project for 1Password’s brand-new security research team, Off-by-1 Labs. The paper's title is Frontier Models’ Vulnerability Patches are Often F.L.A.W.E.D., and unlike other research in this space, this study targets novel vulnerabilities not likely to be found in the training data of frontier models, and then exercises frontier models to determine their efficacy at successfully producing patches.

Across six recently-disclosed CVEs, we produced 6,080 patches using two frontier, cyber-capable reasoning models. The average success rate for generating a patch that fully resolved the vulnerability (without materially changing application behavior) was just 26.0%. Patches that successfully resolved the vulnerability, but altered the application’s behavior in the process, occurred 20.1% of the time. Examples of application behavior changes we observed included reimplementing file-local parsers, changing “allow list” logic to “deny list” logic, and other similar changes. 

Conversely, LLM-generated patches did not resolve the vulnerability, added a new vulnerability, or both, an average 53.9% of the time. You can read further details about our findings, observations, and conclusions in the research paper we’ve published alongside this post.

Targeted vulnerabilities

In order to validate the efficacy of LLM-generated patches, we targeted six recently disclosed, novel vulnerabilities in open source software that required complex patch implementations in order to fully resolve the underlying issue(s). The vulnerabilities used to assess patch efficacy included: 

• CVE-2026-31431 - Linux privilege escalation (“Copy Fail”)

• CVE-2026-34197 - ActiveMQ Remote Code Execution

• CVE-2026-8512 - Use-after-free in Chrome's File System Access API on macOS

• CVE-2026-45185 - EXIM unauthenticated Remote Code Execution

• CVE-2026-22738 - SpringAI SpEL Remote Code Execution

• GHSA-wpqr-6v78-jr5g - Gemini CLI Remote Code Execution

Given that open source code is highly likely to exist within the training datasets of frontier models, we specifically chose these vulnerabilities based on the recency of their disclosures, since they and their associated patches were unlikely to be included as part of current models’ training data. Even so, given the codebase’s presence in the training data, our hypothesis for this research was that vulnerabilities in open source code would produce reasonably high patch success rates (> 67%) when automatically generating patches using frontier LLMs. The results were significantly lower and more uneven than we hypothesized. 

For further details on the patch success rates of each model per vulnerability, please see the research paper published alongside this post.

Methodology and the cost of patching

With each model, we generated 540 patches per vulnerability. These patches were generated in sets of 20 under varied conditions, including three different environment configurations and nine structured prompt templates that were unique per vulnerability. We also tracked whether a model attempted to retrieve information about an available patch to the vulnerability, and for our final report we flagged all instances where a model was determined to have behaved in this way when tasked with producing a patch.

With the flagged patches removed, we qualified patch outcomes across five scenarios:

• Scenario 1 (S1): Complete fix; does not alter application behavior

• Scenario 2 (S2): Complete fix; alters application behavior

• Scenario 3 (S3): Does not fix the vulnerability

• Scenario 4 (S4): Complete fix of the old vulnerability while adding a new vulnerability

• Scenario 5 (S5): Does not fix the vulnerability while adding a new vulnerability

Figure 1: Average patch success rate across 6,080 patches, with 400 flagged patches removed from reporting.

The inference cost for OpenAI’s ChatGPT-5.5 with Trusted Access for Cyber guardrails and the default “medium” effort setting was an average $2.11 per attempted patch and validation cycle. Likewise, the cost for Anthropic’s Opus 4.8 with Cyber Verification Program guardrails and the default “high” effort setting was an average $2.81 per attempted patch and validation cycle.

While these costs might seem trivial compared to the human cost of producing an effective patch, the likely outcome of producing such a patch without altering application behavior was nearly 1 in 4. In other words, LLM-produced patches still require review from a skilled engineer with domain expertise to ensure they actually achieve the desired mitigation(s) without altering application behavior. 

In addition to the corresponding research paper, we are releasing the full set of generated patches, along with the software we designed to generate, validate, compare, and manually verify these patches. As you will see from the patches in the dataset, the difference between a successful patch and one that alters application behavior, leaves the vulnerability unresolved, or even introduces a new vulnerability is quite often fragile, and not always clear at a glance.

In our experiments, more than 33% of the S1 and S2 patches generated by an LLM contained subtleties that we would qualify as “fragile” from a security context. These patches guard against vulnerable inputs with narrowly targeted checks, rather than fully addressing the underlying vulnerable code. For instance, when tasked with patching the SpringAI CVE, both models frequently generated patches that simply escaped specific characters in user input. The patch thus blocked the malicious input string used in the proof-of-concept presented to the model, while leaving the root cause of the vulnerability entirely untouched. If the guarded code were to become reachable again by using alternative inputs, it would lead to the old vulnerability resurfacing in the software. 

Recommendations for improving patch outcomes

We recognize that the outcomes of our research creates a challenge for defenders who are struggling to address a tsunami of vulnerability reports. As such, we reached out to the Frontier AI labs whose models we studied for feedback and recommendations regarding further research. Below is the feedback provided, along with some of our thoughts on what comes next.

Feedback and recommendations from Anthropic: patch generation has outpaced patch verification, and the fix is to make verification execution-grounded rather than inspection-based, while keeping domain experts as the final reviewers at current model capabilities. We've made this point publicly: "Progress on software security used to be limited by how quickly we could find new vulnerabilities. Now it's limited by how quickly we can verify, disclose, and patch." (Project Glasswing initial update, May 2026)

Additional thoughts from 1Password: based on the results of our research, we strongly agree with Anthropic’s feedback on keeping domain experts in the loop as a final reviewer given current model capabilities. We greatly appreciate Anthropic’s review of our research, and the extensive feedback they provided for further consideration in future research.

Final thoughts

Our recommendation today is to leverage the FLAWED tooling we’ve released in order to determine how effective LLMs are at patching vulnerabilities in your organization’s codebase. At the very least, a sample of patches produced by multiple LLMs on previously-patched vulnerabilities will provide leading indicators for where human expertise still provides the greatest impact, while highlighting areas within your codebase that are not well suited to LLM-generated patching alone.

This research casts a spotlight on how LLMs are asymmetrically changing the balance of the “defender’s dilemma” in the attacker’s favor. As the old saying goes: “an attacker only needs to be right once; a defender needs to be right 100% of the time.” These results paint a troubling picture: LLMs that excel at discovering a wide range of vulnerabilities today are only currently effective at patching a narrow subset of them. Having said that, we have identified opportunities for further research that may yet yield more consistent and robust AI-generated patches.

We believe that the software we’ve released, along with the datasets which include all 6,480 patches we generated, will help developers identify scenarios where AI is likely to produce positive outcomes, or at least to steer them away from situations where AI is likely to generate S4 or S5 patches. In the Case Study section of our research paper, we’ve included one such example where our tooling would have helped defenders identify the limitations of AI-generated patching.

Defenders are once again facing the “mechanic’s dilemma” where they must choose between good, fast, and cheap solutions to address this problem. Producing reliable LLM-generated patches may involve some mix of introducing non-LLM tooling, improving test suite robustness, and/or implementing an AI harness to test for invariants. In the interim, our research shows that human expertise still plays an essential role in the process of fully resolving vulnerabilities in software without introducing unwanted side effects. And even then, humans may still fall victim to cognitive surrender if they are not paying careful attention to the code being generated by LLMs.

Special thanks to Casey Ellis, Jason Haddix, Mike Shema and others for their peer review of our research.

Download the full research paper, Frontier Models’ Vulnerability Patches are Often F.L.A.W.E.D.