While the security community was still processing the Vercel breach last weekend, a second AI platform story broke on the same day — and in some ways it is more alarming. Not because of a sophisticated threat actor or a replayed OAuth token, but because of something far more mundane: an API that simply did not check whether you were allowed to see what you were asking for.
On April 20, 2026, security researcher @weezerOSINT posted on X: “Lovable has a mass data breach affecting every project created before November 2025. I made a Lovable account today and was able to access another user’s source code, database credentials, AI chat histories, and customer data — all readable by any free account.”
No exploit. No privilege escalation. No social engineering. Just five API calls.
What Lovable Is — and Why the Stakes Are High
Lovable is a Swedish AI-powered “vibe coding” platform that allows anyone to build functional web applications by describing what they want in plain language. No programming experience required. The AI generates code, connects a Supabase backend for authentication and database storage, and produces a deployable application. It has become one of the fastest-growing AI startups in Europe, completing a $330 million Series B in early 2026 at a valuation of $6.6 billion — a more than threefold increase in five months. Backers include CapitalG (Google’s growth fund), Menlo Ventures, NVIDIA, Salesforce Ventures, and Deutsche Telekom.
Its customer base is not limited to hobbyists. Employees from Uber, Zendesk, Nvidia, Microsoft, Spotify, and Deutsche Telekom use the platform. Startups have replaced five-figure Salesforce subscriptions with Lovable-built CRMs. Nonprofits have built membership platforms. Developers have prototyped internal tools, pasted API keys mid-session, shared database schemas with the AI assistant, and stored credential-bearing environment configurations — all trusting that their project data was theirs alone.
It was not.
The Vulnerability: BOLA, the Number One API Flaw in the World
The technical root cause is a Broken Object Level Authorization vulnerability — ranked first on the OWASP API Security Top 10 for its prevalence and the severity of its consequences.
BOLA occurs when an API verifies that a user is authenticated but fails to verify that the user owns or has permission to access the specific resource they are requesting. In Lovable’s case, the /projects/{id}/* API endpoints checked for a valid Firebase authentication token — confirming the user was a legitimate Lovable account holder — but performed no ownership check. Any authenticated user could substitute any project ID into the request and receive that project’s full data in return.
The exposed endpoint https://api.lovable.dev/GetProjectMessagesOutputBody returned full project message histories, AI thinking logs, tool-use records, and internal reasoning chains without enforcing any access controls.
What that means in practice: with a free account and five API calls, anyone could access:
- Full source code of any affected project
- Database credentials — including Supabase API keys providing direct read/write access to the project’s live database
- Complete AI chat histories — every prompt the developer ever sent, including pasted error logs, hardcoded secrets, and discussions of business logic
- Customer data stored in connected databases
- Internal AI reasoning logs — the model’s chain-of-thought that was never intended to be user-visible
Critically, the vulnerability was not limited to old abandoned projects. The API handled requests differently based on project creation date — new projects returned a secure 403 Forbidden, while projects created before November 2025 returned a 200 OK granting full source-tree access through the same endpoint. Researchers found one affected project that had received over 3,700 developer edits in 2026 alone.
What Was Actually Exposed: The Connected Women in AI Example
To illustrate the severity, the researcher demonstrated the vulnerability using a live admin panel belonging to Connected Women in AI, a Danish nonprofit. This was not an abandoned test project — it was an active platform with thousands of recent edits.
From the exposed source code, hardcoded Supabase credentials were extracted and used to query the live database, pulling real names, job titles, LinkedIn profiles, and Stripe customer IDs belonging to professionals from Accenture Denmark and Copenhagen Business School.
The AI chat history for the same project revealed the developer had walked Lovable’s assistant through the database schema in detail — discussing the structure of tables containing emails, dates of birth, and Stripe customer IDs. All of it was readable. The chat log was, in effect, a map to the database stored alongside the credentials needed to open it.
A subsequent scan of 1,645 apps built with Lovable found 170 of them had critical security flaws along the same lines.
This Was Reported 48 Days Ago. It Was Marked as a Duplicate.
Here is where the story becomes as much about disclosure process failure as the vulnerability itself.
The researcher reported the flaw 48 days before public disclosure. The original bug report, filed March 3, 2026, was submitted to HackerOne under the title: “Broken Object Level Authorization on Lovable API leads to unauthorized access to user data and project source code.” It was marked as a duplicate of an existing report and flagged as “Informative” — suggesting the issue was already known — yet the flaw remained exploitable on legacy accounts.
When the researcher discovered the bug was still live for pre-November 2025 projects and re-reported it, they were told the issue was already tracked. Then they went public.
Lovable’s Response: Three Phases in One Day
The company’s handling of the public disclosure ran through at least three distinct phases within hours:
Phase 1 — Denial. Lovable initially said it was “made aware of concerns regarding the visibility of chat messages and code on Lovable projects with public visibility settings,” and stated: “To be clear: We did not suffer a data breach.”
Phase 2 — Documentation Blame. The company acknowledged that “our documentation of what ‘public’ implies was unclear, and that’s a failure on us” — while simultaneously defending visibility of source code as “intentional behaviour.”
Phase 3 — Blame HackerOne. Lovable then explained that “unfortunately, the reports were closed without escalation because our HackerOne partners thought that seeing public projects’ chats was the intended behaviour.” Upon learning this, Lovable said it “immediately reverted the change to make all public projects’ chats private again.”
The full sequence: the company switched to private-by-default in December 2025, but access to public project chats was mistakenly re-enabled in February 2026 during backend permission consolidation work. A regression reactivated a vulnerability that had been partially addressed — and the bug bounty programme classified it as intended behaviour and did not escalate it.
Lovable eventually issued a more complete apology acknowledging that “pointing to documentation issues alone was not enough here.” But by then the story had run its full cycle across security media.
The Deeper Problem: AI-Generated Code Doesn’t Know What It Doesn’t Know
This is not exclusively a Lovable problem. It is a structural property of vibe coding platforms the industry has not yet honestly reckoned with.
When a developer — particularly a non-technical one, which is Lovable’s target market — uses an AI to generate an application, the AI produces code that may look functional and may even clear a pre-publish security scan. What it often does not produce is code that implements security correctly at the application layer.
Researcher Taimur Khan identified 16 vulnerabilities — six of them critical — in a single Lovable-hosted application featured on Lovable’s own Discover page with over 100,000 views. The main issue: apps built on Lovable use Supabase as the backend, and when AI-generated code fails to implement row-level security, flawed code ships without the developer knowing. In one case, a logic error in authentication code had completely inverted access control — authenticated users were denied access while unauthenticated visitors had full read access, exposing 18,697 user records including student accounts.
As security firm Symbiotic noted: “Telling developers to review security before publishing doesn’t work when those developers chose AI tools because they’re not security experts.”
This is the fundamental tension at the heart of every vibe coding platform. The value proposition is explicitly democratizing development for people without technical expertise. But security is a discipline requiring an understanding of what can go wrong — and surfacing a pre-publish warning then allowing users to click through it does not discharge the platform’s responsibility when the platform generated the insecure code.
The Supabase Credential Problem Is Systemic
One pattern appearing repeatedly across Lovable security incidents is hardcoded Supabase credentials in generated source code. Lovable’s default architecture uses Supabase as the backend for every application it generates. When the AI connects a project to a database, those connection credentials end up in the source code — and when source code is exposed through a BOLA vulnerability, a misconfigured public project, or a user sharing their code, those credentials provide direct database access.
A full Supabase service role key provides unrestricted read/write access to the connected database. An attacker reading source code from an exposed project is not just reading code — they have a working key to the underlying data store.
For any Lovable project created before November 2025 that connected to a Supabase database, those credentials should be treated as compromised and rotated immediately.
What You Need to Do Right Now
If you built on Lovable before November 2025, assume your project’s source code, AI chat history, and database credentials have been accessible to any authenticated Lovable user. Act accordingly:
Rotate all database credentials immediately. Every Supabase API key, service role key, and database connection string stored in or generated by your Lovable project should be considered compromised. Rotate at the Supabase level, not just in your code.
Audit your AI chat history for credential exposure. If you ever pasted an API key, environment variable, database URL, or secret into the Lovable chat interface, that value has been exposed. Rotate every credential that appeared in any session.
Audit your customer data. If your application stored user data in a connected Supabase database, determine whether that data was accessible through the exposed credentials. Depending on your jurisdiction and data type, this may trigger notification obligations under GDPR, CCPA, or sector-specific regulations.
For organisations whose employees use Lovable: The exposure is not limited to small developers. If employees used Lovable to build internal tools or prototype corporate applications before the November 2025 cutoff, proprietary code and database credentials could have been readable. Security teams should survey for Lovable accounts and treat any pre-November 2025 project credentials as potentially compromised.
For builders on any vibe coding platform: Never hardcode secrets in AI-generated code. Enable row-level security in Supabase for every table that stores user data. Treat AI-generated authentication code with special scrutiny. Understand what “public” means on any platform before you publish.
The Accountability Question
Lovable’s initial response — attributing the issue to unclear documentation and then to HackerOne — reflects a pattern visible across the AI development tool space. When AI-generated code ships with vulnerabilities, the question of who bears responsibility is genuinely contested: the platform that generated the code, the user who published it, or the bug bounty service that misclassified the report.
The honest answer is all of them, in different proportions. But the framing that puts the heaviest burden on the user — the non-technical developer who chose an AI tool precisely because they lacked the expertise to build security themselves — is the least defensible position.
As researcher Taimur Khan put it: “If Lovable is going to market itself as a platform that generates production-ready apps with authentication included, it bears responsibility for the security posture of the apps it generates and promotes. You can’t showcase an app to 100,000 people and then close the ticket when someone tells you it’s leaking user data.”
A $6.6 billion valuation built on promises of production-ready applications comes with obligations that “it’s in our documentation” does not satisfy.
April 2026: A Reckoning for AI Tool Security
The Lovable vulnerability and the Vercel OAuth supply chain breach surfaced on the same day. The technical mechanisms are completely different — Vercel required a sophisticated attacker with months of groundwork; Lovable required a free account and five API calls. But they share a structural cause: AI tools are being integrated into production development workflows at a pace that has outrun the security maturity of the platforms providing them.
Both incidents send the same message: the AI-assisted development ecosystem — from the tools that write your code, to the platforms that deploy it, to the integrations that connect it to your corporate infrastructure — is operating with security debt that is now coming due.
The velocity of AI adoption in software development is not slowing down. The security infrastructure around it needs to close the gap, fast.
Current Status
As of April 21, 2026, Lovable has stated that AI chat histories for public projects are no longer visible to other users and that newly created projects correctly return 403 errors to unauthorised requests. The company has not published a comprehensive post-mortem or confirmed whether legacy project source code exposure has been fully remediated.
Users who created projects before November 2025 should not wait for a platform statement. Rotate your credentials now.
This article draws on research by @weezerOSINT, Taimur Khan, The Register, Cyber Kendra, CyberNews, GBHackers, Cybersecurity News, and public statements from Lovable. The investigation is ongoing and reflects information available as of April 21, 2026.
