GenAI Code Security Fall 2026: The Ceiling Moves, But on the Low-Hanging Fruit
For the first time in this research series, the numbers moved. Since we began tracking AI-generated code security, the average pass rate has barely budged from 55–56%. Four snapshots, over 100 models, massive advances in capability… and the average stayed flat. Last quarter, we noted that the ceiling had actually dropped, from 72% (GPT-5 Mini, October 2025) to 68% (GPT-5.5, Summer 2026). The headline was “the ceiling won’t break.”
This quarter, it budged. The average security pass rate jumped from 56% to 62%. This is the first meaningful movement in the series. The vulnerability rate dropped from roughly 44% to ~38%. The new high water mark is 73%, shared by two models. Ten models now clear 60%, up from four, and cross-site scripting (CWE-80) is finally climbing.
But before we call it a breakthrough, the gains deserve a closer look. Because the improvement is real, it is uneven, and it is concentrated on the lowest-hanging fruit in the dataset.
The Fall 2026 Leaderboard
We tested 18 models across four languages (Python, C#, JavaScript, Java) and four CWE categories (CWE-89, CWE-327, CWE-80, CWE-117). Here’s where they landed:
| Rank | Model | Security Pass Rate | Syntax |
| 1 | Claude Opus 5.5 (Anthropic) | 73% | 100% |
| 1 | GPT-6-Sol (OpenAI) | 73% | 100% |
| 3 | Claude Sonnet 5.5 (Anthropic) | 72% | 99% |
| 4 | GPT-5.6-Sol (OpenAI) | 70% | 100% |
| 5 | Grok 4.7 (xAI) | 69% | 100% |
| 6 | Qwen 3.8-Max-0902 (Alibaba) | 68% | 100% |
| 7 | Claude Sonnet 5 (Anthropic) | 66% | 100% |
| 7 | GPT-6-Luna (OpenAI) | 66% | 100% |
| 9 | GLM 5.3 (Z-AI) | 64% | 100% |
| 10 | Gemini 3.8 Flash (Google) | 62% | 100% |
| 11 | Gemini 3.7 Flash (Google) | 60% | 100% |
| 12 | DeepSeek V4 Pro (DeepSeek) | 59% | 100% |
| 13 | Kimi K3 (Moonshot AI) | 58% | 100% |
| 13 | Grok 4.6 (xAI) | 58% | 100% |
| 15 | MiniMax M3 | 56% | 100% |
| 16 | Qwen 3.7-Max (Alibaba) | 50% | 100% |
| 16 | Palmyra X5 (Writer) | 50% | 91% |
| 17 | Nova 2 Lite (Amazon) | 44% | 100% |
A few things stand out.
New co-leaders. Claude Opus 5.5 and GPT-6-Sol are tied at 73%, dethroning GPT-5.5, which led the Summer 2026 snapshot at 68%. Anthropic and OpenAI each place three models in the top seven.
The middle is rising. In July, six of eleven models sat between 50% and 53%. This quarter, only two models are stuck in that band. Ten models clear 60%. The field is separating, and the middle is drifting upward.
The floor hasn’t moved much. The bottom of the leaderboard is still at 44–50%. Model selection remains a security decision: the difference between a model that fails one in three security tasks and one that fails one in two is the volume of vulnerabilities entering your codebase.
The Price of Progress
There is a catch to the improvement that the leaderboard doesn’t show: the models at the top carry premium compute costs. Claude Opus 5.5 ($4/$20 per million input/output tokens) and GPT-6-Sol ($2/$10) are frontier-class models with frontier-class price tags. Notably, both are cheaper than their predecessors, and neither is the most expensive model on the market. What the data does show is that performance tracks with model size: large models average 55% versus 51% for small models, a 3.5-point gap that reverses last year’s finding. Security performance is improving, but the gains concentrate on the larger end of the field.
For most organizations, this creates an uncomfortable reality. The models that produce the most secure code are the ones that cost the most to run at scale, and they still fail on more than one in four security tasks. An organization that routes all its code generation through the most expensive frontier models in pursuit of marginal security gains is burning compute budget on a 73% pass rate that could be achieved more cost-effectively and (more reliably) by using less expensive models and cleaning the output with dedicated security tooling.
The math is straightforward: a mid-tier model at 60% pass rate plus Veracode scanning is more accurate, more cost-effective, and more scalable than a frontier model at 73% with no verification. Tokens spent on the most expensive model are tokens not spent on remediation. We’re looking for a combination of model and verification that gets you to the highest security outcome at the lowest cost. That answer is almost never “use the most expensive model and hope for the best.”
What Moved: CWE-80 Is Carrying the Improvement
Here is where the story gets interesting… and where the headline needs an asterisk.
The overall improvement in security pass rates is not evenly distributed across vulnerability types. It is heavily concentrated in one category: CWE-80, cross-site scripting (XSS).
In the July report, XSS sat at a mean of 15. We wrote it off: “XSS shows a modest uptick in the most recent models, but from a floor so low it barely registers.”
That has changed. The Fall 2026 data shows CWE-80 on a steep upward trajectory, with the mean rising to 18%. That is the single biggest movement in the dataset, and it accounts for a disproportionate share of the visible progress.
Meanwhile, the other three CWE categories barely moved:
| CWE | July 2026 | October 2026 | Trend |
| CWE-327 (Crypto) | 87% | 87.4% | Flat |
| CWE-89 (SQL Injection) | 83% | 83.7% | Flat |
| CWE-80 (XSS) | 15% | 18% (mean) | Steep upward trajectory |
| CWE-117 (Log Injection) | 12% | 12.6% | Flat |
The two strong categories (crypto and SQL injection) were already near their ceiling and stayed there. The two weak categories split: XSS surged, log injection didn’t.
Why CWE-80 Specifically Moves the Needle
XSS is the easiest vulnerability class to fix through pattern recognition, and that is exactly the mechanism by which LLMs improve.
It is a simple, high-frequency pattern. Basic XSS comes down to one rule: don’t put untrusted data into an HTML context without encoding or escaping it. Once a model reliably prefers textContent over innerHTML, or reaches for a framework’s auto-escaping template engine, the failure rate drops sharply. That is a much easier pattern for an LLM to learn than correctly handling log newlines, response-header splitting, or subtle integer overflows.
Training data has shifted toward safe defaults. Modern web frameworks make the safe path the default or the path of least resistance. Public code, tutorials, and GitHub repos increasingly show the safe pattern. Models trained on more recent data see far more examples of “just use the framework’s escaping” than of raw string concatenation into HTML. Older models were trained on a higher proportion of the insecure legacy style.
XSS is the most heavily documented and taught vulnerability. There is an enormous volume of positive and negative examples — blog posts, CTF write-ups, OWASP material, security courses, “how to fix XSS” snippets. Alignment and safety fine-tuning disproportionately cover classic web injection issues because they are easy to generate, easy to judge, and high-visibility. Log injection and response splitting get far less of that treatment.
The safe API is short and obvious. In the languages we test, there is usually a clear, well-known safe function for output encoding. Models tend to follow the shortest path the language or implied libraries offer. For XSS, that path has become safer. For log injection, the short path is still often the vulnerable one.
Evaluation sensitivity. Security benchmarks treat CWE-80 as a clear pass/fail: does untrusted data reach an HTML sink without neutralization? A model that starts routinely choosing the safe sink produces a large, measurable jump. Harder CWEs require deeper reasoning about data flow, context, or side channels and therefore move more slowly.
In short: security metrics look better largely because models have gotten much better at the single easiest, most heavily exemplified, and most framework-supported vulnerability class.
Why the Hard Cases Fall Flat
CWE-117 (log injection) stays flat at ~12% and has shown no sign of recovery across any snapshot in this series. The reason is structural: log injection requires reasoning about data flow — tracing user input through transformations, storage, and rendering across multiple functions to determine whether it reaches a log sink unneutralized. There is no single “safe API” to reach for. The vulnerability is contextual, not pattern-based, and that is exactly where LLMs continue to struggle.
This is the same dynamic we noted in the July report about Java: improvement runs out exactly where pattern recognition runs out. XSS is pattern-recognizable. Log injection is not. The models improve on the former and stall on the latter.
For a deeper look at the importance of context and the risks of relying on AI agents for coding, watch our breakdown: The Risks of AI Agents for Coding.
The Field Is Splitting in New Ways
Beyond the leaderboard, the category-level trend data reveals several shifts worth noting.
General models are pulling further ahead of coding models. General-purpose models average 54% on security tasks; coding-specialized models average 51%. In July, that gap was about 1 percentage point. It has widened to 3. Being optimized to write code faster does not translate to writing it more securely — and the gap is growing, not closing.
Model size now matters. In the October 2025 update, we reported that model size had “essentially no effect” on security performance. That has changed. Large models now average 55%, medium 52%, and small 51% — a 4-point spread. Scaling up doesn’t solve the security problem, but it is looking less irrelevant to it.
Java is still stuck. Java remains the dramatic outlier at ~31%, barely up from 30% in July. It is the only language with a clear upward trajectory across the full series, but it also has the furthest to go. To some degree, this may be a case of Java slowly approaching the mean – improving because it started so low, and likely to plateau when it hits the 50–60% level. For now, the gap between Java and the other three languages is still 26–33 percentage points.
| Language | July 2026 | October 2026 |
| Python | ~62% | 64.22% |
| C# | ~58% | 59.55% |
| JavaScript | ~57% | 56.99% |
| Java | 30% | 31.00% |
Zoom Out: What This Actually Mends
It is worth being honest about what a 56% → 62% improvement in AI code security actually means in the context of your overall risk surface.
The improvement in this dataset is concentrated in basic XSS: a single vulnerability class, and one of the easiest to detect and fix. Meanwhile, the hard cases (log injection, contextual data-flow vulnerabilities) are unchanged. Java is unchanged. The functionality-security gap is unchanged. The best model still fails on more than one in four security tasks.
Now zoom out from AI-generated code to the broader software security picture. According to Veracode’s 2026 State of Software Security report, 82% of organizations now carry security debt — known vulnerabilities that remain unresolved for more than a year. That’s up from 74% in 2025 and 71% in 2024. Critical security debt, flaws that are both high-severity and highly exploitable left unfixed for over a year, now affects 60% of organizations, a 20% jump in a single year. The median time to fix a flaw is 243 days.
And here is the part that puts AI code security in perspective: 66% of the most dangerous, long-lived vulnerabilities come from third-party code. This is libraries, dependencies, and open-source components that this AI code security benchmarks doesn’t test. These flaws take 358 days to fix on average.
An improvement in AI-generated XSS prevention is real progress. But it mends a small corner of a much larger wound. The biggest risks in your software stack (the ones that persist for months, are most likely to be exploited, and in your supply chain) are not the ones that improved in this dataset or that it can even measure.
What Hasn’t Changed
Syntax is still a solved problem sitting at nearly 100% across the board. The vulnerability rate dropped from ~44% to ~38%. This is meaningful, but it still means roughly 4 in 10 AI code generation tasks in this test produced code with a known vulnerability. The functionality-security gap still exists and is not closed by any model. The productivity-security paradox persists: models that can reason through complex problems, write fluent code in four languages, and pass syntax checks almost 100% of the time still introduce detectable vulnerabilities in roughly 4 out of 10 tasks when given no security-specific guidance.
The Bottom Line
The improvement is real! We’re seeing newer models produce more code that is both functional and secure. But it does not mean the gap is closed or that you can stop treating LLM output as untrusted. Gains are not uniform: some CWEs stay flat, and the progress that does exist is concentrated in the easiest vulnerability class. Real-world impact still depends on the surrounding application like output handling, CSP, framework defaults. A model that generates safer snippets can still produce XSS if the application later renders the result unsafely.
The takeaway is not that security is solved. It is that security is improving where it is easiest to improve, and the hard problems remain exactly where they have always been. The most effective strategy isn’t chasing the most expensive model for marginal gains. It’s combining AI code generation with continuous, independent security verification that catches what the model misses and that covers the full risk surface, from first-party code to third-party dependencies.
For the full methodology, historical context across four snapshots, and deeper analysis of every CWE, language, and model category, read the 2026 GenAI Code Security Report.
For the broader picture of software security risk — including security debt, third-party vulnerability trends, and remediation benchmarks — read the 2026 State of Software Security Report.
