Vibe Coding's Security Reckoning — 35 CVEs in One Month and a Platform That Called Its Breach 'Intentional'

On April 20th, security researcher Matt Palmer publicly disclosed that Lovable had been leaking every user's source code, database credentials, and AI chat histories for 48 days through a basic authorization flaw. Lovable is a vibe coding platform valued at $6.6 billion with 8 million users. Palmer had reported the vulnerability through Lovable's bug bounty program on March 3rd. It was marked as a "duplicate" and left unpatched. When it finally went public, Lovable's initial response was to post on X that the exposed data was "intentional behaviour."

Eight million users. 48 days. "Intentional behaviour." That's the state of vibe coding security in April 2026.

The worst month in vibe coding's short history

Lovable wasn't even the only disaster. In January, Moltbook, a social network for AI agents built entirely with vibe coding, was breached within three days of launch. Wiz Security researchers found a Supabase API key hardcoded in client-side JavaScript with Row Level Security completely disabled. Anyone who looked could access 1.5 million API tokens and 35,000 email addresses. The founder had publicly stated he "didn't write a single line of code for Moltbook."

Meanwhile, Georgia Tech's Systems Software and Security Lab has been tracking CVEs traced to AI-generated code through their Vibe Security Radar. The numbers are accelerating: 6 CVEs in January, 15 in February, 35 in March. That last number is more in one month than all of 2025 combined. The researchers estimate the real number is 5 to 10 times higher than what their dashboard captures.

What's a BOLA vulnerability?

Broken Object Level Authorization (BOLA) is the #1 vulnerability on the OWASP API Security Top 10. It happens when an API lets you access other users' data just by changing an ID in the request, like switching /api/projects/123 to /api/projects/456 and getting someone else's project. It's one of the simplest vulnerabilities to exploit and one of the easiest to prevent with proper authorization checks. That a $6.6 billion platform shipped with this flaw tells you something about the gap between "it works" and "it's secure."

The security data is brutal

These aren't isolated incidents. Multiple independent studies converge on the same uncomfortable conclusion: AI-generated code is systematically less secure than human-written code.

Veracode's GenAI Code Security Report tested 80 coding tasks across 100+ LLMs. 45% of AI-generated code introduced OWASP Top 10 vulnerabilities. 86% of relevant samples failed to defend against cross-site scripting. Despite 95% syntax accuracy, the security pass rate hasn't meaningfully budged. Models are getting better at writing code that compiles and no better at writing code that's safe.

A Stanford study by Perry et al. found that developers with AI assistance wrote secure code only 36% of the time, compared to 50% for a control group without AI. Worse: the AI-assisted developers were more confident their code was secure. The ones who produced the least vulnerable code were the ones who trusted the AI the least.

CodeRabbit analyzed 470 real-world GitHub pull requests and found AI-generated code introduces 2.74x more security vulnerabilities than human-written code. Not twice as many. Nearly three times.

The "Challenger disaster" warning

Developer Simon Willison predicted in January that we're "due a Challenger disaster with respect to coding agent security," referencing the 1986 shuttle explosion caused by the "normalization of deviance," where organizations keep getting away with unsafe practices until catastrophic failure occurs. His concern: developers are running AI coding agents "practically as root," and every day nothing goes wrong reinforces the habit. The Lovable and Moltbook breaches might not be the Challenger moment, but they're the O-ring warnings before launch day.

Even the guy who coined "vibe coding" walked it back

Andrej Karpathy coined "vibe coding" in February 2025, describing it as coding where you "fully give in to the vibes" and "forget that the code even exists." By February 2026, he revised his framing. His new preferred term: agentic engineering. The emphasis on "engineering" was deliberate, meant "to emphasize that there is an art and science and expertise to it."

That's a significant shift. The original framing treated not understanding your code as a feature. The new framing treats it as a skill gap to manage. Karpathy described how by December 2025, AI handled about 80% of his code, up from roughly 20% a few months earlier. But he's not shipping it blind. He's reviewing it, orchestrating it, acting as oversight. The difference between Karpathy's workflow and the Lovable disaster isn't the AI. It's whether a human with engineering judgment is in the loop.

The problem isn't AI writing code — it's shipping code you don't understand

Here's where I'll stake my position, and it might be unpopular with some of my peers: vibe coding tools aren't the problem. Deploying their output without understanding it is.

I use AI coding tools every day. I wrote about this earlier this year: the shift from code writer to code reviewer is real and happening. AI generates the first draft; I provide the judgment. That workflow genuinely makes me more productive.

But "I provide the judgment" is doing a lot of heavy lifting in that sentence. I tried Lovable once earlier this year to prototype a study group finder app for a course. It was genuinely impressive: I described what I wanted and had something that looked production-ready in twenty minutes. Then I looked at the generated Supabase config and realized there were no RLS policies. Any user could read any other user's data. The prototype looked great. The security was nonexistent. I scrapped it and built the auth layer myself.

Not everyone does that. The Moltbook founder and the thousands of users building apps on Lovable weren't bad people. Many were non-developers, which was supposed to be the whole point. But "anyone can build an app" has silently become "anyone can deploy an insecure app to production and expose real user data." I wrote recently about how AI is reshaping security. The irony is that while models like Mythos are finding vulnerabilities in existing software, vibe coding tools are simultaneously creating new ones at an unprecedented rate.

The Stanford study's most disturbing finding wasn't the vulnerability rate. It was the confidence gap. Developers using AI felt more secure while being less secure. That's not a tooling problem. That's a human judgment problem. And it's exactly the kind of problem that CS fundamentals, the kind people are abandoning right now, are designed to address.

A minimum security checklist before you deploy anything AI-generated

Before pushing any vibe-coded or AI-assisted project to production: (1) Read every line of your authentication and authorization logic. Don't just trust that it works because the demo looked right. (2) Check for hardcoded secrets and API keys. Run TruffleHog or git-secrets on your repo. (3) Verify your database has Row Level Security policies if you're using Supabase or similar. (4) Run a free SAST scan with something like Semgrep. (5) Check the OWASP Top 10 against your app. You don't need to be a security expert. You need to spend thirty minutes looking for the obvious stuff that AI consistently gets wrong.

What this means for your Monday morning

If you're a CS student using AI tools to build side projects, portfolio pieces, or class assignments, here's the honest version: your vibe-coded project could be a liability on your resume instead of an asset. A hiring manager who runs a basic security scan on your public repo and finds hardcoded API keys and missing auth checks isn't going to think "wow, they ship fast." They're going to think "this person doesn't understand what they're building."

The fix isn't to stop using AI tools. It's to close the gap between "it works" and "it's secure."

Learn to read auth code. You don't need to become a security specialist. You need to be able to look at a login flow, a database policy, or an API endpoint and answer: "who can access this, and what stops someone else from accessing it?" If you can't answer that for code AI wrote, you can't deploy it.

Run a scanner before you push. Semgrep, TruffleHog, even just grepping for API_KEY in your client-side code. Five minutes of automated scanning catches the exact class of vulnerabilities that took down Moltbook and Lovable.

Treat AI output the way you'd treat a Stack Overflow answer from 2014. It might be right. It might be outdated. It might work in a demo and break in production. Your job isn't to copy it — it's to evaluate it. That's the skill that separates a developer who uses AI from one who gets used by it.

Karpathy was right to update his vocabulary. The era of "vibe coding," of forgetting the code exists, needs to end. What replaces it should keep the speed but add the judgment. The AI writes the code. You make sure it's safe. That's the deal. And if you're not holding up your end, the next Lovable-scale breach might have your project's name on it.