Lovable's April 2026 Breach: The Story, the Spin, and What It Means For Your App

If you built a Lovable app before November 2025, someone with a free Lovable account could read your source code, your AI chat history, and your customers' data. For 48 days. From five API calls.

That is the actual story. Lovable will tell it differently. Let's walk through what happened, what it means for the people who built apps on the platform, and the bigger lesson hiding underneath it.

What actually happened

On 20 April 2026, a security researcher posting as @weezerOSINT showed that a logged-in Lovable user could call the platform's project API, swap in another user's project ID, and get back the full source code, the AI chat that built it, and the database credentials embedded in that code. The flaw is called BOLA, Broken Object Level Authorisation. In plain language: the API forgot to ask "are you allowed to see this?" before answering.

Five API calls from a free account. That is the entire exploit.

The bug was reported to Lovable's bug bounty programme on 3 March 2026. Lovable patched it for projects created after November 2025. Older projects, the ones that were live when the bug was first reported, stayed exposed for another 48 days. A second researcher reported that gap. It was closed as a duplicate.

What was exposed

Three categories of data were readable for any user with a free account and a project link:

The source code itself. That includes any environment variables and database credentials a builder hard-coded into the project, which on a low-code platform is more common than the platform would like to admit.

The AI chat history. Every prompt, every response, every iteration. If a builder pasted an API key into a prompt to ask "why isn't this Stripe call working," that key is in the chat. If they shared a real customer email to debug a flow, that email is in the chat.

The customer data sitting in databases that those projects connect to. Once an attacker has the database credentials from the source code, the database is no longer protected by the platform. It is protected by whatever Row Level Security rules the builder set up on Supabase, which on most vibe-coded apps is "none."

By Halborn's count, the affected surface area is "tens of thousands" of projects. Earlier in February 2026, a separate single Lovable-hosted app was found to have leaked over 18,000 user records, including 870 with full PII. This is the third major Lovable security event in roughly thirteen months.

The spin

Lovable's first public response called the exposed chat history "intentional behavior" and pointed at unclear documentation. They then redirected questions about the bug bounty handling to HackerOne. By the next news cycle, the framing had softened to "an incident we are responding to," and a remediation post followed.

You will see this called the "supposed" Lovable hack in some places, because of how Lovable initially framed it. Let's be direct: when an unauthenticated stranger can pull your source code and your customers' email addresses with five API calls, that is a breach. The label does not change what was on the wire.

The more important point is the structural one. A platform that builds your app does not govern your app. Lovable's incentive is to ship features fast. Your incentive is to know your customers' data is safe. Those are not the same incentive, and they were never going to be.

What this means for your app (it depends on what your app does)

Here is where context matters more than the headline. Not every Lovable app is in the same boat.

If you built a personal landing page on Lovable and never connected a database, the impact is mostly your chat history. Embarrassing, possibly. Catastrophic, no.

If you built an internal tool used by ten people in your company, with hard-coded credentials to a dev database, the impact is bigger. Rotate everything, audit access logs, and ask whether the data in that database had any PII.

If you built a real product with paying users, with Stripe webhooks, with a customer database, with hard-coded API keys to anything: assume those credentials were readable for at least 48 days. Treat it as a credential compromise event. Rotate every key. Check every third-party service for unauthorised access. Look at your Supabase logs for queries you didn't write.

The same incident has three completely different recovery plans depending on what your app actually does. That is the point we keep making at NEKOD: a missing access-control check on a hobby project is a non-event, on a product with PII it is a notification obligation. Same bug, different consequences. We covered this lens in The 5 Security Gaps Hiding in Every Vibe-Coded App, and the Lovable incident is the cleanest real-world example of why it matters.

What to actually do this week

Five steps, in order:

Rotate every credential that was ever pasted into a Lovable project. API keys, database passwords, third-party tokens. If you don't remember pasting it, rotate it anyway.

Read your AI chat history for the project. Anywhere you see a real key, a real customer email, or a real password, treat that data as compromised.

Open your Supabase project and turn on Row Level Security on every table that holds user data. If you've never done this, this is a "stop everything else" task.

Check your auth provider, your Stripe dashboard, and your email service for any login or API call you didn't make.

Get an outside review of your app. Lovable patching the API does not patch the credentials your app already had hard-coded. It does not check your RLS rules. It does not tell you which of your endpoints leaks user data on a malformed request.

The lesson

The Lovable team will keep building. They will keep patching. The next BOLA-shaped bug is already in someone's commit history, on Lovable or any of the other platforms in this space. That is not a Lovable problem. That is the cost of how fast all of this is moving.

What is in your control is the layer above the platform. Your app's data, your app's auth, your app's compliance posture: those don't belong to Lovable, and they don't belong to Replit, and they don't belong to Cursor. They belong to you. We built nekod.one with Claude Code and ran our own scan against it for exactly this reason. We don't trust the platform to grade its own homework, and you shouldn't either.

Key takeaways

• A BOLA bug in Lovable's API let any free-tier user pull source code, AI chats, and database credentials from any project built before November 2025, for at least 48 days after disclosure.
• The exposed surface includes hard-coded API keys and customer PII, depending on what each individual project actually stored.
• The recovery plan is not the same for every app. A landing page, an internal tool, and a paid SaaS with PII all need different actions. Context decides.
• Rotate credentials, audit chat history for secrets, turn on Supabase RLS, check third-party services for unauthorised use, and get an outside review.
• A platform building your app is not a platform governing your app. Those are two different jobs.

Run a Free Scan on Your Lovable App

If your app was live on Lovable before November 2025, we'll scan it for the exact patterns this breach exposed: hard-coded credentials, missing RLS, broken access controls, and PII handling that won't survive a real audit. NEKOD's 360° review tells you where you stand and gives you a Launch Readiness Score for what to fix first, in priority order, based on what your app actually does.

Get Your Free Scan