Anyone with a free Lovable account could access other users’ source code, database credentials, API keys, and full AI chat histories — using just five API calls. The vulnerability sat open for 48 days after a security researcher reported it. Lovable’s initial response was to deny anything was wrong.
Lovable is an AI-powered “vibe coding” platform valued at $6.6 billion after its Series B funding round. Companies including Uber, Zendesk, and Deutsche Telekom use it. The platform lets users describe what they want in plain language and generates working applications — complete with backend connections to services like Supabase, Stripe, and Google APIs.
The problem: when the AI generates those apps, it frequently hardcodes the credentials directly into the source code. And until April 20, anyone could read that source code.
What Was Exposed
The vulnerability was a Broken Object Level Authorization (BOLA) flaw — one of the most basic API security failures that exists. The platform’s API endpoints didn’t check whether the person making the request actually owned the data they were requesting.
A security researcher demonstrated the attack on March 3 by creating a free Lovable account and making five API calls. They accessed another user’s profile, their public projects, full source code, and then extracted database credentials embedded in the code.
The exposed data included:
- Source code from thousands of projects, including hardcoded credentials for Supabase databases, Stripe payment processing, and Google API services
- AI chat histories — every conversation between users and the AI, revealing business logic, internal requirements, and development decisions
- Personal information — names, job titles, LinkedIn profiles, and Stripe customer IDs
- Student records — 4,538 accounts from UC Berkeley and UC Davis, including data belonging to minors
A separate study found that 70% of Lovable apps had Supabase row-level security entirely disabled, meaning the exposed database credentials gave direct access to whatever data those apps stored.
Denied, Deflected, Then Apologised
Lovable’s response followed a pattern that’s become depressingly familiar in tech.
Step one: deny. When the researcher went public on April 20, Lovable stated flatly: “We did not suffer a data breach.” The company called the exposure “intentional behaviour,” claiming the visibility settings were “consistent and by design.”
Step two: deflect. The company then shifted blame to “unclear documentation” about what “public” means on its platform. Next, they blamed their HackerOne bug bounty partners for closing the researcher’s report instead of escalating it — even though Lovable’s own outdated internal documentation told triagers that the behaviour was expected.
Step three: partial admission. Lovable eventually acknowledged that in February 2026, while “unifying permissions in our backend,” they accidentally re-enabled access to chat histories on public projects — undoing a fix they’d previously implemented. The company admitted their “initial communication regarding the public report missed the mark.”
It took two hours to fix the vulnerability once it became a public embarrassment. It had been reported 48 days earlier.
A Pattern, Not an Accident
This wasn’t a one-off. A study of 1,645 Lovable apps found that 170 had unauthorised access issues. A separate analysis of AI-generated code found that 40-62% contained security vulnerabilities. In Q1 2026, 91.5% of “vibe-coded” apps had hallucination-related security flaws.
The appeal of platforms like Lovable is obvious: describe what you want, get a working app. But the AI doesn’t think about security. It optimises for getting the app to work, which often means hardcoding credentials, skipping input validation, and disabling security features that get in the way of a quick demo.
When thousands of people use a platform like this to build real applications — apps that handle payments, store personal data, manage student records — every one of those security shortcuts becomes someone else’s problem.
Why This Matters
Lovable’s breach is a case study in why “just trust the platform” is a losing strategy for anyone who cares about their data.
The platform stored everything — your source code, your database credentials, your AI conversations, your customers’ data — and protected it with an authorisation check so basic that a free account and five API calls were enough to bypass it. When a researcher reported the flaw, the company closed the report. When it went public, they denied it. When denial stopped working, they blamed their partners.
Every app built on Lovable that embedded third-party credentials turned the breach into a supply chain event. If your Supabase database URL and service key were in an exposed project, anyone who found them had direct access to your data — and your users’ data.
This is the trade-off hiding behind every convenience-first cloud platform. You hand over your code, your credentials, and your business logic to a service you don’t control. You assume they’ve handled security properly. When they haven’t, you find out from a researcher’s post on X, not from the company itself.
What You Should Do
If you’ve built anything on Lovable, especially before November 2025:
- Rotate every credential that ever appeared in your Lovable project — Supabase keys, Stripe secrets, API tokens, database passwords. All of them
- Audit your Supabase row-level security — if it’s disabled, your data is accessible to anyone with the connection string
- Review your AI chat history for sensitive business information, customer data, or credentials you discussed during development
- Check whether your app stores personal data and consider notification obligations under GDPR, state privacy laws, or other regulations
- Move credentials to environment variables — never hardcode secrets in source code, regardless of which platform you’re using
The AI can generate your app. It won’t protect your data. That part is still on you — and on the platform you chose to trust.