Build · founder · 8 min read

Lovable's April 2026 Data Exposure: What Founders Need to Do Now

Lovable had a Broken Object Level Authorization flaw sitting open for 48 days. Here's what happened, what's at risk, and what to do if you built with Lovable.

Published April 21, 2026 ·

security lovable vibe coding founders BOLA

On April 20, 2026, a security researcher published evidence that Lovable — the most popular AI app builder for non-technical founders — had spent the previous 48 days sitting on a Broken Object Level Authorization (BOLA) vulnerability in its own API. Any free account could read other users’ source code, database credentials, AI chat transcripts, and customer data for projects created before November 2025.

Lovable’s initial response was to deny it was a breach, blame “unclear documentation,” and throw its bug-bounty vendor HackerOne under the bus. A day later, on April 21, the company issued a second statement that was closer to a real apology — but still laid the core blame on HackerOne for closing the original report as a duplicate.

If you have ever built something in Lovable, you need to understand this one. Not because your app was necessarily affected. Because the pattern of what went wrong — and how the company responded — tells you how to think about the whole category going forward.

What a BOLA flaw is, in one paragraph

Broken Object Level Authorization is OWASP’s number-one API security risk. It happens when an API checks whether you are logged in, but fails to check whether you actually own the thing you’re asking for. In Lovable’s case, the API endpoints that served project data (/projects/{id}/...) verified your Firebase authentication token, but didn’t verify that the project ID belonged to your account. Any logged-in user could substitute any project ID and pull back the contents.

That is not a subtle bug. It is, in plain terms, “the front door has a lock, but the key is the same for every house on the street.”

The timeline, as best it has been pieced together

March 3, 2026. A researcher (posting on X as @weezerOSINT) reports the BOLA flaw to Lovable via HackerOne. HackerOne triagers close the report as a duplicate — referencing the fact that chats on projects marked “public” were already considered visible by design. Critically, the researcher was reporting something broader: that the API was returning data even when ownership didn’t match. That distinction was lost in triage.

February 2026 (context). In a backend unification effort, Lovable accidentally re-enabled chat access on public projects. This is the specific thing the company now acknowledges as its “mistake” — but the underlying BOLA surface was wider than just public-project chats.

March–April 2026. Lovable ships new ownership checks for new projects. Projects created before that ownership check was added remain exposed.

April 20, 2026. The researcher publishes the details publicly, along with a concrete demonstration: they pulled Supabase credentials from an exposed admin panel for Connected Women in AI (a Danish nonprofit with over 3,700 real developer records for 2026), then used those credentials to query the live database and retrieve names, job titles, LinkedIn profiles, and Stripe customer IDs belonging to real professionals at Accenture Denmark and Copenhagen Business School.

April 20, 2026 (later that day). Lovable reverts the February change so chats on public projects are private again. CEO Anton Osika posts on X denying the characterization of “mass data breach” and pointing to “intentional behavior” plus unclear documentation. Coverage in The Register, CyberNews, Computing, and GBHackers is less forgiving.

April 21, 2026. A second Lovable statement acknowledges the prior post “didn’t properly address our mistake,” explains the February misconfiguration more directly, and confirms the public-project chat hole has been closed — while continuing to attribute the root-cause miss to HackerOne closing the original report.

What was and wasn’t actually exposed

This matters a lot. Read it carefully.

What was exposed, for affected projects: Source code generated by Lovable, AI chat transcripts from those project sessions, and — most importantly — any credentials that your AI assistant wrote directly into your code. The most common example is a Supabase service-role key pasted into a config file so the app could call the database. If your project had keys hardcoded somewhere, those keys were exposed.

What “affected” meant, in practice: Projects created before Lovable’s ownership-check backfill. Lovable has been vague on exactly which projects those are, but the safe assumption for non-technical founders is: if you built it before March 2026, treat it as potentially affected.

