The most common vulnerabilities in vibe-coded apps
What actually goes wrong when apps are built by prompting an AI: the five vulnerability classes that show up again and again, with the research behind each one.
- security
- vibe coding
Vibe coding, the practice of building software by prompting an AI and shipping what it produces without reading every line, has made it trivial to get an app running in an afternoon. The catch is that “running” and “safe to launch” are not the same thing, and the gap between them is where attackers live.
The data on that gap is not subtle. Veracode’s 2025 GenAI Code Security Report tested more than 100 large language models across Java, JavaScript, Python, and C#, and found that 45 percent of generated code samples failed security tests by introducing an OWASP Top 10 vulnerability. Security performance stayed flat regardless of model size or how new the model was, so a bigger, smarter model does not save you here. And this is not theoretical: when Escape.tech scanned 5,600 live, publicly reachable vibe-coded apps in their State of Security of Vibe Coded Apps study, they confirmed more than 2,000 vulnerabilities, over 400 exposed secrets, and 175 cases of leaked personal data, including medical records and bank account numbers. Every one was in production, discoverable within hours.
The same handful of problems come up over and over. Here are the five that matter most, and they line up almost exactly with the layers a real release scan has to cover.
1. Hardcoded secrets and exposed API keys
This is the fastest way to get compromised and the single most common finding in the wild. An AI assistant will happily write an integration that embeds an API key directly in the code, and that key ends up committed to the repository, baked into the frontend bundle, or printed into an error log. Wiz Research found third-party credentials, including plaintext OpenAI keys, sitting in client-side JavaScript where anyone viewing source could read them (Common Security Risks in Vibe-Coded Apps). A key in a frontend bundle is not hidden, it is published.
2. Broken access control
AI is good at writing the happy path and bad at the boundaries around it. That shows up as authentication logic that runs entirely in the browser, missing authorization checks on backend endpoints, and objects that any logged-in user can read by changing an ID in the URL. Multi-step flows are especially fragile: email verification and multi-factor steps get bypassed because the model treated each step as an isolated feature rather than a gate.
The clearest example is CVE-2025-48757, a CVSS 9.3 flaw where Lovable-generated projects shipped Supabase databases with missing or insufficient Row-Level Security. The public client key let unauthenticated attackers read and write arbitrary tables, dumping full user lists and payment records without ever logging in. More than 170 production apps were confirmed exposed.
3. Injection, especially cross-site scripting
Injection is old, well understood, and still everywhere in generated code, because the model reaches for string concatenation and skips input validation unless you explicitly ask for it. Missing input sanitization is consistently the most common flaw across languages and models. Cross-site scripting is the worst offender: in Veracode’s testing, the models failed to prevent XSS in 86 percent of the relevant samples. SQL injection follows the same pattern wherever user input reaches a query unescaped.
4. Vulnerable and hallucinated dependencies
The code an AI does not write is still code you ship. Generated apps tend to pull in large dependency trees, and outdated packages carry known vulnerabilities straight into your build. There is also a newer, stranger risk: slopsquatting. Research across 16 models found that roughly 19.7 percent of AI package recommendations pointed at packages that do not exist, and 43 percent of those hallucinated names showed up again on every rerun of the same prompt. That predictability is the exploit: attackers register the fake names, and the next developer who trusts the suggestion installs malware.
5. Insecure configuration and exposed surfaces
The last layer is everything the code assumes about its environment. Admin dashboards, internal tools, and staging environments get deployed to the public internet with no authentication at all, then found through simple fingerprinting. Permissive CORS, debug mode left on, verbose error pages that leak stack traces, and databases with access controls disabled all fall here. Wiz’s finding that one in five organizations building on vibe-coding platforms carries a systemic risk of this kind is mostly a configuration story.
What to do before you ship
You do not have to slow down to close these. You do have to look, across all five layers, before the app is public:
- Scan for secrets in your code and history, and rotate anything that leaked.
- Check that every endpoint enforces authorization on the server, not the client, and that database access controls are actually on.
- Run static analysis for injection and XSS on the generated code.
- Resolve your dependencies against known vulnerability data, and verify that every package you install is real.
- Review the deployed configuration for exposed surfaces and unsafe defaults.
That list is exactly why VibeZero scans across code, dependencies, secrets, configuration, and the running app, then turns the results into one go or no-go release decision instead of a pile of alerts. If you want the longer version of how those layers fit together, we wrote it up in the five layers of a release gate.
Vibe coding is not going away, and it should not. The fix is not to write less code with AI. It is to stop treating “it works” as the finish line.