Vibe coded and vulnerable

There's a new class of software going into production right now. It works. It has a UI. It handles payments, stores personal data, sometimes connects to ERP systems. And nobody who shipped it actually read the code.

Welcome to the vibe coding era, and the security problem nobody is talking about loudly enough.

What Is Vibe Coding, Exactly?

Andrej Karpathy (ex-OpenAI) coined the term in February 2025. The idea: describe what you want in plain language, let the AI generate the code, don't bother reading it too carefully. "Fully giving in to the vibes."

The tools making this possible: Lovable, Bolt.new, Cursor, v0, Replit, Claude Code, GitHub Copilot. Some are no-code platforms where a non-developer can prompt their way to a deployed web app. Others are AI coding assistants layered on top of real IDEs.

Collins Dictionary made "vibe coding" their Word of the Year 2025. By 2026, 92% of US developers use some form of AI coding assistance. An estimated 46% of all code accepted through GitHub Copilot is now AI-generated, projected to hit 60% by end of year.

63% of vibe coding users identify as non-developers. That's the part that should make you nervous.

The Numbers Are Bad

Let's get the statistics out of the way, because they're stark.

Escape.tech scanned over 5,600 publicly deployed vibe-coded applications and found:

• 65% had security issues
• 58% contained at least one critical vulnerability
• 400+ exposed secrets across the dataset
• 175 instances of exposed PII including bank account data

Veracode tested 100+ LLMs across 80 coding tasks and found 45% of AI-generated code introduces OWASP Top 10 vulnerabilities. That pass rate hasn't improved across testing cycles from 2025 through early 2026 despite vendor marketing claims. Java was worst at a 72% failure rate. Even Python and JavaScript hover between 38-45%.

CodeRabbit's analysis of 470 GitHub pull requests found that AI-authored code produces XSS vulnerabilities at 2.74 times the rate of human-written code.

A 2025 audit of Lovable-built apps in Sweden found 170 out of 1,645 production applications contained exploitable SQL injection and XSS vulnerabilities. That's 10.3% of live apps serving real users.

Georgetown CSET found XSS in 86% of AI-generated code samples tested across five major LLMs.

And the one that should really land: AI-assisted developers at Fortune 50 enterprises produce commits at 3-4x the rate of their peers but introduce security findings at 10x the rate. You ship faster and break more, simultaneously.

CVEs Are Now Being Attributed to AI Tools

Georgia Tech's Systems Software and Security Lab launched the Vibe Security Radar in May 2025 to formally track CVEs caused by AI coding tools. Their methodology: trace the fixing commit backward to determine if an AI tool introduced the bug.

The trajectory is alarming:

• January 2026: 6 CVEs attributed to AI-generated code
• February 2026: 15 CVEs
• March 2026: 35 CVEs

Of the 74 confirmed cases, Claude Code accounts for 27, GitHub Copilot for 4, Devin for 2, Cursor and Aether for 1 each.

Researchers estimate the real number is 5-10x higher because most AI tools leave no commit metadata, making attribution impossible. That projects out to 400-700 AI-introduced vulnerabilities in open-source code in Q1 2026 alone.

