Lovable Called Their Data Leak 'Intentional Behavior.' It Got Worse From There.
Six days ago, in our vibe coding security piece, I wrote this about Lovable: “First tool in the space to acknowledge the problem by actually doing something about it.” I praised them for adding built-in penetration testing. I called their honesty refreshing.
That aged like milk in a sauna.
What Actually Happened
On April 20, a security researcher going by @weezerOSINT posted a thread on X that made the entire vibe coding industry wince. The claim was simple and devastating: any free Lovable account could access other users’ source code, database credentials, AI chat histories, and customer data. The cost of entry? Five API calls. Not five hundred. Not five thousand. Five.
The vulnerability was a BOLA — Broken Object Level Authorization. If you’re not a security person, here’s the plain English version: Lovable’s API checked whether you were logged in, but it didn’t check whether the data you were requesting was actually yours. It’s the digital equivalent of a hotel that confirms you have a room key, but doesn’t care which room you open with it.
BOLA sits at the number one spot on OWASP’s API Security Top 10. This isn’t an exotic zero-day. It’s not some nation-state-level exploit that requires a PhD and a clean room. It’s the kind of bug that security courses teach in week two.
And it sat there, exposed, for 48 days.
The PR Response: A Four-Act Tragedy
Here’s where the story goes from “bad security incident” to “somebody please take the microphone away.”
Act 1: Denial. Lovable posted that it was “made aware of concerns regarding the visibility of chat messages.” Their position: “To be clear: We did not suffer a data breach.” Technically, maybe. But when anyone with a free account can read your users’ database credentials, the distinction between “data breach” and “data lying around on the sidewalk” starts to feel academic.
Act 2: It’s a feature. The company described the exposure as “intentional behavior,” explaining that public projects had always shown build history and that “the core behavior has been consistent and by design.” I’ve heard some creative spin in my time, but describing unauthorized access to database credentials as “by design” is genuinely Hall of Fame material.
Act 3: Blame the bounty platform. Lovable pointed at HackerOne, stating the original report was “closed without escalation because our HackerOne partners thought that seeing public projects’ chats was the intended behaviour.” HackerOne, meanwhile, declined to comment in detail — only saying they’d “follow up after review completion.” A polite corporate way of saying “we’re not touching this with a ten-foot pole right now.”
Act 4: The half-apology. Lovable finally acknowledged that “pointing to documentation issues alone was not enough.” Progress. But by this point, the internet had already made up its mind.
There’s a scene in Chernobyl where the plant director insists the readings must be wrong because the reactor can’t explode. “Not great, not terrible,” he says, while the building burns. That’s the energy of calling a BOLA vulnerability “intentional behavior.”
This Wasn’t Even the First Time
Here’s the part that makes it worse. The April incident wasn’t Lovable’s first rodeo.
Back in February, tech entrepreneur Taimur Khan found 16 vulnerabilities — 6 of them critical — in a single featured Lovable app. Not some obscure side project. A featured one. The result: 18,697 user records exposed, including 4,538 student accounts from UC Berkeley and UC Davis. Some of those were likely minors.
Khan filed a support ticket. Lovable closed it without responding.
A separate May 2025 study found that approximately 70% of sampled Lovable apps had row-level security entirely disabled. Not misconfigured. Not partially working. Disabled. The front door wasn’t just unlocked — it had been removed from the hinges and repurposed as a coffee table.
And this is a platform with eight million users, a $6.6 billion valuation, and corporate accounts from Uber, Zendesk, Deutsche Telekom, Nvidia, Microsoft, and Spotify. Those aren’t hobby projects running on someone’s Raspberry Pi.
The Numbers That Should Scare Everyone
Lovable’s meltdown is dramatic, but it’s not an outlier. It’s the logical conclusion of a pattern the entire industry is sleepwalking into.
A Q1 2026 assessment of 200+ vibe-coded applications found that 91.5% contained at least one vulnerability traceable to AI hallucination. Not “might have an issue somewhere.” Ninety-one point five percent. Over 60% exposed API keys or database credentials in public repositories. And 35 CVEs were disclosed in March alone from AI-generated code — up from just 6 in January.
AI-written code produces security flaws at 2.74 times the rate of human-written code. And yet — here’s the truly terrifying part — a recent developer survey found that nearly 80% of developers believe AI generates more secure code than humans.
Read that again. The people writing the code think it’s safer. The data says it’s nearly three times more dangerous. That’s not a knowledge gap. That’s a chasm with fog at the bottom.
The Real Lesson Isn’t About Lovable
It’s easy to pile on Lovable right now, and honestly, their PR response invited it. But the real story here isn’t about one company having a bad week.
The real story is that vibe coding has scaled the creation of software past the point where anyone can verify it. Lovable helped their users build apps in minutes that would have taken weeks. Incredible. But nobody read the code those apps were built on. Nobody checked whether the authentication actually worked. Nobody noticed that database credentials were sitting in the source code like a “rob me” sign in a store window.
Lovable’s marketing page probably says something about empowering developers. But what it actually did was empower people to deploy production applications without understanding what was inside them. And when the inevitably exploitable code shipped, the only safety net was a bug bounty program that closed the report as a duplicate.
This is the vibe coding hangover we’ve been writing about. The tools go fast. The security review doesn’t.
What You Should Actually Do
If you’re using any vibe coding platform — Lovable, Bolt, Replit, whatever — here’s the minimum viable responsibility:
Never ship auth code you didn’t write by hand. Let AI generate your UI. Let it build your CRUD endpoints. But the code that decides who can access what? That’s your job. A human job. The kind of job that AI is statistically terrible at.
Run a secrets scanner on every push. GitGuardian, gitleaks, trufflehog — pick your poison. If Lovable’s users had been scanning their own code, the hardcoded Supabase credentials would have been caught before deployment.
Read the code the AI wrote. All of it. I know it’s tedious. I know it defeats the point of generating it in the first place. But shipping code you haven’t read is shipping code you don’t understand, and that’s the root cause of every disaster in this article.
Assume “public” means “public.” If a platform offers a “public” setting, assume the worst-case interpretation. Lovable’s own users didn’t realize that “public project” meant “your chat history, source code, and database credentials are visible to the entire internet.” Read the fine print. Then read the API docs. Then test it yourself.
The Bottom Line
Lovable will survive this. They’ve raised $530 million. They have eight million users. They’ll patch the remaining vulnerabilities, hire a better PR team, and the news cycle will move on.
But the underlying problem won’t. We’re building software faster than we can secure it, and the gap is widening every quarter. The tools are getting more powerful. The developers using them are getting more confident. And the security review step — the boring, slow, unsexy part where someone actually reads the code — keeps getting skipped because it ruins the vibe.
Forty-eight days. That’s how long a BOLA vulnerability sat in a platform used by eight million people because a bug bounty report got filed as a duplicate.
If that doesn’t kill the vibe, I don’t know what will.
Related Reading:
Share this post
Comments
Leave a comment
NativeFirst Team
EditorialThe NativeFirst team — engineers and designers building native Apple apps and writing the courses we wish we had when we started.