On April 20, 2026, a researcher posting as @weezerOSINT showed that a free Lovable account could read another user’s source code, database credentials, and AI chat history through five API calls, no exploit chain required, just an ID any signed-in account could already see. Lovable’s response moved through three positions in one day: first that no breach had happened, then that the exposure was “intentional behavior,” then that the real fault was unclear documentation.
Whatever the platform ends up calling it, here’s what matters if you built something on Lovable. This was a Broken Object Level Authorization flaw, BOLA for short, and it’s the same failure class I keep finding in AI-built apps this incident never touched. I audit apps for a living, and I’ve traced 7 of 21 third-party apps in the AxonBuild corpus to a version of the same mistake: a logged-in customer reads or writes another customer’s data because nothing on the server checks whether they own the row they’re asking for.
There are two separate questions here, and only one of them is really about Lovable: whether your project was caught in the specific window this incident covers, and whether your own app repeats the platform’s mistake somewhere the April fix never reached.
That is intentional behavior. We have experimented with different UX for how the build history is surfaced on public projects, but the core behavior has been consistent and by design.
That’s Lovable’s own language, from its April 20 statement, before the company walked it back to “our documentation of what ‘public’ implies was unclear.” Neither version changes what a stranger with a free account could actually do.
The Lovable security breach timeline
The Lovable breach ran seventy-six days: a February 2026 backend change quietly reopened access that had been locked down since 2025, a February 22 HackerOne report was closed without escalation, and the fix shipped on April 20, within two hours of public disclosure.
What was exposed, and whose projects
The exposure covered four things inside any public project created before November 2025, when Lovable made private-by-default the setting for new work: source code, database credentials (Supabase connection strings and service-role keys), AI chat history (your prompts and whatever system context the model saw alongside them), and any customer data sitting in a connected database. Private projects and Lovable Cloud were never in scope, and neither was anything created after the November cutoff unless it had been public at some earlier point and never got switched back.
What that meant in practice wasn’t abstract. As Bastion’s writeup of the incident lays out, anyone who had connected a database to a public project before the cutoff had that data sitting exposed too, beyond the project owner’s own work: whatever customer, employee, or partner records the connected database held. The researcher’s demonstration showed how far that reached: hardcoded Supabase credentials from one exposed project opened a Danish nonprofit’s live database, and the records inside included real names, job titles, LinkedIn profiles, and Stripe customer IDs of professionals from Accenture Denmark and Copenhagen Business School. Neither organization built anything on Lovable; their people’s data was simply sitting in someone else’s project.
This is also the platform’s second authorization incident this year. In February 2026, Taimur Khan reported inverted authentication logic in a separate Lovable-hosted app, featured on Lovable’s own Discover page with over 100,000 views, that let anonymous visitors in while blocking logged-in users. It exposed 18,697 records, 4,538 of them student accounts, from UC Berkeley and UC Davis. His report went in through support and closed with no response. If you built your app on Lovable, whether you were caught in this specific incident is the smaller question.
Were you affected? Here’s how to check
Start with the project, not the platform. If you have a Lovable project that predates November 2025 and was ever set to public, even briefly, treat everything inside it as seen by someone else. The honest caveat: no per-victim count exists, so what was reachable and what was actually taken are separate facts, and nobody has published evidence on the second. That silence is exactly why treat-as-exposed is the only defensible default. If your project has always been private, or you created it after the cutoff and never toggled visibility, you’re outside this specific window, though the checks below are still worth ten minutes.
- 01 Check your project’s creation date and its visibility history. If it was public at any point before November 2025, assume the exposure happened.
- 02 Rotate every credential that lived inside that project: Supabase anon and service-role keys first, then any third-party key you ever pasted into a Lovable chat, Stripe, Resend, OpenAI, whatever you connected.
- 03 Confirm the project is private now, and check your Row Level Security policies directly in Supabase rather than trusting a green badge in Lovable’s own scanner.
- 04 Pull your Supabase logs for reads you don’t recognize, going back as far as your plan retains them.
- 05 If the project held anyone else’s personal data, your notification duty doesn’t wait for Lovable to decide whether it was a “breach.”
What your own Lovable app ships, breach or not
The BOLA class behind the Lovable incident is the same failure class the apps themselves ship: 7 of 21 third-party apps in the AxonBuild corpus let a logged-in user read or write another customer’s data, independent of any platform bug. The checklist above only answers whether you were caught in this specific window.
That rate comes from the 26 apps in the AxonBuild corpus, and usually the cause sits in the app itself: an endpoint that checks whether you’re logged in and stops there, never asking whether the row you asked for belongs to you. The platform’s own exposure ran for seventy-six days without looking wrong from anywhere: it produced no error, raised no alert, and changed nothing a user could see. A BOLA hole in your app behaves exactly the same way, which is why “nothing seems wrong” is the one signal that carries no information here.
I found a version of it myself, auditing a multi-tenant B2B ops app with no connection to Lovable or this incident. The session was a plain JSON object written straight into a cookie, no signature, no encryption, and the server trusted it on read. Open the browser tools, change one field to another workspace’s ID, and every tenant’s alerts, customer records, and orders were mine to read or edit. The rest of the codebase was some of the cleanest I’d audited, strict TypeScript, almost no duplication. One unsigned cookie was the entire tenant boundary.
Lovable’s own history carries the same lesson from a different angle. CVE-2025-48757, disclosed in May 2025, found 170 of 1,645 scanned Lovable projects exposing 303 vulnerable endpoints, emails, API keys, financial data, through Row Level Security that existed on the table but wasn’t enforced. Different mechanism than the April incident’s missing-authorization check, same failure underneath: a permission rule was supposed to run on every request, and for some slice of apps, it didn’t. What Lovable’s own passing check can and can’t see is that story told in full.
Run one specific check on your own app: log in with two accounts, and see whether the second one can read the first one’s data by changing an ID in a URL. That’s the thing a platform-level fix, however fast, was never going to check for you.
Lovable’s trust center covers the platform, not your app
Lovable’s own security posture is genuinely substantial: SOC 2 Type II, SOC 2 Type I, and ISO 27001:2022 certification, published at its trust center, plus an automatic scan on every publish that checks database configuration, RLS rules, and known misconfiguration patterns in about 10 to 15 seconds. All of that is real work, and it answers a different question than the one this post is about.
A SOC 2 report certifies Lovable’s own internal controls: how the company handles its infrastructure, its access policies, its incident response. It says nothing about whether the specific app you built checks that a customer owns the row they’re requesting, and the publish-time scan confirms RLS is switched on rather than confirming your policy blocks the request you’d expect it to block. The gap between RLS existing and RLS working is exactly what this incident hinged on for Lovable’s own infrastructure, and it’s the same gap a platform-level trust center was never built to close for the apps running on top of it, which is why whether Base44 is safe resolves into the same two answers despite its own SOC 2 and ISO 27001 attestation. Why AI coding tools ship holes like this by default walks through the mechanism, and the record from 26 real audits is the fuller version of the number quoted above.
If you don’t know which side of that gap your app sits on, the scorecard walks through the same domains in about two minutes and names the one most likely to be your weak spot. Is your AI-built app ready to launch covers the rest of the list.
Common questions about the Lovable breach
Was Lovable hacked, or was this “intentional behavior”?
Neither framing survives contact with what a free account could actually do. Lovable’s first statement called the exposure “intentional behavior,” then walked that back to a documentation problem. Nobody broke in. A backend change in February 2026 reopened access that had been deliberately shut down in 2025, and the fix shipped within two hours of public disclosure. What changed: an authorization control that used to hold, didn’t, for close to eleven weeks.
Which Lovable projects were affected?
Public projects created before November 2025, when Lovable switched new projects to private by default. If your project fits that description and was ever set to public, even for a short window, its source code, database credentials, and AI chat history were reachable by any signed-in Lovable account. Private projects and Lovable Cloud were never in scope.
I built my app on Lovable. How do I check if I was affected?
Check your project’s creation date and visibility history first. If it predates November 2025 and was public at any point, work through the credential rotation and RLS check in the section above. If it’s newer or was always private, you’re outside this specific incident, though the same checks are worth running anyway: the incident’s cause and your app’s own authorization gaps are related, not identical.
Is Lovable safe to use after the breach?
Lovable shipped its fix within two hours of disclosure and converted the affected historical projects to private, a fast and correct response to this specific flaw. That’s a real answer about whether this exact hole reopens. Whether Lovable is safe is really three questions, and this incident answers only the platform one. Whether the app you build with Lovable, or any AI builder, checks by default that one customer can’t read another’s data is a separate question, and its answer lives in your app’s own authorization logic, not the platform’s infrastructure. The number worth holding onto: 7 of 21 third-party apps I’ve audited had that exact gap, independent of which tool built them.
Don't guess where you stand.
The free 2-minute Beyond the Demo Scorecard estimates where you stand across 12 readiness areas and shows what to check first.