The NCSC (UK's National Cyber Security Centre) addressed this directly at RSA Conference in March 2026. Their CEO Richard Horne called on the security community to develop safeguards around vibe coding and described the situation as a "fundamental issue with the quality of technology we use."

The Vulnerability Patterns Are Predictable

Here's the useful part for anyone doing security work: vibe-coded applications fail in consistent, recognizable ways. OX Security's presentation at RSAC 2026 described LLMs as "junior developers" with systematic blind spots. The patterns:

Hardcoded secrets. AI tools embed Stripe keys, OpenAI API keys, database credentials, and cloud tokens directly in frontend JavaScript. GitGuardian documented 28.65 million new hardcoded secrets in public GitHub commits during 2025, a 34% year-over-year increase. AI-assisted commits expose secrets at a 3.2% rate versus 1.5% for human-only commits. In April 2026, one high-profile vibe-coded AI platform leaked 1.5 million API keys because the founder shipped without a single security review.

Broken access control. The Tea app in 2025 exposed private user direct messages to other users because the AI-generated access control logic had no server-side enforcement. Client-side authentication that can be bypassed with browser developer tools is extremely common in Bolt and Lovable-generated apps.

Missing Supabase RLS. The dominant stack for vibe-coded SaaS is React frontend + Supabase backend + Vercel deployment. Supabase uses Row Level Security (RLS) policies to restrict data access. AI tools routinely generate the database schema and API calls but skip RLS configuration entirely, meaning any authenticated user can query any row.

SSRF everywhere. A December 2025 study by Tenzai tested five major AI coding agents building identical features. Every single one introduced Server-Side Request Forgery. Five out of five, 100%. The pattern: an AI-generated "fetch URL for preview" feature that accepts any URL including http://169.254.169.254/latest/meta-data/ (AWS instance metadata).

Slopsquatting. AI models hallucinate package names in predictable, reproducible ways. Attackers register those names on npm and PyPI in advance. The attack requires no phishing. It exploits the statistical predictability of what AI tools will hallucinate when you ask them to add a certain type of dependency.

NEXT_PUBLIC abuse. In Next.js projects (the default choice for most AI coding platforms), any environment variable prefixed with NEXT_PUBLIC_ is bundled into the client-side JavaScript and visible to anyone who views source. AI tools routinely prefix sensitive backend variables incorrectly.

How to Fingerprint a Vibe-Coded App

This is where it gets interesting from a pentesting and reconnaissance perspective. Researchers at a January 2026 paper on arXiv analyzed 33,580 pull requests from five major AI coding agents and achieved a 97.2% F1-score identifying which tool generated the code from commit metadata alone.

The behavioral signatures by tool:

Claude Code: High conditional density (27.2%), elevated comment density (19.8%). Code is well-documented and control-flow-heavy. Tends to be misclassified as Devin when wrong.

GitHub Copilot: Longer PR descriptions (38.4%), high change concentration (24.9%). Focused code changes with detailed explanations.

OpenAI Codex: Extensive multiline commit messages (67.5%). More documentation than other agents.

Cursor: Frequently uses bullet points (17.2%) and hyperlinks (12.8%) in PR bodies. Structured, reference-rich descriptions.

Devin: Multiline commit messages combined with distributed changes across many files (8.2%), suggesting granular autonomous commits.

For live applications you can't see the source of, fingerprinting works at the infrastructure and HTML level:

Platform tells:

• A Lovable build loads gpteng.co scripts and ships characteristic component naming patterns
• Bolt apps have specific Vite build signatures and characteristic _app structures
• Framer-built sites serve assets from framerusercontent.com
• v0 generates distinctive Tailwind class combinations and shadcn/ui component structures
• Most vibe-coded apps deploy to Vercel; a domain like project-name-abc123.vercel.app is a near-certain tell, even after switching to a custom domain the Vercel response headers remain

Commit pattern tells (for open repos): Rapid succession commits like "Fix bug in form validation", "Add responsive styles to hero section", "Implement contact form" within hours of each other indicates AI pair programming. Human developers don't ship like that.

Code structure tells:

• Uniform function naming style across the entire codebase (humans are inconsistent)
• No dead code, no commented-out experiments, no TODO/FIXME archaeology
• Every component neatly separated, every file the same approximate length
• Auth and database access patterns copy-pasted identically across multiple files rather than abstracted

Tools like isitvibecoded.com automate this, covering 35+ AI tools with confidence scoring and the specific HTML/script indicators it used to reach its verdict.

The Dutch NIS2 Problem

This matters specifically for the Dutch and Belgian market because of where vibe-coded software is landing.

NIS2 came into effect and Dutch organizations in essential and important sectors now carry legal obligations around supply chain risk management, vulnerability disclosure, and incident reporting within 72 hours. The problem: a significant portion of internal tooling, customer portals, and B2B SaaS being sold into NIS2-obligated organizations right now was built with AI coding tools by founders or junior developers who have never heard of OWASP, let alone RLS misconfigurations.

The supply chain attack surface is real. If your NIS2-obligated client uses a vibe-coded supplier portal that has no RLS policies, their data is exposed. The breach obligation is theirs, not the startup founder who built the portal in a weekend.

53% of teams that shipped AI-generated code later discovered security issues that passed initial review. That discovery often happens during an incident, not a planned audit.

What to Actually Do About It

If you're building with vibe coding tools:

Run these five checks before shipping anything with real users or real data:

1. grep -r "NEXT_PUBLIC_" .env - anything sensitive should not be in a NEXT_PUBLIC variable
2. Check every Supabase table for RLS: SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public'; - if rowsecurity is false on any table holding user data\, you have a problem
3. Search the built JS bundle for obvious secrets: grep -E "(sk_live|pk_live|eyJ|AIza|AKIA)" dist/
4. Review every fetch() call that accepts user-supplied URLs
5. Check CORS headers on your API: curl -H "Origin: https://evil.com" -v https://yourapp.com/api/anything

Tools worth running before launch: Snyk (dependency CVEs), Semgrep (code patterns), and a live scanner like VibeCheck or Vibe App Scanner for config-level issues Snyk won't catch.

If you're testing vibe-coded apps for a client:

The standard OWASP checklist still applies, but prioritize these based on what AI tools consistently miss:

• Supabase/Firebase RLS policies (the number one finding in AI app audits)
• SSRF via any URL-accepting feature (5/5 AI tools introduced this in controlled testing)
• Client-side auth bypass (check if any auth enforcement is solely in frontend JavaScript)
• Exposed .env files and secrets in built JS (tool: trufflesecurity/trufflehog)
• MCP server configuration if the app integrates AI agents (CVE-2025-54136 MCPoison is worth checking)

The good news is that the vulnerability patterns are predictable enough that a targeted checklist covers most of the critical surface. The bad news is that most traditional SAST tooling was built for human-written code and doesn't know to check for RLS misconfigurations or NEXT_PUBLIC abuse.

The Bottom Line

Vibe coding is not going away. 46% of code on GitHub is already AI-generated. The Dutch IT sector is shipping vibe-coded tools into production right now, including into regulated environments. The security assumptions embedded in that code are wrong in consistent, exploitable ways.

The question isn't whether to use AI coding tools. The question is whether you have a security gate between "AI generated this" and "this is in production handling customer data."

Most organizations don't. That's the opportunity, and the problem.