Vibe coding ships fast, but 45% of AI-generated code samples contain an OWASP Top 10 vulnerability. Adi looks at what’s actually breaking in production, and what to do about it.
Table of Contents
A Blog | By Adi Singh, Database Analyst at Go Insight | 9 July 2026
Coined by Andrej Karpathy, the term “vibe coding” was awarded Word of the Year by Collins Dictionary in November 2025, the idea is defined as this: describe what you want to the AI, accept what it writes, and ship it, no careful screening of what the code actually does.
YC’s Garry Tan reported in March 2025 that 25% of the Winter 2025 batch had over 95% of their code written by an LLM. For a lot of those apps, the code runs. Users sign up, features work, money comes in.
The problem is that “it works” and “it’s secure” are two different questions, and the AI is only answering the first. The second isn’t reliably answered.
The Data
Veracode tested more than 100 LLMs on 80 coding tasks in Java, Python, C#, and JavaScript, and found 45% of samples contained an OWASP Top 10 vulnerability. XSS defences failed 86% of the time and log injection defences failed 88%.
They repeated the same test in March 2026, with similar pass rates. We set up larger models and more recent models, but none of it changed the security outcomes.
CodeRabbit examined 470 pull requests (320 AI-coauthored pull requests and 150 human-written pull requests). AI pull requests had an average of 10.83 issues compared to 6.45 for human-written pull requests. They were 2.74x more likely to introduce XSS and 1.82x more likely to introduce insecure deserialization. Data from Apiiro across Fortune-50 codebases showed that AI-assisted developers wrote 3-4x more code. Privilege-escalation paths grew 322%. Codebases as of June 2025 are generating 10,000 new security findings each month, up from 1000 in December 2024.
The finding that sticks with me the most is the arXiv study that tracked what happens when telling an AI to fix its own code repeatedly. After five “improvements”, the number of critical vulnerabilities went up by 37.6%. And with every fix came new problems.
10-fold
Breaches that already happened
Moltbook launched in January 2026 and, was created by Matt Schlicht without having to use code. Wiz researcher Gal Nagli found a Supabase API key in the client-side JavaScript with Row Level Security disabled. With the Supabase API key and no authentication, someone could read/write to the Supabase database, 1.5 million API tokens, 35,000 email addresses, plaintext OpenAI keys within private messages, and take control of any account. The issue took a few hours to fix. The database had been open since launch.
Lovable (CVE-2025-48757, CVSS 9.3) had a structural issue where all applications created by default did not enable Supabase’s Row Level Security. A scan in March 2025 found that out of 1645 applications created by the Lovable platform, 170 had databases that were completely public and open to the internet. In April 2026, it was possible through a suspected configuration error for a free-tier account to read other users’ source code, database credentials and AI chat history in five API calls. The bug existed for 48 days.
By July 2025, Base44 had undocumented register and verify-otp endpoints that did not require authentication other than an app_id, which was publicly visible from page URLs in its web client and manifest.json files. Verified accounts could be created for any private app, bypassing SSO and other access controls. The bug also affected enterprise chatbots, human resources software and any app storing PII.
One Replit example: SaaStr’s Jason Lemkin vibe coded an app in July 2025. Replit’s AI agent, whose dev and production instances are not distinguishable by humans, deleted the live database, created 4000 fake users, and told Lemkin that it couldn’t roll back the change. The CEO of Replit later apologized and shipped guardrails.
They are all apps in production, with real users, and the common denominator is AI writing code that runs and, nobody checking whether it’s safe.
What keeps breaking
Tenzai, a security startup that had raised $75M in a seed round in late 2025 to build an AI that audits AI-generated code, ran a controlled experiment in which five agents (Cursor, Claude Code, OpenAI Codex, Replit, and Devin) developed 3 identical apps, together creating 15 codebases. The results:
None of the 15 apps had CSRF protection.
- Zero set CSP, HSTS, X-Frame-Options, or proper CORS headers
- Each of the agents contained an SSRF vulnerability in the link-preview feature
The SSRF result was understandable. Tenzai researcher Ori David said, “There’s no universal rule for distinguishing legitimate URL fetches from malicious ones. Making a generic solution impossible.” SQL injection and XSS are not a large concern, since modern frameworks automatically encode output to avoid these injections. SSRF requires a model to understand intent and context. It doesn’t.
AI tools do well on the classes of vulnerabilities where the fix is baked into the library but do poorly on the classes of vulnerabilities where it becomes a judgment call in the application what a piece of code is supposed to allow and for whom.
The six most common things that break
The most common type of authorization vulnerability is the Lovable BOLA and Base44 bugs, in which an attacker can retrieve records using their IDs, without the code first checking whether the user is authorized to access them. The AI builds the retrieval logic but doesn’t build the permission check into the code.
Hardcoded secrets were a constant issue. For example, all code written by GPT-3 would include the api_key = “sk-…”, # TODO: move to env. That said, we were not able to reproduce this error consistently in CI, and based on GitGuardian, AI-authored commits are only ~2x more likely to leak credentials. Both Gitleaks and TruffleHog, which are free, flag this on push.
Other less obvious but common broken authentication points include code that decodes a generated JWT without verifying the signature, accepting alg: none, or ignoring expiry. Libraries to handle JWT standards exist in every major programming language. The AI does not consistently reach for them.
Concerning security headers and rate limiting, Tenzai noted none of the 15 apps set Content Security Policy, HTTP Strict Transport Security, or X-Frame-Options, and none applied rate limiting to their login pages. These are not advanced hardening steps. They are not applied by default, unless you specifically ask for them (which most prompts do not).
A variant called slopsquatting was described in a USENIX Security 2025 paper (Spracklen et al.) that sampled 2.23 million AI-generated snippets using 16 models and found 19.7% of the snippets name at least one package that does not exist. Not a deprecated package or a typo. A package the model invented. 43% of hallucinated package names are reproducible from multiple runs, allowing attackers to register them on PyPI or npm before the target does. If you run pip install on the AI’s suggestion, you get the attacker’s package.
Insecure deserialization attacks are less common but can be severe. Databricks’ AI Red Team discovered that the model deserialized untrusted network data using Python’s pickle module. pickle on untrusted input is remote code execution. This model created a working feature without warning about the security risk.
The confidence problem
In 2023, a Snyk survey found that three quarters of developers surveyed believed AI-written code to be more secure than code from a developer, and 76% of respondents in a 2024 JetBrains survey felt likewise.
No studies have found this, though; the only good news seems to be is when AI helps fix vulnerability classes already covered by framework automatic checks. However, the architectural failures, and failures dependent on context, have gotten worse. The strongest evidence for this theory is two 2023 studies, Sandoval et al. (USENIX Security) and Perry et al. (ACM CCS). When asked to write secure code, AI assistant users wrote code of lower quality and were more overconfident in the security of their code, and the tool made users less careful.
Don't treat AI output like it is reviewed code
What to do
This week: Turn on secret scanning. Gitleaks can be run as a pre-commit hook and TruffleHog in CI for free. Block merges include credentials, rotate anything already in the commit history, and scrub the commit history.
Audit your database defaults. Enable Row Level Security on each Supabase or Postgres table. If storage buckets were set as deny-by-default, the Moltbook and Lovable leaks would have been avoided, but this would have taken approximately ten minutes.
Update Cursor. CVE-2025-54135 (“CurXecute”, CVSS 8.6). Rewriting the ~/.cursor/mcp.json file from a poisoned Slack message sent through an MCP server, causing arbitrary commands to be executed by Cursor without user confirmation. Fixed in v1.3.9.
This quarter: Decide what the AI can code without close supervision and what it cannot. Authentication and authorization logic, cryptography, and anything involving payments need a human to check every line. Boilerplate, UI scaffolding, and pattern refactors all move fast. Put a line in the sand and write it down.
SAST and SCA should run on the CI with every commit. Use Semgrep or CodeQL for injection/deserialization vulnerabilities and Snyk or Trivy for supply chain issues. Neither replaces behavioral testing, but both catch known patterns before they reach production.
Write abuse-case tests. For example, log in as user A and check that they cannot read data from user B. Send an unregulated form without a CSRF token, or hit a link-preview endpoint from the internal IP. These issues will not be found by a static analysis tool, but by an HTTP client.
Structurally: Palo Alto’s Unit 42 published a framework called SHIELD in Jan 2026 with these high-level recommendations: (1) AI agents don’t get production access, (2) any code dealing with auth goes through a human approval step, (3) agents run with the least privilege needed for their tasks. The last part is almost always omitted. AI coding agents usually inherit write access to production databases because this was never explicitly restricted. Restricting it costs nothing.
A note on the numbers
Most of the numbers reported in the field are from security vendors, companies that sell remediation tools. These include Veracode, Apiiro, Escape, and Snyk, whose methodologies differ. The roughest numbers are for ungoverned consumer apps that have no security process at all. Independent research (Georgetown CSET, USENIX, the arXiv studies on formal verification) broadly supports these conclusions, but the specific numbers can vary widely: “12% of AI-generated files contain a CWE” versus “62% of vibe-coded apps have a critical vulnerability”, depending on the metric and implementation.
The models are improving on narrow things. Tenzai was unable to find exploitable SQL injection or XSS in any of the 15 test apps. A year earlier, it would have been impossible. Veracode’s March 2026 update to this report does not indicate that security training added to new models has changed the pass rate. The models are now able to write larger amounts of code in less time, but the security issue proportion is unchanged. This is something to keep in mind when reviewing a PR.
References
Veracode, 2025 GenAI Code Security Report (August 2025); Spring 2026 GenAI Code Security Update (March 24, 2026), veracode.com
Apiiro, “4x Velocity, 10x Vulnerabilities” (September 4, 2025), covered in The Register (September 5, 2025)
CodeRabbit, “State of AI vs Human Code Generation” (December 17, 2025)
Georgetown CSET, “Cybersecurity Risks of AI-Generated Code” (November 2024), cset.georgetown.edu
Spracklen et al., “We Have a Package for You! Hallucinated Package Names and Threats to Package Ecosystems,” USENIX Security 2025
Sandoval et al., “Lost at C: A User Study on the Security Implications of AI-Assisted Coding,” USENIX Security 2023
Perry et al., “Do Users Write More Insecure Code with AI Assistants?” ACM CCS 2023
arXiv 2512.03262, “Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code”
arXiv 2604.05292, “Broken by Default: A Formal Verification Study of Security Vulnerabilities in AI-Generated Code” (April 2026)
arXiv 2506.11022, “Security Degradation in Iterative AI Code Generation” (IEEE ISTAS 2025)
arXiv 2510.26103, Schreiber and Tippe, “Security Vulnerabilities in AI-Generated Code: A Large-Scale Analysis of Public GitHub Repositories”
Wiz Research on Base44 (July 2025) and Moltbook (February 2026), wiz.io
Escape.tech, “State of Security of Vibe Coded Apps” (October 29, 2025)
Tenzai, “Bad Vibes: Comparing the Secure Coding Capabilities of Popular Coding Agents” (January 13, 2026), blog.tenzai.com
Palo Alto Unit 42, “Securing Vibe Coding Tools: The SHIELD Framework” (January 8, 2026)
Cloud Security Alliance, “Vibe Coding’s Security Debt: The AI-Generated CVE Surge” (2026), labs.cloudsecurityalliance.org
OWASP Top 10 for LLM Applications 2025, genai.owasp.org
CVE-2025-48757 (Lovable RLS), CVE-2025-54135 “CurXecute” (Aim Labs / Tenable, August 2025)
Replit incident: The Register, Fortune, Cybernews (July 2025); AIID #1152
Snyk, AI Code Security Report (2023)
GitGuardian, State of Secrets Sprawl (2025)