What was not exposed through this specific flaw: End-user data stored inside your app’s database is not directly exposed by the Lovable API bug. But it is exposed transitively — once an attacker has your Supabase credentials out of your source code, they can read your production database directly. That’s exactly what the researcher demonstrated.

The Stripe or payment credentials issue. If your app handled payments and your Stripe secret keys were baked into the generated project, those were in the exposed surface too.

The checklist if you built on Lovable before March 2026

Run through this today. Not next week.

1. Rotate every credential that ever lived inside a Lovable project. This includes Supabase keys, Stripe secret keys, SendGrid/Resend API keys, any third-party API keys, OAuth client secrets, and anything else your project holds in an .env file or config file. Go to each vendor’s dashboard, rotate the key, and update the new one in your project. If you have a running production app, plan the rotation so you don’t cause downtime. You may not have been breached — but your keys have been sitting in a place you did not authorize them to sit.

2. Audit your Supabase database. Log into Supabase, open the SQL editor, and run the built-in audit log view. Look for queries that did not originate from your own IP or server. Check the authentication logs for sign-ins you don’t recognize. Pay particular attention to service-role queries that read whole tables.

3. Check your app’s traffic logs. Most apps built on Vercel, Netlify, Cloudflare, or Supabase edge functions have request logs. Look for patterns of unusual scraping — repeated calls to /api/users, /api/orders, /api/customers, or any enumeration endpoints you exposed.

4. If you stored real user PII — act as if it was exposed. For any app that held real names, emails, addresses, or payment metadata, the conservative assumption is that this data should be treated as having been in an insecure state. Depending on your jurisdiction and user base (GDPR, CCPA, HIPAA), you may have a disclosure obligation. Talk to a lawyer. Not tomorrow.

5. Turn on the “Private by default” setting on all your Lovable projects. Any project you don’t explicitly need to share publicly should not have public visibility. The UI for this is under project settings.

6. Run the Aikido automated pentest before shipping anything net new. Lovable’s own Aikido integration ($100 per test, 1–4 hours) is the fastest practical security check for a Lovable-built app. Use it before a launch or a marketing push, not after.

What this tells you about the category

Two things, and they both matter.

First: AI app builders are shipping at a speed that outpaces their security posture. Lovable is the best-resourced company in the category and they still ran a BOLA flaw in production for at least 48 days after it was reported. That’s not a Lovable problem in isolation. Every tool in this category — Bolt, Base44, Create, v0, Emergent — is under the same pressure to ship features, and the same inherent difficulty of generating secure code from natural-language prompts. Expect more incidents, not fewer.

Second: how a company responds is part of the product. Lovable’s first public statement was defensive and deflective. Its second was better. The gap between those two statements is where trust lives. When you’re picking a tool that will hold your customer data, the response pattern to security issues is as important as the features.

What Lovable should do from here

This isn’t our site’s usual beat — we’re a tool review site, not a security publication — but the actionable pieces are clear enough to call out.

The company should publish a concrete list of which project-creation-date ranges were affected, so users know whether to rotate credentials. It should take responsibility publicly for closing the HackerOne report as a duplicate instead of escalating. It should commit to a specific timeline for a third-party API security audit, and publish the summary. And it should stop framing this as a documentation issue. It was an authorization issue. Using the right words matters.

The honest bottom line for founders

Lovable is still the fastest way for a non-technical founder to build a working SaaS app. The capabilities it unlocked in 2025 and 2026 are real, and nothing that happened this week changes that. You can still use Lovable.

What has changed is the default assumption you should carry into the tool. Do not put real customer PII, payment credentials, or regulated data into a Lovable-built app that has not been independently security-reviewed. Validate with fake data. Ship with a security pass. Rotate credentials on any schedule that outlives the first version of any project.

If you want a second opinion on whether your specific build needs a security audit before you onboard real customers, the answer is almost always yes. The cost of a one-off audit is between $1,000 and $5,000. The cost of being the next headline is categorically larger than that.