In November 2024, MITRE and CISA published the current CWE Top 25 Most Dangerous Software Weaknesses, and cross-site scripting (CWE-79), out-of-bounds write (CWE-787), and SQL injection (CWE-89) held the top three spots — the same three that led the 2023 list. What changed is where those weaknesses are coming from. Large language models now write a meaningful share of the code entering production: GitHub reported in 2023 that Copilot generates on average 46% of code in files where it's enabled, and adoption has only grown since. The trouble is that LLMs learned to code from public repositories full of the exact tutorial-grade patterns the CWE Top 25 exists to flag. A 2025 Veracode benchmark spanning 80-plus coding tasks across 100-plus LLMs found that 45% of AI-generated samples introduced at least one weakness mapping to the OWASP Top 10, which overlaps heavily with the CWE Top 25. Here's how specific CWE Top 25 entries map to the habits driving that number.
How much AI-generated code actually ships with real vulnerabilities?
Somewhere between 4 in 10 and roughly half of AI-generated code samples contain at least one exploitable weakness, depending on the study, language, and task. The earliest large-scale look, NYU's 2021 "Asleep at the Keyboard?" study, ran GitHub Copilot against 89 scenarios built from MITRE's top weakness categories and found about 40% of the completions were vulnerable, including hardcoded credentials (CWE-798) and SQL built through string concatenation (CWE-89). Stanford's 2023 study (Perry et al., published at ACM CCS) went further: developers who used an AI assistant wrote measurably less secure code on the majority of assigned tasks than developers who didn't — and were more confident their code was secure, a false-confidence effect that compounds the risk. The 2025 Veracode GenAI Code Security Report put a fresh number on the trend: 45% of generated code samples failed security testing outright, with the failure rate climbing above 70% for Java specifically. None of these numbers have trended toward zero as models have improved at writing code that compiles and passes functional tests.
Which CWE Top 25 categories show up most often in AI-generated code?
Five categories account for most of what shows up in AI-generated code: Cross-Site Scripting (CWE-79), SQL Injection (CWE-89), Path Traversal (CWE-22), Deserialization of Untrusted Data (CWE-502), and Missing or Incorrect Authorization (CWE-862/CWE-863). SQL injection appears because models default to f-strings and string concatenation to build queries — it's the pattern most common in the tutorials and Stack Overflow answers they were trained on, not the parameterized-query pattern that's actually safe. XSS shows up because AI-generated frontend snippets routinely write user input straight into the DOM with innerHTML instead of a sanitizing accessor; in Veracode's 2025 benchmark, models chose a secure coding pattern for cross-site scripting less than 1 in 5 times. Path traversal turns up in file-serving and upload endpoints where a user-supplied filename gets passed straight into os.path.join with no normalization check. Deserialization flaws come from Python's pickle.loads or PyYAML's default yaml.load being the first suggestion a model offers for "load this config," when the safe equivalents (yaml.safe_load, avoiding pickle for untrusted input) require an extra, unprompted step. Missing authorization shows up constantly in scaffolded API endpoints — a model asked to "add a route that returns the user's orders" will produce working CRUD logic and skip the auth middleware entirely, because the prompt never asked for it.
Why do LLMs keep reproducing the same vulnerability classes instead of learning from them?
Because next-token prediction optimizes for code that looks idiomatic and runs, not code that's hardened, and the training corpus is dominated by example-grade snippets that drop security for clarity. A tutorial teaching SQL in fifteen lines concatenates a string on purpose, because explaining parameterized queries would double the length of the example — and that fifteen-line pattern appears far more often in public code than its production-hardened counterpart, so it wins the statistical majority the model is sampling from. The same dynamic applies to authentication: "hello world" API examples never include middleware, so models trained on millions of them treat auth as optional by default. Context length compounds this — a security requirement stated once at the top of a long spec or system prompt gets diluted or dropped by the time the model reaches the fortieth function it's generating in that session, which is exactly when CWE-862 and CWE-798 findings tend to cluster.
Does model choice or programming language change the risk profile?
Yes — Java-generated code fails security testing roughly twice as often as Python or JavaScript in current benchmarks, and newer frontier models haven't closed that gap. Veracode's 2025 data put Java's failure rate above 70%, against roughly 38–45% for Python, JavaScript, and C#, largely because Java's verbose object-serialization and reflection idioms give models more surface area to reproduce CWE-502 and CWE-611-style flaws per line of code generated. Across model generations, the more striking pattern is what hasn't improved: functional correctness and code quality have risen sharply from GPT-3.5-era models through current frontier models, but the rate of security-relevant failures has stayed roughly flat over that same period in Veracode's testing. In other words, AI-generated code is getting better at doing what you asked and no better, on average, at not introducing a CWE Top 25 weakness while doing it.
Can traditional SAST or code review catch these flaws before they reach production?
Partially — SAST tools reliably flag the syntactic pattern behind a CWE Top 25 weakness, such as a string-built SQL query, but they routinely can't tell whether that pattern is reachable from an untrusted input, and that gap is what turns AI-generated code into an alert-noise problem. A single AI-scaffolded microservice can produce hundreds of CWE-89 and CWE-79 matches from a rule-based scanner, the overwhelming majority of them on code paths no external input ever reaches. Human review doesn't close the gap either: developers accept AI code suggestions at a high rate and review AI-authored diffs faster than hand-written ones of the same size, a documented automation-bias effect that runs in exactly the wrong direction given the vulnerability rates above. The net effect is that CWE Top 25 findings in AI-generated code either get triaged away wholesale because the volume is unmanageable, or they sit in a backlog because no one can quickly tell which ten of the four hundred flagged lines are actually exploitable.
How Safeguard Helps
Safeguard is built for the specific gap between AI code velocity and manual review capacity. Our reachability analysis traces every CWE Top 25 finding — from a CWE-89 SQL injection to a CWE-502 deserialization call — back to whether an actual untrusted input can reach the vulnerable line, so security teams see the handful of exploitable findings instead of the hundreds of syntactic matches a generic scanner returns. Griffin AI, Safeguard's detection engine, is trained specifically on the patterns LLMs like Copilot, Claude Code, and Cursor tend to reproduce, so it catches AI-authored CWE-79, CWE-22, and CWE-862 instances that rule-based SAST rules miss or over-flag. Safeguard also generates and ingests SBOMs for every AI-assisted build, giving teams a record of which components and code paths were machine-generated. When Griffin AI confirms a reachable CWE Top 25 finding, Safeguard opens an auto-fix pull request with the corrected pattern — a parameterized query, a safe deserialization call, an added authorization check — already applied, closing the loop in the same review cycle the vulnerability was introduced in.