Vibe Coding Is Everywhere. So Are the Security Holes It Leaves Behind.

In 2025, Andrej Karpathy, one of the founding researchers at OpenAI, described a new way of building software: fully give in to the vibes, let the AI write the code, and stop worrying about what's happening underneath. The idea was liberating. Within months, a generation of founders, marketers, and non-technical builders had shipped products they could never have built before. Lovable, Cursor, Bolt, Replit Agent, the tools made it real. By 2026, Collins English Dictionary named vibe coding its Word of the Year, over 92% of developers reported using AI coding assistance, and the web was filling up with AI-generated websites and applications moving faster than anyone expected. The only thing moving faster than the builds was the accumulation of security debt nobody was reviewing. This article is about that debt, what it looks like, why it happens, and what you can check right now without touching a single line of code.

The numbers behind the vibe coding security crisis

This is not theoretical. The data on vibe coding security failures has been accumulating since 2025 and the picture is consistent and worsening.

Veracode tested over 100 large language models on security-sensitive coding tasks across Java, Python, C#, and JavaScript. The verdict: 45% of AI-generated code samples introduce vulnerabilities from the OWASP Top 10, the most well-documented and most exploited vulnerability categories in existence. Cross-site scripting failures appeared in 86% of generated samples. Log injection vulnerabilities appeared in 88%. And critically: a follow-up study published in March 2026 found the security pass rate unchanged. Despite significant improvements in code functionality, the security failure rate had not moved.

Separately, security firm Escape.tech scanned over 1,400 vibe-coded production applications. 65% had security issues. 58% contained at least one critical vulnerability. The scan turned up over 400 exposed secrets, API keys, database credentials, service tokens, sitting in live applications, accessible to anyone who knew where to look.

Georgia Tech's Systems Software and Security Lab launched a dedicated tracking project called the Vibe Security Radar in May 2025, monitoring CVE entries directly attributable to AI-generated code. The trajectory it documented is not a plateau, it is an acceleration. Six attributable CVEs in January 2026. Fifteen in February. Thirty-five in March. Researchers estimate the true count is five to ten times higher, because most AI coding tools do not leave identifiable commit metadata.

A December 2025 analysis of 470 open-source GitHub pull requests found that AI co-authored code contained 1.7 times more major issues than human-written code. Security vulnerabilities specifically appeared at 2.74 times the rate of non-AI code. Misconfigurations were 75% more common.

The most concrete case study is Moltbook, an AI social network launched in January 2026 where the founder publicly stated he had not written a single line of code. Within three days of launch, security researchers at Wiz discovered the application had exposed its entire production database to the public internet: 1.5 million API authentication tokens, 35,000 email addresses, and private user messages. The root cause was a misconfigured Supabase deployment. The same kind of deployment that powers thousands of other vibe-coded applications built with the same tools.

Why AI code generators produce insecure code

Understanding why this happens matters because it explains what types of vulnerabilities are most common, and therefore what to look for.

AI tools optimise for functionality, not security

When you prompt an AI coding tool to build a feature, it is optimising for one outcome: making the feature work. Security is a second-order concern that most prompts do not explicitly specify and most AI tools do not proactively enforce. The code runs. The feature works. The authentication bypass or exposed secret or missing security header sits there invisibly, waiting.

Andrej Karpathy himself, the person who coined the term, warned about this publicly. As reliance on AI increases, he noted, the developer's job shifts from writing code to reviewing it. The problem is that most vibe coders are not reviewing what the AI produces. The whole appeal of the workflow is not having to do that.

The hallucinated package problem

AI coding tools regularly reference packages that do not exist, a known failure pattern sometimes called hallucinated dependencies. In a human-written codebase, a non-existent package causes an immediate error. In an AI-generated codebase, the developer often pastes the error back and asks the AI to fix it, which may prompt a workaround rather than flagging the underlying problem.

More dangerously, attackers have learned to exploit this. A technique called slopsquatting involves registering the names of packages that AI tools commonly hallucinate as real malicious packages. When a developer installs the hallucinated dependency, they install the attacker's code instead. Approximately 20% of AI-generated code samples reference packages that do not exist, creating a persistent supply chain attack surface.

Security logic ends up in the wrong place

