Introduction
In late January 2026, Matt Schlicht launched Moltbook, an internet forum for AI agents. Within weeks, the platform was processing millions of records. Then, in early February, security researchers at Wiz discovered something that should not have made it past even a basic review: a Supabase API key sitting in the site's front-end JavaScript, visible to anyone who opened the browser's network inspector.
That key had full read and write access to the entire production database. By the time Moltbook patched the issue, 1.5 million authentication tokens and 35,000 email addresses were exposed, along with private conversations that contained users' OpenAI API keys shared under the assumption of privacy.
Schlicht later said he "didn't write a single line of code." He built the whole platform with AI.
That detail is not a gotcha. AI-assisted development is not inherently reckless, and plenty of serious engineers use it every day. But the Moltbook breach captures a specific failure pattern that shows up consistently across vibe-coded projects: the AI produces functional code, you ship it, and nobody checks whether it is also secure. The gap between "it works" and "it is safe" does not close automatically just because the code was generated quickly.
What the research actually shows
Researchers have now run enough audits to move past anecdotes. The numbers paint a consistent picture.
A scan of 5,600 apps built with vibe coding tools found 2,000 critical vulnerabilities, 400 exposed secrets, and 175 instances of PII sitting accessible without authentication. A separate pen test of 15 vibe-coded applications found 69 vulnerabilities across those 15 apps, six of them critical. Every single app in that study had multiple security problems before anyone tried to exploit it.
The XSS numbers are particularly striking. A study testing five major LLMs found that 86% of AI-generated code failed to defend against cross-site scripting attacks. A broader analysis put AI code at 2.74 times more likely to contain XSS vulnerabilities than code written by humans. XSS is not obscure. It has been on the OWASP Top 10 since 2003. Security courses cover it in the first week. The models generate it anyway, because they are trained to produce code that runs, not code that resists attack.
Georgia Tech's Vibe Security Radar tracked CVEs attributed to AI-generated code throughout early 2026: 6 in January, 15 in February, 35 in March. The trajectory over those three months was unambiguous. More AI code in production means more AI-generated CVEs showing up in disclosure databases.
There is also the package hallucination problem, sometimes called slopsquatting. Around 20% of AI-generated code references packages that do not exist. The AI confidently names a dependency, the developer installs it, and the package registry fills in the gap. Attackers watch for these hallucinated names, register packages with those exact names, and include whatever payload they want. The developer trusts the AI's suggestion, runs the install, and gets malicious code. This is not a theoretical attack. It is happening now, and it works precisely because developers treat AI output as if it came from a colleague who checked their references.
The cumulative effect on security debt is measurable. Around 82% of engineering organizations report growing security debt in their codebases, up from 74% the year before. That figure tracks closely with how widely AI-assisted coding has been adopted. The teams moving fastest with AI are also the ones accumulating technical debt they cannot see yet because the code appears to work.
Add it all together: 45% of AI-generated code introduces vulnerabilities from the OWASP Top 10. These are the most documented and best-studied vulnerability classes in existence. AI models produce them at scale because producing them does not stop the code from running.
2026's biggest vibe coding security incidents
Lovable is a vibe coding platform valued at $6.6 billion with 8 million users. Between February and April 2026, it dealt with three separate security incidents. Together, they exposed source code, database credentials, AI chat histories, and the personal data of thousands of users.
The February incident exposed 18,697 user records, including data from university accounts at UC Berkeley and UC Davis. The April incident was larger in scope. A security researcher disclosed a broken object-level authorization vulnerability that let any free account read the source code, database credentials, and chat history from other users' projects. The flaw had been reported on March 3. It stayed open for 48 days before public disclosure. It affected every project created before November 2025.
Lovable's initial response to the April disclosure was to say there was no breach and call the exposed data "intentional behavior." Then the company blamed their bug bounty partner for not escalating the report. Neither explanation changed what happened: a basic authorization flaw sat open for 48 days on a platform millions of people trusted with their code and credentials.
The type of vulnerability matters here. Broken object-level authorization (BOLA) means the API checks whether you are authenticated but not whether you own the resource you are accessing. This is number one on the OWASP API Security Top 10. It gets caught in a basic security review. It does not get caught when there is no review.
Moltbook's failure was more direct. A full-access database key in client-side JavaScript is the kind of thing you catch when a second set of eyes looks at the code. In a conventional development process, a secrets scanner, a code review, or even a pull request comment would likely surface it before the code went live. With vibe coding, the code went from AI output to production without that step.
Why this keeps happening
There is a structural reason AI-generated code has more security problems than human-written code, and it comes down to what the models are optimizing for.
When you prompt an AI to build a feature, it produces code that satisfies the stated requirement: the feature works. Authentication? The user can log in. That part works too. But security is largely about things that should not work. Unauthenticated access to another user's data should not work. Malformed input should not reach the database. API credentials should not appear in JavaScript that ships to the browser.
These constraints are mostly implicit. Senior engineers have internalized them over years of reading security advisories, dealing with production incidents, and sitting through code reviews where someone more experienced pointed out the flaw. AI models have not had that experience. They have been trained on enormous amounts of code, including a lot of insecure code, and they produce outputs that look correct and often run correctly while skipping the properties that make code actually safe. The model does not know it left out the authorization check. It just knows the function returned data.
The pace compounds this. Vibe coding's appeal is that you can build in hours what used to take days. That speed is real and useful. But security review takes time, and when the tool that generates your code also runs it in 30 seconds, the review step gets skipped. Developers who have never thought carefully about BOLA or input sanitization are now shipping production APIs because AI made it achievable. The code works. The tests pass, if there are tests. Nobody checks for the security properties the developer did not know to ask for.
A study of AI-assisted developers found 3 to 4 times more commits per day than in traditional workflows, but 10 times more security findings per commit. Production incidents per PR rose 23.5% from December 2025 into early 2026. The speed is not the problem in isolation. The speed combined with no security review is.
What to actually do about it
The 92% figure, meaning 92% of AI codebases contain at least one critical vulnerability, will probably improve as tooling matures and developers get more security-aware. But right now that is where things stand, and shipping AI-generated code without any security check is essentially gambling with your users' data.
A few things are worth getting right as a baseline. Secrets belong in environment variables, not in source code or client-side JavaScript. Row-level security should be on in your database, not just authentication at the API layer. Every endpoint that returns user-specific data should verify that the requesting user actually owns that data, not just that they have a valid token. SQL queries should be parameterized. Dependencies should be checked against a real package registry before installation, not trusted from an AI suggestion alone.
None of this is advanced. It is the baseline that experienced engineers reach for automatically. The vibe coding security problem in 2026 is largely that the tools generating code skip it, and the people using those tools often do not know enough to add it back. That is not a criticism of those developers. It is a description of a skill gap that the tooling has not bridged. AI tools have gotten remarkably good at explaining how to build things. They are still poor at proactively flagging the security properties they forgot to implement.
There is a version of AI-assisted development that works well. Developers who use AI for speed and then run automated security checks before merging get the best of both approaches: fast iteration with a safety net. The problem is not AI coding as a category. The problem is the assumption that code which works is also code that is safe.
Security review catches these problems consistently. A scanner checking for hardcoded credentials, missing authorization controls, and common injection patterns before code reaches production would have caught Moltbook's database key. It would have flagged Lovable's BOLA endpoints. The code still gets written fast. It just gets checked before it ships.
The practical ask is not to slow down. It is to add one step: automated security scanning before merge. Most of the vulnerabilities showing up in 2026's vibe coding breaches — hardcoded credentials, missing authorization checks, XSS sinks, hallucinated packages — are exactly the kind of thing static analysis and secrets scanning catch in seconds. These tools do not require slowing down the AI-assisted workflow. They sit at the end of it and catch what the AI left out.
The breaches happening right now are not sophisticated attacks. They are basic failures that a review step would prevent. This is not an unsolvable hard problem. It is a skipped step in a workflow that moves very fast.
Stop manual code reviews. Ship with confidence.
BugLens is an AI senior reviewer for GitHub PRs that catches bugs, vulnerabilities, and style violations before your team does. Join the waitlist for our private beta today.