The short answer
In July 2026, security firm Theori ran its Xint autonomous pentest platform against 28 applications built with AI coding tools and confirmed 434 exploitable vulnerabilities — 196 in newly built apps and 238 in a single legacy system rewritten with AI assistance. The striking part is the shape of the failures. The models, spanning five frontier releases from Anthropic and OpenAI, had clearly improved: classic SQL injection and cross-site scripting were rare because prepared statements and input sanitisation came by default. What they missed was everything that needs a view of the whole system — missing rate limits and unbounded queries (denial of service), unchecked object references (IDOR), and default secrets pasted straight from quick-start templates.
For teams that have wired AI assistants into daily development, the takeaway is not "stop using them." It is that AI produces code that looks right and compiles, while omitting the security properties a human architect enforces without thinking. That gap is cheap to close with review and expensive to ignore — which is why AI-written code belongs inside a secure software development process, not shipped straight from the prompt to production.
What Theori tested
Theori built the study around its Xint platform, which runs autonomous, AI-driven penetration tests combining runtime probing with source-code analysis. The team pointed it at 28 applications produced through different AI coding workflows — from a one-line "build me an app" prompt to more structured, spec-driven generation — using five frontier models from Anthropic and OpenAI. Each app got roughly a 30-minute scan. The raw output was noisy: 8,827 potential detections. After deduplication and exploitability triage, 434 issues survived as genuinely exploitable, and those are the numbers that matter.
The split is instructive. Two greenfield apps, generated from scratch, accounted for 196 confirmed flaws. But a single brownfield case — the legacy PHP forum Gnuboard7, migrated with AI help to a Laravel and React stack — carried 238 on its own, more than both greenfield apps combined. That is the clearest signal in the report: AI-assisted rewrites of existing systems do not just inherit old risk, they multiply it as the same missing checks repeat across a larger surface. For anyone weighing an AI-accelerated legacy modernization, that is the line to underline before starting.
Which bugs the AI left behind
The vulnerability mix is the real story, because it tells you where to look in your own AI-generated code. Resource exhaustion and denial of service topped the list at around 21% of findings — unbounded pagination that returns an entire table, endpoints with no rate limit, and synchronous blocking operations that let one request tie up a worker. The impact, as Theori framed it, is not stolen data but "runaway server cost or a server an attacker can knock over." For a SaaS running on metered cloud, that is a billing incident and an availability incident at once.
Broken authorization, chiefly insecure direct object references (IDOR), came next. Here the size effect is sharp: about 11% of findings in the small greenfield apps, rising to roughly 28% in the rewritten CMS, because the AI applied — or forgot — ownership checks inconsistently across hundreds of endpoints. Access-boundary problems such as path traversal and server-side request forgery added another tranche. And among the 23 critical-severity findings, the pattern that should worry every team is the simplest: 11 were hardcoded or default secrets — default SECRET_KEY values, JWT signing keys, and embedded credentials lifted from starter templates — plus 6 cases of debug mode left on, which turns a stack trace into remote code execution.
The findings at a glance
The headline classes, drawn from Theori's confirmed set of 434 exploitable issues:
| Finding | What Theori reported |
|---|---|
| Apps analysed | 28 AI-generated apps, 5 frontier models (Anthropic & OpenAI) |
| Raw → confirmed | 8,827 detections triaged to 434 exploitable |
| Greenfield vs brownfield | 196 in two new apps; 238 in one AI-rewritten legacy app |
| Most common class | Resource exhaustion / DoS (≈21%) |
| Second class | Broken authorization / IDOR (11% small → 28% large) |
| Critical findings | 23 total — 11 hardcoded/default secrets, 6 debug-mode RCE |
| Handled well | SQL injection and XSS — rare, thanks to default prepared statements & sanitisation |
Why AI code fails this way
The pattern is not random, and understanding it tells you what review to prioritise. A language model generates code token by token from local context. It is very good at the shape of a safe database query or an escaped template, because those are local, repeated patterns it has seen millions of times. It is poor at properties that only exist at the level of the whole system: which user owns this record, how many rows this endpoint should ever return, which route must never run with debug on, where the trust boundary between tenant data actually sits. Those are architectural facts, not line-level idioms.
Theori's CTO, Andrew Wesie, put it plainly: the "vulnerability classes that models still struggle with are those that require system-level understanding." That single sentence should reshape how teams divide labour with AI. The models have earned trust on the mechanical, injection-style bugs; they have not earned it on authorization, resource governance or secrets hygiene. Theori's own recommendation follows directly — lean on automated tools to screen high volumes of AI-generated code for the repetitive classes, and keep human experts focused on threat modelling and architecture rather than line-by-line review. That is the same division of labour we build into how we ship AI agents and assistants for clients: let the model draft, but never let it be the last set of eyes on a trust boundary.
What it means for US & EU software teams
Read at altitude, the study is a warning about velocity without a safety net. AI assistants let a small team ship a working application in days, and every one of the 28 apps worked — the flaws were invisible until an autonomous pentester went looking. Teams that measure only "does it run" are accumulating a security debt they cannot see, and the brownfield result shows that debt compounds as the codebase grows. The answer is not slower development; it is making automated security review a non-negotiable stage in the pipeline, so the DoS, IDOR and secrets classes are caught by machines at the speed the code is written.
For regulated products the stakes are higher than a bug ticket. In FinTech and HealthTech, an IDOR that exposes another customer's records is a data-breach event with GDPR 72-hour and, for financial firms, DORA incident clocks attached. A hardcoded signing key in a public repository is a disclosure waiting to happen. The EU AI Act and frameworks like SOC 2 already expect a documented, controlled development lifecycle — and "our AI wrote it and we shipped it" is the opposite of that. The teams that will move fast and stay compliant are the ones treating AI output as untrusted input to a real secure-SDLC, not as finished work.
What to do this week
A short, practical sequence that turns the study into action rather than anxiety:
- Scan for secrets in CI. Add secret detection to your pipeline and block commits; rotate any key that ever appeared in source or a template. This neutralises the single largest critical class the study found.
- Turn off development defaults. Audit every environment for debug mode, verbose errors and default framework settings left on — the source of the debug-mode RCEs.
- Load-test and rate-limit. Add rate limits, pagination caps and timeouts to AI-generated endpoints; probe for unbounded queries before an attacker or a cloud bill does.
- Review authorization by hand. IDOR is exactly what automation misses and what grows with scale — have a human verify ownership checks on every endpoint that returns user data.
- Make AppSec a pipeline stage. Put automated security review in front of merge for AI-written code, and route anything touching a trust boundary to a human owner.
None of this argues against AI coding tools — the productivity case is real, and the models have genuinely closed the door on the injection bugs that plagued a generation of apps. But the study is a clear signal: AI writes code that passes a demo, not code that survives an attacker. The teams that add the missing review layer get both speed and safety; the ones that skip it are shipping 434-flaw apps without knowing it.
Frequently asked questions
What did the Theori study of AI-generated code find?
Theori ran its Xint autonomous pentest platform against 28 apps built with AI tools across five frontier models from Anthropic and OpenAI, triaged 8,827 raw detections, and confirmed 434 exploitable vulnerabilities — 196 in greenfield apps and 238 in one AI-rewritten legacy app. Resource-exhaustion DoS led, followed by broken authorization; of 23 critical findings, 11 were hardcoded or default secrets and 6 were debug-mode RCE.
Why does AI-generated code contain security flaws?
The models handled SQL injection and XSS well using prepared statements and sanitisation, but they struggle with system-level reasoning — trust boundaries, resource limits and data ownership. That is why they omit rate limits, leave object references unchecked (IDOR), and paste default secrets from templates. As Theori CTO Andrew Wesie noted, the hard classes are those that require system-level understanding.
Do vulnerabilities get worse in larger AI-generated codebases?
Yes. IDOR appeared in about 11% of findings in the small greenfield apps but rose to roughly 28% in the rewritten CMS, where the same gap repeated across hundreds of endpoints. The single brownfield app carried 238 confirmed flaws — more than both greenfield apps combined (196) — showing that AI-assisted rewrites concentrate risk as scope grows.
Is it safe to use AI coding tools in production?
Yes, with review. The productivity gain is real and the models handle common injection bugs, but their output should not ship unreviewed. Keep AI-written code inside a secure SDLC: automated security review at high volume for the repetitive DoS, authorization and secrets issues, plus human engineers owning threat modelling and architecture, which is where the models fall short.
What should teams do about hardcoded secrets in AI-generated apps?
Hardcoded and default secrets were nearly half of the critical findings. Add secret scanning to CI to block commits, move keys to a managed secrets store or environment injection, rotate any credential that ever appeared in source or a template, and never let a framework's development default reach production. These are cheap, automatable controls that remove the highest-severity class the study found.
Sources
SecurityWeek — Vibe-Coded Apps Riddled With Exploitable Security Flaws, 22 July 2026
Help Net Security — The AI code vulnerabilities that grow with your app, 23 July 2026
Cybersecurity News — What 434 AI-Generated Vulnerabilities Reveal About Secure Software Development, July 2026