The 9 Security Flaws We Find Most Often in AI-Generated Code
Last updated September 2026
The AI generated code security vulnerabilities we find most often are not exotic. Nine flaws account for most of what a rescue audit turns up: missing authorization, unescaped output, unsanitized logging, hardcoded secrets, unverified dependencies, client-side-only validation, absent rate limits, leaked error detail, and unguarded prompt paths. All nine are cheap to find and cheap to fix before launch.
How common are AI generated code security vulnerabilities in 2026?
Common enough that the base rate should change how you review. Veracode’s Spring 2026 GenAI Code Security update, which has now run the same benchmark across more than 150 large language models, found that 45 percent of AI-generated code contained a known vulnerability when the prompt did not explicitly ask for secure code. That pass rate has sat near 55 percent across two years of model releases, while syntax correctness climbed above 95 percent. Models got much better at writing code that runs and no better at writing code that holds.
The failures are not spread evenly, which is the useful part. Across 80 coding tasks in four languages, SQL injection passed 82 percent of the time and insecure cryptographic algorithms passed 86 percent. Cross-site scripting passed 15 percent. Log injection passed 13 percent. Java passed 29 percent against 62 percent for Python. Reasoning-focused models reached 70 to 72 percent, better but nowhere near a number you would accept from a human contractor.
Read that as a map of where to look. The vulnerability classes with decades of framework defaults behind them are largely handled. The classes that require the model to hold context from three files away are not, and that is exactly the shape of the nine flaws below.
Which 9 security flaws show up most often in AI-generated code?
Ordered by how often we open a file and find one. The last column is the cheapest check that catches it, because a finding you cannot reproduce on demand does not get fixed.
| # | Flaw | CWE | Why the model produces it | Check that catches it |
|---|---|---|---|---|
| 1 | Authenticated route with no authorization check | CWE-862, CWE-639 | The prompt said “logged-in users”, so it added a session check and stopped | Call every object-scoped endpoint with a second valid account’s token |
| 2 | Unescaped user data rendered to the browser | CWE-79, CWE-80 | Escaping lives in the template layer the model was not shown | Inject a script payload into every field that renders anywhere |
| 3 | Raw user input written into application logs | CWE-117 | Logging is treated as internal, so nothing is sanitized | Grep for logger calls with string interpolation of request data |
| 4 | Hardcoded API keys, tokens, and connection strings | CWE-798 | A literal value makes the generated snippet run on the first try | Run a secret scanner over full git history, not the working tree |
| 5 | Dependencies that are unpinned, abandoned, or nonexistent | CWE-1104 | Package names are predicted, not looked up | Diff every import against the lockfile and the registry’s publish date |
| 6 | Validation enforced only in the client | CWE-602 | The UI code and the API handler were generated in separate sessions | Replay the same request with curl, bypassing the form entirely |
| 7 | No rate limit or quota on expensive endpoints | CWE-770 | Nobody asked for one, and it is invisible in a demo | Loop the login, export, and model-calling routes 200 times |
| 8 | Stack traces and driver errors returned to the caller | CWE-209 | Verbose errors were useful while the assistant was debugging | Send malformed input to every endpoint and read the response body |
| 9 | Unbounded prompt and tool paths in AI features | OWASP LLM01 | User text, retrieved documents, and system instructions share one string | Put an instruction inside a document the retriever will fetch |
Flaw one is the expensive one. Authentication and authorization get collapsed into a single idea, so the generated handler confirms who you are and never confirms the record belongs to you. It passes every test an assistant writes for it, because those tests use one account. It is also the flaw most likely to become a disclosure event rather than an incident ticket, since the person who finds it is a customer holding someone else’s data.
Flaw four has the clearest public evidence. GitGuardian’s State of Secrets Sprawl 2026 counted 28.65 million new hardcoded secrets committed to public GitHub during 2025, up 34 percent year over year, with AI service credentials the fastest-growing category at 1,275,105 leaked instances, an 81 percent jump. Their commit-level analysis puts the leak rate on AI-assisted commits at 3.2 percent against a 1.5 percent baseline. Worse, 64 percent of the valid secrets they found in 2022 were still live in January 2026, which tells you that rotation is the step teams skip.
Flaw nine is newer and gets skipped in audits because it does not look like code. If your product retrieves a document and hands it to a model that can call a tool, then the document is executable input. Treat retrieved content as untrusted, keep tool permissions narrower than the user’s own, and log every tool call with the prompt that triggered it.
Why do assistants keep producing the same AI generated code security vulnerabilities?
Three mechanisms, all structural rather than accidental.
The model optimizes for the request in front of it. Asked for an endpoint that returns an invoice, it returns an invoice. Authorization is a property of the system, not of the function, and nothing in the prompt represents the system.
The training corpus is public code, and public code is full of tutorials where the secret is inline and the error handler prints the exception. Those patterns are statistically normal, which is precisely what the model reproduces.
Finally, the review that would catch all of this is the step teams drop first when velocity rises. That is the same mechanism we described in our piece on why AI-generated code compounds technical debt faster than human code: output volume goes up, review capacity does not, and the gap becomes the defect rate.
Is the hallucinated dependency risk still what the headlines claim?
This is where most of the current first page of search results is out of date, so it is worth being precise. The USENIX Security 2025 study by Spracklen and colleagues generated 576,000 code samples from 16 models and found that 19.7 percent of recommended packages did not exist, with commercial models averaging 5.2 percent and open-source models 21.7 percent, across 205,474 unique hallucinated names. Nearly every article on this topic still quotes the 19.7 percent figure without the split.
A 2026 replication of that methodology, run in April 2026 against five frontier models released between October 2025 and March 2026 across 199,845 paired Python and JavaScript prompts, found hallucination rates between 4.62 percent and 6.10 percent. The range compressed by roughly an order of magnitude. That is the good news, and it is why quoting the old number to justify a tooling purchase is a mistake.
The bad news is in the same paper: 127 package names were hallucinated identically by all five models, and 53 of those remained registrable after registry defenses. A name that every model invents the same way is a supply chain target that does not depend on which assistant your team uses. Lower rate, sharper edge. Pin your dependencies, check publish dates, and fail the build on any import that is not in the lockfile.
How do you find these AI generated code security vulnerabilities in your own repo this week?
Six checks, in order of return per hour. A senior engineer gets through all six on a mid-sized codebase in about two days.
- Two-account test on every object-scoped endpoint (3 hours). Authenticate as user A, then request user B’s records by ID. This single test finds flaw one, and it is the one your test suite structurally cannot find.
- Secret scan across full history (1 hour). Scan every commit, not the current tree. Then rotate what you find, because detection without rotation changes nothing.
- Lockfile and import diff (2 hours). Every import resolved against the lockfile, every new package checked for publish date, download history, and repository. Anything under a few months old with no history gets a human decision.
- Replay the form submissions with curl (2 hours). Strip the client and send the request directly. Whatever the API accepts is your real validation layer.
- Loop the expensive routes (1 hour). Two hundred requests against login, export, search, and any endpoint that calls a model. No 429 means no rate limit.
- Read the error bodies (1 hour). Malformed input to every endpoint, then read what comes back. Stack traces, driver errors, and internal paths all go in the findings list.
Those six produce a ranked list rather than a scanner dump, which matters because the hard part of remediation is deciding what to leave alone. The full ten-day version of this process, including the fix-versus-rewrite rule, is written up in our guide to auditing an AI-generated codebase in 10 days.
Book a Code Review
TopDevz engineers average more than ten years of experience and read AI-generated code for a living, from offices in Sacramento, California and Toronto, Ontario. If you want the nine flaws checked properly rather than sampled, a Rescue Audit is $4,950, is credited toward remediation if you proceed, and delivers a ranked findings report with reproduction steps for each item.
If you are not ready for an audit, book a code review and a senior engineer will look at the riskiest part of your codebase and tell you what they would fix first.