What actually goes wrong in vibe-coded apps

Independent researchers have now audited thousands of AI-built applications. The same handful of failures keeps appearing — and none of them is exotic. They are ordinary web-security mistakes, at ordinary trust boundaries.

Vibe coding has made it possible to build and deploy full-stack applications without understanding much of the code underneath them. Security research published over the past two years is now large enough to show that the resulting failures are not random.

Across production scans, repository audits and controlled benchmarks, the same categories keep appearing: broken access control, exposed credentials, unsafe input handling, weak authentication and missing operational safeguards.

The studies do not all measure the same thing, so their percentages should not be combined into a single “X% of vibe-coded apps are vulnerable” statistic. But the repeated patterns are useful.

At a glance

The strongest academic evidence comes from a 2026 study by researchers from Microsoft, CISPA and an independent researcher. They assembled 10,517 real vibe-coded applications, randomly audited 200 deployed web applications and manually validated 1,471 vulnerabilities. Of the 200 applications, 180 — 90% — contained at least one vulnerability.¹

1. Authorization and data access

The most consistent problem in the research

An application can authenticate a user correctly and still fail to check what that user is allowed to access.

The 2026 academic study found Broken Access Control to be the largest vulnerability category:

530 of 1,471 vulnerabilities — 36.0%

At least one access-control vulnerability appeared in 75.5% of the 200 applications studied. More than 82% of those flaws were in backend code.¹

In practice, this category includes problems such as:

• User A can request User B's records by changing an ID.
• A normal account can call an administrator endpoint.
• An endpoint checks that someone is logged in, but not that they own the requested object.
• A database table can be queried without authentication.
• Row-Level Security exists but grants access too broadly.
• A new route is added without the authorization checks used elsewhere.
• Client-supplied userId, role or ownership information is trusted by the server.

Xint/Theori reached a similar result from a different methodology. Across 434 validated findings, authorization/IDOR accounted for 88 findings, or about 20%. In its larger real-world application, authorization problems became the largest category, accounting for 28% of findings, compared with 11% in the smaller generated applications.²³

This appears to be one of vibe coding's hardest problems because authorization is rarely contained in one function. The application must preserve the same rules across routes, database queries, roles and newly generated features.

2. Database permissions and Row-Level Security

This is closely related to authorization, but it appears often enough in vibe-coded applications to deserve separate attention.

Escape's study of more than 5,600 live vibe-coded applications concluded that its primary vulnerability cause was misconfigured permissions, particularly Supabase Row-Level Security policies.³⁵

Another 2026 study from Symbiotic Security scanned 1,072 Supabase-backed vibe-coded applications. Among its findings:

• 172 sites allowed database records to be deleted without authentication.
• 172 allowed unauthenticated modification.
• 39 exposed database tables for unauthenticated reading.
• 34 exposed sensitive columns such as emails, password hashes and authentication tokens.
• 14 allowed unauthenticated insertion of data.⁴

Wiz researchers separately documented vibe-coded applications with database tables left open through absent or overly permissive RLS policies.⁵

3. Secrets and credentials reaching places they should not

Researchers repeatedly found genuine secrets embedded in source code, frontend bundles, configuration and application data.

Escape reported:

• 400+ exposed secrets
• 175 instances of exposed PII
• leaked OpenAI keys
• GitHub tokens
• payment API credentials
• plaintext passwords

The exposed personal data included medical information, bank-account details, phone numbers and email addresses.³

Xint found secret exposure to be the largest source of critical vulnerabilities in its generated-app cohort: 11 of 23 critical findings involved hardcoded, default or otherwise unsafe secrets.²

The pattern is also visible outside dedicated vibe-coding platforms. GitGuardian's 2026 analysis found secrets in 3.2% of Claude Code-assisted public commits, compared with a 1.5% baseline across public GitHub commits.¹³

Common forms include:

• Private API keys compiled into the frontend
• Server credentials stored in source code
• JWT/session signing secrets hardcoded into an application
• OAuth tokens stored insecurely in browser storage
• Production credentials left in demo or test code
• Sensitive tokens written to logs

4. Security that only exists in the browser

The browser is controlled by the user. Any security decision enforced only there can usually be changed by that user.

Wiz found real vibe-coded applications in which authentication was implemented entirely in browser JavaScript. Examples included applications that stored a password in frontend code and then set an "authenticated" value in localStorage after login. Changing that local value was enough to bypass the apparent protection.⁵

Related failures include:

• isAdmin = true stored in Local Storage
• Routes hidden in the UI but callable directly
• Role checks performed only by React components
• Payment state trusted from the browser
• Sensitive buttons hidden without protecting the underlying API

The 2026 academic study found authentication failures in 42.5% of audited repositories, although authentication represented a smaller 9% of the total vulnerability count than authorization.¹

5. Unsafe input and injection

Injection remains important, but recent evidence is more nuanced than “AI code is full of SQL injection.”

The 2026 real-world study found 261 injection vulnerabilities, representing 17.7% of all vulnerabilities, with at least one appearing in 61.5% of audited applications. These included untrusted input reaching HTML, SQL and other sensitive operations without sufficient validation.¹

CodeRabbit's study of 470 open-source pull requests found AI-associated PRs contained about 1.7× more issues overall, with some security categories reaching 2.74× the human rate.¹²

But Xint's newer 2026 testing found relatively few traditional injection vulnerabilities in small newly generated apps and noted that current models increasingly reach for ORMs, prepared statements and safe defaults automatically.²

