AI-Generated Code Security in 2026: What a Benchmark, a Lab Study and GitHub Data Each Show

Ask how secure AI-written code is, and the honest answer depends entirely on what was measured. In 2026 three groups tried to answer the question with three different instruments: a vendor ran the same 80-task benchmark against a growing roster of language models, two academic researchers generated nine small automation scripts and counted the flaws in each one, and a separate team pulled tens of thousands of real commits off GitHub to compare AI-assisted code against human-written code in the same repositories. None of the three is wrong. They simply point at different slices of what "AI writes code" means in practice.

That matters for anyone deciding how much to trust a model's output, because the three studies do not just disagree on a percentage — they disagree by tens of percentage points, in both directions, depending on whether the code was written to a prompt designed to surface a specific flaw, written once by a non-expert for a real task, or merged into a production codebase under whatever review process that codebase already has.

The starting point is the most widely cited of the three: Veracode's recurring GenAI Code Security Report, which the company has rerun periodically since first testing the idea, most recently publishing results on 28 July 2026.

The benchmark: 80 tasks, four languages, no security hints

Veracode's method, described in its 28 July 2026 report, is a fixed test battery: 80 coding tasks spanning four languages — Java, JavaScript, C# and Python — crossed with four vulnerability categories tracked by MITRE's Common Weakness Enumeration: SQL injection (CWE-89), cross-site scripting (CWE-80), log injection (CWE-117) and insecure cryptographic algorithms (CWE-327), with five task instances for each language-CWE pairing. Models are prompted "out of the box," with no security-specific instructions, and the resulting code is run through Veracode's own static analysis (SAST) tool to check whether a known vulnerability pattern is present.

In the July 2026 round, Veracode reported an average security pass rate of 56% across the field, which it describes as barely changed from the 55% recorded in the previous round. Put the other way, roughly 44% of code-generation tasks in the 2026 report introduced a vulnerability the static analyzer could detect. The best performer, OpenAI's GPT-5.5, passed 68% of tasks, while more than half of the models tested clustered between 50% and 53%. Reasoning models averaged 56% against 51% for non-reasoning models in the same report, and coding-specialized models (51%) did not outperform general-purpose ones (52%) — a model built to write code faster was not, on this test, writing it more safely.

The vulnerability categories did not fail evenly. Models passed SQL injection tasks 83% of the time and cryptography tasks 87% of the time in the July 2026 report, but passed cross-site scripting tasks only 15% of the time and log injection tasks only 12% of the time. An interim update Veracode published earlier in the year, the Spring 2026 GenAI Code Security Update, found a similar shape with slightly different numbers from an earlier model snapshot: SQL injection 82%, cryptography 86%, cross-site scripting 15%, log injection 13%, and a language breakdown showing Python at 62%, C# at 58%, JavaScript at 57% and Java at 29%. The same update found OpenAI's reasoning models reaching 70–72% on security tasks, notably above the field average at that snapshot. Veracode frames the overall pattern as a gap between two curves: syntactic correctness is "effectively solved," with models now producing code that compiles or runs correctly nearly all the time, while the ability to avoid specific, well-documented vulnerability classes has not improved at the same pace across the life of the benchmark.

A small lab study: when every script failed

A very different kind of measurement came from a preprint posted to arXiv in July 2026 by Shanna M. Kahn and John D. Hastings, "Security Vulnerability Patterns in AI-Generated Code: A Cross-Model Comparative Study." Rather than running a large battery of narrow tasks, the authors asked three consumer-facing assistants — ChatGPT, Microsoft Copilot and Google Gemini — to write one script each for three realistic automation jobs: web scraping and data extraction, email and document automation, and file and workflow automation. That produced nine scripts in total, three per model.

Every one of the nine scripts contained an exploitable vulnerability, the paper reports. After deduplicating an initial 45 individual findings, the authors identified 17 distinct vulnerability classes across the set, nine of which showed up in code from all three assistants and 14 of which showed up in at least two. Weighted CVSS v3.1 severity scores differed by less than 10% between the three platforms, meaning no model stood out as meaningfully safer than the others on this sample. The authors are explicit about the limits of what this shows: each task domain was generated only once per model, which they describe as a realistic reflection of how a non-expert user would actually behave but which they also flag as a limitation, and the vulnerability review itself was performed by an automated process — using the Claude Code coding assistant to apply a standardized review with a five-finding cap — rather than by manual analysis from a security professional or a dedicated static-analysis tool. A sample of nine scripts, scored by one automated reviewer, is not evidence that AI-written code fails 100% of the time in general; it is evidence that, in this specific small sample, every single-shot output had something wrong with it.

