Scale of the problem: data from studies 2025–2026
Veracode tested more than 100 LLM on code generation tasks in Java, Python, C# and JavaScript on four categories of vulnerabilities from OWASP Top 10: SQL injection (CWE-89), cross-site scripting (CWE-80), log injection (CWE-117) and weak cryptography (CWE-327). 45% of AI-generated samples contain vulnerabilities. Java showed the worst result - 72% rate rate. 86% of samples do not protect against XSS, 88% are vulnerable to log injection.The March 2026 Veracode update records: the pass rate has not shifted (~55%), although vendors are talking about security-aware training. Models have become better at writing compiled code (90% vs. 20% two years ago), but not more secure. The code is going - and on this good news ends.
At the enterprise level, the picture is tougher. According to Apiiro (analysis of tens of thousands of repositories in Fortune 50 companies, December 2024 - June 2025): AI-assisted developers will commit 3-4 times faster, but the number of security findings has grown from ~1,000 to more than 10,000 per month - a tenfold increase in half a year. Syntactic errors became 76% less, logical bugs - by 60%. The developers feel more productive and more confident. But privilege paths rose 322%, architectural design flaws - 153%. These are AI-generated code vulnerabilities that require in-depth contextual analysis - and that standard SAST scanners pass through most often.
According to the project Vibe Security Radar (presumably related to Georgia Tech; public verification of the methodology at the time of writing is not available), in the three months of the beginning of 2026, about 74 CVEs were identified, attributed to AI tools through the tracing of fixing commit in Git-history. A large part is tied to Claude Code - it leaves characteristic signatures in commit messages, on which it is easy to trace. The rest are GitHub Copilot, Cursor, Devin, Aether. The real number of vulnerabilities, according to researchers, may be 5-10 times higher.
JetBrains on a sample of 24,534 developers in 194 countries: 85% regularly use AI-assistants of programming, 62% rely on a minimum of one AI tool. According to Y Combinator, 25% of winter butch startups 2025 had a codebase, 95%+ generated by AI. The risks of generative programming are scaled proportionally in proportion to adoption - here the arithmetic is simple.
Anatomy of AI-generated code vulnerabilities
Injections without validation: CWE-89, CWE-80, CWE-94
CWE-89 (SQL Injection), CWE-80 (Basic XSS, CWE-79 variant), CWE-94 (Code Injection) - the three most frequent categories of injectable vulnerabilities in AI generated code. Veracode tested four categories (CWE-89, CWE-80, CWE-117, CWE-327), and CWE-94 additionally highlighted in the data of Kaspersky and MITRE CWE Top 25.Why does the model build queries through string concatenation? Because in the training data thousands of such examples. The model's parametrized requests also "knows," but without a clear indication in the industrial party chooses a short path. She's so easier. And it is easier for us to break.
A characteristic pattern that was found in five of my twelve reviews:
Python:
def get_user(request):
username = request.args.get('username')
query = f"SELECT * FROM users WHERE username = '{username}'"
return db.execute(query)
Another typical case - eval() for mathematical operations on user input (CWE-94). The model is optimized for the shortest solution, and eval() - technically the shortest way. For a pentexter, this is a direct access initial access to an arbitrary code execution.
According to Kaspersky, citing the MITRE CWE Top 25, the most frequent problems in the AI code are: CWE-94 (code injection), CWE-78 (OS command injection), CWE-190 (integer overflow), CWE-306 (missing authentication), CWE-434 (unrestricted file upload). All five - classics OWASP Top 10 (A03:2021 Injection, A01:2021 Broken Access Control, A05:2021 Security Misconfiguration).
A separate risk is the degradation of security in iterative edits through follow-up industrial symptoms. According to a study cited in the Kaspersky blog (the original source and methodology are not publicly verified): after five iterations, the GPT-4o code contained 37% more critical vulnerabilities than the original version. With problems for the addition of a feature - 158 vulnerabilities (29 critical). Even with security-focused prompts - 38 new, 7 critical. Each iteration of the industrial system is a potential security regression. The code doesn't get better from being asked - it gets worse.
CVE-2025-48757: Open Supabase database in Loveable
CVE-2025-48757 - CVSS 9.3 (CRITICAL). The lack of a Row Level Security policy in applications generated by the Lovable platform allows the unauthenticated attacker to read and write data to arbitrary tables.Note: the manufacturer (Lovable) disputes the classification, claiming that the responsibility for setting up RLS lies with the client (NOTE in NVD to CVE-2025-48757). A familiar song is "it's a feature, not a bug."
CVSS vector: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N - network access, low attack complexity, no privileges or user interactions, scope with high privacy impact. The root reason - CWE-863 (Incorrect Authorization).
Supabase architecturally assumes that anon key and database URLs fall into the client code - when configured by RLS it is safe. The Lovable AI generator created circuits without a single line of RLS policies. Thousands of users have published apps unaware that anon key actually opens full access to the database.
The security of Lovable Bolt in this case depended entirely on whether AI Row Level Security will enable the schema generation. Spoiler: not included. On MITRE ATT&CK this Exploit Public-Facing Application (T1190, Initial Access) -> Data from Cloud Storage (T1530, Collection). For operation, it is enough to open DevTools, pull the URL and key:
Bash:
curl 'https://<project>.supabase.co/rest/v1/users?select=*' -H "apikey: <anon_key>" -H "Authorization: Bearer <anon_key>"
If the response contains data - RLS is not configured, a Supabase data leak is possible without a single line of exploit code. According to the Escape.tech report, application scans on Lovable, Base44, Bolt.new and Vibe Studio revealed about 2,038 critical vulnerabilities, more than 400 leaks of secrets, 175 cases of PII disclosure - medical records, financial data, authentication credentials. Everything is in production, with real users.
Slopsquatting: supply chain through LLM hallucinations
About 20% of the AI-generated code refers to packages that do not exist - data from the USENIX Security study, given in the Cloud Security Alliance report. The model "remembers" the structure of package names, but comes up with specific names. Hallucinating, simply put.Attackers exploit this through Compromise Software Dependencies and Development Tools (T1195.001, Initial Access): register false names on PyPI, npm, RubyGems and place malicious code. Developer launches pip install or npm install by AI-generated requirements.txt - and receives a malwar. Unlike typosquatting (similar names), here LLM generates non-existent names itself, and the attacker can only register them. Nice attack, come to think of it.
Checking the security of the AI code in this context begins with the verification of each dependency: pip index versions <package> or npm view <package> version. Package not found - it's a hallucination or already supply chain. With AI code security audit I put this step first, to SAST and logo review.
AI-assistants programming as the target of attack
The surface of the attack is bidirectional. AI tools not only generate vulnerable code - they themselves become targets for supply chain attacks.
According to CSA and Pradeo, CVE was revealed in 2025 against the three largest assistants:
Amazon Q Developer - the attacker operated an incorrectly configured GitHub token to inject malicious code into the VS Code extension. The compromised version was distributed through the VS Code Marketplace for several days. Syntactic error in payload prevented real exploitation. Lucky - literally.
Cursor - CurXecute vulnerability: remote execution of code through prompt injection from the connected MCP server. MCPoison - poisoning of the MCP configuration in the shared repository: the developer approves the legitimate configuration and inconspicuously receives a redirect to the malicious server.
GitHub Copilot - Injecting invisible Unicode-symbols into Copilot and Cursor rule files. The symbols forced AI to insert malicious code into all the generated files. Visually, the file looked clean - and inside sat the bookmark.
That T1195.001 (Compromise Software Dependencies and Development Tools) and T1213.003 (Code Repositories) at the level of the development tool itself. For no-code platform vulnerabilities, the risk is even higher: Lovable and Bolt.new run generated code on their own servers. The vulnerability of the platform automatically means the vulnerability of all applications on it.
For a pentester, an interesting vector opens here: instead of attacking a target application - an attack on an AI tool through a malicious one .cursor/rules or .github/copilot-instructions.md in the shared repository. One file - and potentially compromised all the projects where it will load.