One of the most structurally dangerous patterns in vibe-coded applications is security logic implemented client-side rather than server-side. A startup called Enrichlead, built entirely with AI tools, shipped a lead generation platform in 2025 where all access control was implemented in the browser. Users discovered within 72 hours that changing a single value in the browser console gave them free access to all paid features. The AI had produced code that looked correct and functioned correctly in testing, the security flaw was an architectural decision the founder had no visibility into because they had never read the code.

Credentials end up hardcoded

GitGuardian's State of Secrets Sprawl 2026 report documented 28.65 million new hardcoded secrets in public GitHub commits during 2025, a 34% year-over-year increase and the largest single-year jump ever recorded. AI-assisted commits showed a 3.2% secret-leak rate, compared to a 1.5% baseline for non-AI code. The doubling of credential exposure rate is directly attributable to AI code generators regularly hardcoding API keys, database connection strings, and service credentials into application files rather than referencing environment variables.

What a surface-level scan can actually tell you

Here is the important distinction that gets lost in most security conversations: you do not need access to the source code to identify many of the most common and most serious vibe coding security failures. A significant number of vulnerabilities are visible from the outside, from the URL alone.

PeekedAI's security scan works from a single URL, the same way the rest of the platform works. No code access required. No developer involvement needed to run it. Paste the URL, run the scan, get a structured report on what the surface of your site is revealing.

What a surface-level scan from a URL can detect:

HTTPS enforcement. Is the site served over HTTPS, and is HTTP traffic properly redirected? Mixed content, HTTPS pages loading HTTP resources, is a common vibe coding failure that exposes data in transit.

Security headers. Security headers like Content-Security-Policy, X-Frame-Options, Strict-Transport-Security (HSTS), X-Content-Type-Options, and Referrer-Policy are instructions to the browser that protect against common attacks. They are trivially easy to add and almost universally missing from vibe-coded sites because AI tools do not include them by default unless explicitly prompted.

Cookie security flags. Cookies that handle authentication or session state should be marked HttpOnly (not readable by JavaScript) and Secure (only sent over HTTPS). A surface scan can verify whether these flags are present. Missing cookie security flags are one of the most common and most exploitable vibe coding failures.

Exposed admin routes. Common admin paths, /admin, /dashboard, /api/admin, that are publicly accessible without authentication are detectable from outside the application. Vibe-coded apps frequently ship with admin routes that the developer tested locally but never locked down for production.

Client-side API key exposure. API keys embedded in JavaScript that is loaded in the browser are readable by anyone who opens the browser developer tools. A surface scan can flag the presence of patterns consistent with exposed credentials in client-side code.

SSL certificate validity. An expired or misconfigured SSL certificate is an immediate trust and security failure that is visible from the URL alone.

What a surface-level scan cannot detect: vulnerabilities buried in server-side business logic, database permission configurations, authentication implementation quality, or code-level injection flaws. For those, a full code audit or penetration test is required. The surface scan is the first check, the one that catches the most common failures before they are exploited, not the last one.

The most common vibe coding security failures, ranked by exploitability

Based on the patterns documented across the research above, these are the issues most commonly found in vibe-coded websites and applications, ordered by how easily they can be exploited by an attacker with no special access:

1. Missing security headers, Exploitability: High. Effort to fix: Very low. The most common finding in any surface scan of AI-built sites. Security headers are a single configuration change. They are absent because AI tools do not add them unprompted and most vibe coders do not know to ask.
2. Exposed API keys in client-side code, Exploitability: Critical. Effort to fix: Low once identified. An API key in a JavaScript file loaded by the browser is readable by anyone. Attackers use automated tools to scan for these continuously across the public web. The fix is moving the key to an environment variable and proxying requests through a server-side function, something that can be done by reprompting the AI tool once the issue is identified.
3. Missing HTTPS enforcement, Exploitability: Medium. Effort to fix: Low. HTTP traffic to a site that handles any user data or authentication should redirect to HTTPS. Many vibe-coded deployments miss this configuration step.
4. Insecure cookie flags, Exploitability: Medium to High. Effort to fix: Low. HttpOnly and Secure flags on session cookies are a one-line fix. Their absence means session tokens can be stolen through cross-site scripting or network interception.
5. Exposed admin routes without authentication, Exploitability: Critical if present. Effort to fix: Medium. Admin interfaces that are publicly accessible without authentication are an open door. The fix requires adding authentication middleware, a prompt-able change but one that needs to be implemented correctly.
6. Overly permissive database rules, Exploitability: Critical. Effort to fix: Medium. Supabase Row Level Security disabled or misconfigured is the failure class that caused the Moltbook breach. Not detectable from the surface alone, but identifiable through database configuration review.
7. Missing input validation, Exploitability: High. Effort to fix: Medium to High. AI tools regularly generate forms and API endpoints without server-side input validation. This is the root cause of SQL injection and cross-site scripting vulnerabilities. Not surface-detectable in most cases, but present in the majority of vibe-coded applications.