Real-world GitHub data: a smaller gap, in the other direction

The third measurement looked at code already in production rather than code generated for a test. In a preprint first posted in March 2026 and revised in July 2026, "A Large-Scale Comprehensive Measurement of AI-Generated Code in Real-World Repositories," researchers from Indiana University Bloomington's Luddy School of Informatics, Computing, and Engineering and Nanyang Technological University's College of Computing and Data Science assembled a dataset of 19,816 AI-involved code files drawn from 12,749 commits, with data collection running through 31 December 2025. From this they derived 36,855 likely AI-generated code units, matched against 65,391 human-written control units, and 7,471 full-file snapshots paired against 15,424 human-written files. ChatGPT was the dominant tool behind the AI-involved commits at 83.3%, followed by Copilot at 10.8% and DeepSeek at 2.2%; Python accounted for 41.7% of the code examined, ahead of JavaScript (15.4%), Java (8.6%), C++ (7.8%) and TypeScript (7.8%).

Running static-analysis alert counts across both groups, the authors found that AI-involved code carried fewer alerts per thousand lines than human-written code in the same repositories — 10.04 alerts per KLOC against 13.56 for human code — with high-risk alerts roughly comparable between the two (0.514 per KLOC for AI-involved code versus 0.52 for human code). AI-involved code also contained hardcoded secrets less often than human code in this dataset. Human-written code showed substantially more duplication across files, at 26.62% against 13.22% for AI-involved code. The paper's own framing is that, measured this way, the real-world gap between AI-assisted and human-written code is "rather small" compared with what lab-based studies had suggested — a direct contrast with both the benchmark and the nine-script study above.

Why three honest measurements disagree

The disagreement is not a sign that one study is faked and another is correct; it follows from what each study actually sampled. Veracode's benchmark deliberately targets four specific, well-known vulnerability classes with tasks built to trigger them, which is exactly why it can report a precise pass rate per CWE — but a model that passes 83% of SQL-injection tasks and 15% of cross-site-scripting tasks is not "56% secure" in any sense that generalizes to a developer's actual, much more varied workload. The nine-script study captured single, unreviewed, first-draft output from consumer chat interfaces on three specific automation tasks, scored by an automated reviewer rather than a professional audit — a design its own authors flag as too small to generalize, even though "every script failed" is a striking number to report. The GitHub study, by contrast, measured code that had already survived whatever review, testing and iteration a real project applies before a commit lands — AI-involved code that reached a real repository may already be the code a human picked after discarding worse drafts, and the tasks developers hand to AI assistants in practice may skew toward exactly the kind of boilerplate, duplication-prone work where models do reasonably well, rather than toward authentication or cryptography.

None of this is academic. The 2026 Data Breach Investigations Report from Verizon found that vulnerability exploitation was the initial access vector in 31% of breaches, the first time in the report's nineteen-year history that exploiting a vulnerability has overtaken stolen credentials as the most common way into a network. Whatever fraction of newly written code is now AI-assisted, the vulnerability classes that keep showing up across all three 2026 measurements — cross-site scripting and log injection scored worst in Veracode's benchmark both in spring and in July, and appeared repeatedly in the nine-script study's 17 vulnerability classes — are the same categories attackers already know how to exploit.

What this means for anyone writing or reviewing AI-assisted code

The practical lesson is not to pick whichever number is most convenient. A 56% pass rate on Veracode's four-CWE benchmark says something true and specific about how often models avoid four well-defined flaw categories under a no-hints prompt; it says nothing about a codebase that never touches cryptography or raw SQL. A nine-script study saying every output failed says something true about unreviewed, single-shot generation from consumer assistants on three task types; it is not a claim about failure rates at scale. A GitHub analysis finding AI-involved code only slightly behind human code on static-analysis alerts says something true about code that already passed through a project's existing controls; it says nothing about what the first draft looked like before review caught the problem.

For anyone learning to work with these tools, the consistent finding across all three 2026 measurements is narrower than any single headline number: the same handful of vulnerability classes — cross-site scripting and log injection above all — keep failing regardless of which model, which benchmark, or which real-world sample is used, while syntactic correctness and simpler injection patterns like basic SQL queries have largely stopped being the problem. That is a specific, checkable claim, and it is the one worth acting on: run static analysis on AI-authored commits the same way a project would on any other contributor's code, and treat the categories that fail consistently across these three independent measurements as the ones that need a human reviewer's attention every time, not just when a benchmark says so.