So injection remains significant, but it is not the only—or necessarily the dominant—vibe-coding risk.

6. Missing rate limits and resource controls

Some security failures do not expose data at all. They make an application easy to abuse or knock offline.

In Xint's 434 validated findings, the largest single category was resource exhaustion and denial of service: 93 findings, or 21%.

Examples included:

• No rate limit on expensive endpoints
• Unlimited pagination or queries
• Synchronous work that blocks the server
• No limits on resource-intensive operations
• Authentication endpoints callable indefinitely

These problems appeared in nearly every project Xint tested.²³

Unit 42 has likewise documented vibe-coded applications where AI-generated functions implemented the requested behavior but omitted authentication and rate-limiting controls.¹⁵

7. Applications that were never meaningfully private

Some of the worst failures contain no sophisticated exploit.

RedAccess researchers found more than 5,000 vibe-coded web applications with virtually no security or authentication across Lovable, Replit, Base44 and Netlify-hosted applications.

Close to 2,000 appeared to expose private information, including financial data, corporate strategy documents, customer conversations and medical information. WIRED independently inspected examples and reported that some application owners confirmed that their data had been exposed.⁷

Axios separately reported that RedAccess had identified roughly 380,000 publicly accessible assets, including thousands containing sensitive corporate data.⁸

This category is less “vulnerability in the code” and more missing security architecture altogether.

What is not dominating the evidence

One useful result from the research is what does not appear at the top.

Dependency vulnerabilities are not the defining problem

In the 2026 academic dataset, exploitable software-supply-chain failures represented only 0.6% of the 1,471 validated vulnerabilities and affected 4.5% of the audited repositories. The researchers explicitly counted a vulnerable dependency only when an exploitable path existed.¹

Dependencies still matter. But the strongest vibe-coding-specific evidence points elsewhere:

Those are application-logic and trust-boundary questions, not package-version questions.

Why these failures keep appearing

The 2026 academic study also examined how the vulnerabilities were introduced by reviewing vulnerable code and its development history.

The largest root cause was hidden security requirements, responsible for 43.9% of vulnerabilities. The user asked for functionality, but never explicitly stated the security properties that functionality also needed.

Other recurring causes included:

• Demo-oriented design — 16.1%: security weakened so a feature would work quickly.
• Function-fix side effects — 14.5%: fixing one problem unintentionally disabled a protection elsewhere.
• Incomplete change propagation — 12.6%: a security check was added to some routes but forgotten on others.
• Forgotten obligations — 6.9%: TODOs and temporary security shortcuts survived into the deployed application.¹

That helps explain why functionality is a poor proxy for security.

The SusVibes benchmark reached a similar conclusion from controlled repository-level tasks. Its best-performing configuration completed 61% of tasks functionally, but only 10.5% securely.⁹

Veracode's broader testing across more than 100 models found security flaws in 45% of generated coding tasks.¹¹

The code can work exactly as requested while still allowing something that was never supposed to happen.

What the evidence supports

There is no credible basis for saying that every vibe-coded application is insecure, or that any one percentage describes the entire ecosystem. The available studies have different datasets, scanners, vulnerability definitions and commercial incentives. Several are heavily weighted toward Lovable or Supabase applications, and some of the newer academic work remains pre-publication research.

But across independent methodologies, a surprisingly stable pattern has emerged.

The security problems most associated with vibe-coded applications are not exotic AI vulnerabilities. They are familiar web-security failures occurring at trust boundaries:

1. Broken authorization and object ownership
2. Incorrect database permissions and RLS
3. Exposed secrets and credentials
4. Authentication or authorization trusted to the client
5. Unsafe handling of user-controlled input
6. Missing rate limits and abuse controls
7. Sensitive applications deployed publicly by mistake

Vibe coding changes the speed and the person building the software. The underlying security rules have not changed.

Sources reviewed

This review prioritizes research involving complete or deployed vibe-coded applications, while using broader AI-code research as supporting evidence.

1. 1
   Deng, Fan & Meng — Understanding the (In)Security of Vibe-Coded Applications, 2026.
2. 2
   Xint / Theori — The Top Security Vulnerabilities Generated by AI Code, 2026.
3. 3
   Escape — The State of Security of Vibe Coded Apps, 2025–2026.
4. 4
   Symbiotic Security — scan of 1,072 Supabase-backed vibe-coded applications, 2026.
5. 5
   Wiz Research — common security risks in vibe-coded applications, 2025.
6. 6
   Wiz Research — Base44 authentication-bypass research, 2025.
7. 7
   RedAccess research, reported and independently examined by WIRED, 2026.
8. 8
   RedAccess research, independently examined by Axios, 2026.
9. 9
   Zhao et al. — Is Vibe Coding Safe? / SusVibes, 2025–2026.
10. 10
    Endor Labs — Agent Security League, 2026.
11. 11
    Veracode — 2025 GenAI Code Security Report.
12. 12
    CodeRabbit — State of AI vs Human Code Generation, 2025.
13. 13
    GitGuardian — State of Secrets Sprawl 2026.
14. 14
    Perry, Srivastava, Kumar & Boneh — Do Users Write More Insecure Code with AI Assistants?
15. 15
    Palo Alto Networks Unit 42 — Securing Vibe Coding Tools, 2026.
16. 16
    Tenable — Managing Vibe Coding Risks, 2026.
17. 17
    Supabase — API keys documentation.