The gap between "it works" and "it works safely"

There is a mindset shift that explains most of the vibe coding security crisis: the assumption that if the application functions correctly, it is probably fine.

This assumption is wrong, and it is wrong in a specific way. Security failures are invisible until they are exploited. A site with an exposed API key looks identical to a site without one. A login page with broken authentication logic looks identical to a properly implemented one. A database with disabled Row Level Security behaves identically to a properly secured one, until someone queries it directly.

The "it works" signal that vibe coding optimises for tells you nothing about security. The application working is proof that the AI produced functioning code. It is not proof, or even evidence, that the code is secure.

This gap is not unique to vibe coding. Security has always been the last thing developers check and the first thing founders deprioritise. What vibe coding adds is scale and invisibility: more code shipped faster, with less review, by more people who cannot evaluate what they are reviewing. The volume of vulnerable code entering production is increasing, and the proportion of founders who can identify it is not.

What to do if you shipped a vibe-coded site

• Rotate every key that has ever appeared in client-side code or a repository.
• Move every authorisation check to the server. If the browser enforces it, it is not enforced.
• Review database access rules row by row, assuming an anonymous caller.
• Add the standard security headers and confirm they are present in a live response.
• Scan the deployed URL rather than the source, so you see what an attacker sees.
• Re-scan after every AI-assisted change, not once at launch.

If you built your website with Lovable, Cursor, Bolt, Replit, v0, or any other AI coding tool, the practical starting point is a surface-level scan. Not because it catches everything, it does not, but because it catches the most exploitable issues fastest, and it requires nothing from you except a URL.

Step 1, Run a surface scan. Paste your URL into PeekedAI's security scan. The report surfaces the issues visible from the outside: security headers, HTTPS configuration, cookie flags, exposed routes, and client-side credential exposure. This takes a few minutes and requires no technical knowledge to interpret.

Step 2, Fix what the scan surfaces. Most surface-level findings can be fixed by reprompting your AI tool with specific instructions. "Add a Content-Security-Policy header to all responses." "Ensure all cookies are set with HttpOnly and Secure flags." "Redirect all HTTP traffic to HTTPS." These are prompt-able instructions that the AI tool that built your site can implement.

Step 3, Audit your database permissions. If you are using Supabase, check that Row Level Security is enabled on every table that stores user data. This is the configuration failure that caused the Moltbook breach and is one of the most common serious vulnerabilities in vibe-coded applications. Supabase's dashboard shows RLS status per table, no code access required to check.

Step 4, Check for exposed credentials. Search your codebase for patterns like API_KEY =, secret =, password =, and any service-specific credential patterns for the APIs you are using. If any of these appear in files that are committed to a public repository or loaded in the browser, rotate the credentials immediately and move them to environment variables.

Step 5, Consider a proper security review before scaling. A surface scan is a starting point. If your application handles payments, stores personal data, or is growing beyond a small user base, a proper security audit by a developer with security experience is worth the investment. The scan tells you where to start. The audit tells you whether you have addressed the full scope.

The vibe coding workflow is not the problem. Skipping the check is.

Vibe coding is not going away, and the argument that it should is not worth having. The productivity gains are real. The democratisation of software creation is real. Founders have shipped products that would have taken months in weeks, tested ideas that would never have been tested, and built businesses that would not otherwise exist.

The issue is not the workflow. The issue is the assumption that shipping fast means you can skip the security review. You cannot. The tools that make it fast to build have not made it safe to skip verification. They have just made it easier to not realise you should be doing it.

The security check for a vibe-coded site does not require a developer. It does not require code access. It does not require weeks of review or thousands of pounds in penetration testing. It requires a URL and a few minutes to understand what your site is exposing to the outside world.

The founders who get this right are the ones who treat the surface scan as part of the build workflow, not an optional step after launch. They run it before they share the link. They run it again after they add a new feature. They treat "it works" and "it is secure" as two separate questions that both need an answer.

Frequently asked questions