Lovable Builds Your App. For 48 Days, Anyone on Lovable Could Read It.

Not the code. The platform.

On April 20, 2026, a researcher going by @weezerOSINT disclosed something that breaks from every prior Lovable security story. This wasn't about AI-generated code leaving RLS disabled. This wasn't an inverted if statement letting the wrong user through. This was Lovable's own infrastructure failing to keep your project separate from mine.

For 48 days — February 3 through April 20, 2026 — any registered Lovable user could read another user's project. Free account. No exploit. The project API returned whatever project ID you requested, as long as you were logged in.

Every project created before November 2025 was in scope.

What was actually readable

If your project fell in the affected window, another Lovable user could query your project artifacts and receive all of it.

Full source code — every file Lovable's AI generated, including your routing logic, database schema, and environment configuration. Database credentials — connection strings, API keys, and service role keys stored in the project. Your complete AI chat history — every prompt you sent while building, debugging, and iterating. Customer data — anything the project API surfaced from your connected database.

The chat history is worth pausing on. Builders paste real secrets into AI chat interfaces constantly. "Here's my Supabase connection string, why is this failing?" That conversation — and the credentials inside it — was readable by anyone on the platform.

With a service role key in hand, an attacker bypasses every RLS policy you ever configured. The security work you did correctly — the row-level policies, the auth middleware, the carefully scoped queries — none of it helps when someone connects directly to your database with the service role key they found in your chat history.

What Lovable said

@weezerOSINT did the right thing. They reported through HackerOne, Lovable's bug bounty channel.

Lovable's initial response: the behavior was "intentional."

Not "we're investigating." Not "thank you for the report." Intentional — as in, this is how it was designed to work. When the researcher pushed the disclosure forward, Lovable shifted to pointing at the HackerOne process. The public disclosure on April 20 was what moved things.

The response matters as much as the vulnerability. A researcher found a critical tenant isolation failure, followed proper disclosure channels, was dismissed, and had to go public. That's not just a security failure — it's a process failure.

Three incidents. Two different kinds of risk.

The first two were code-level failures. Painful, but auditable in theory — the insecure code was something you had access to review before you shipped. Lovable's AI generated it, but you could have caught it with a scan or a careful read before launch.

The third was a platform-level failure. There was nothing to audit. Your project lived on Lovable's servers. Their API served it to anyone who asked. You had no visibility into that decision and no ability to prevent it.

The distinction that matters

This is the line worth understanding before you choose where to build.

Code-level risk is what Flowpatrol scans for: the vulnerabilities in the app your AI generated. Missing ownership checks. Disabled RLS. Unsigned webhook handlers. These are real, common, and findable. If you scan your deployed app, you can find them. If you catch them before launch, you can fix them. The AI introduced the risk, but you have a path to catching it.

Platform-level risk lives inside the platform's infrastructure — its APIs, its multi-tenant boundaries, its data storage architecture. You can't scan for this from the outside. You trusted the platform to keep your project separate from the next user's project. When that trust breaks, no scan of your own app would have caught it. Your security practices didn't apply to Lovable's servers.

When a platform has repeated code-level incidents, builders can adapt: scan more aggressively, audit generated code, add a verification step before launch. When a platform has a platform-level incident, builders are simply exposed — and there was nothing they could have done differently.

What you should do right now

If you have a Lovable project created before November 2025, treat your credentials as potentially read during the 48-day window. These steps are concrete and sequential.

1. Rotate every credential stored in the project. Database passwords, API keys, service role keys, third-party integration tokens — all of them. Rotate first, investigate after. Don't wait to determine whether your specific project was accessed.

2. Audit your AI chat history for secrets. Search your Lovable conversation history for connection strings, environment variables, API keys, and passwords you pasted while troubleshooting. Treat each one as compromised and rotate it immediately.

3. Pull your database access logs for February 3 – April 20, 2026. If you use Supabase, check Supabase Dashboard → Logs → API logs for that window. Look for queries that match your schema but came from unexpected IP addresses or at unexpected hours.

4. Stop storing production credentials in AI builder interfaces. Going forward: secrets belong in your deployment platform (Vercel, Fly, Railway) as environment variables, not in a chat interface. Never paste a live service role key, connection string, or API key into an AI conversation.

5. Scan what's already deployed. If an attacker accessed your credentials and source code, they may have modified your app or its data. Flowpatrol checks your running app for the signs: endpoints that shouldn't be public, credentials surfacing in client-side responses, access control gaps in your API. You can't recall what was already read — but you can know exactly where your deployed app stands right now.

The pattern that doesn't show up in patch notes

Lovable will fix this the way they fixed the others. Each specific vulnerability gets closed. The RLS bypass was patched. The university auth bug was patched. This tenant isolation failure will be patched.

What doesn't appear in a patch note is the process question: how does a company ship a project API with no ownership check between tenants? Tenant isolation is not a feature — it's a constraint that has to be enforced at every API endpoint, every storage path, every new piece of infrastructure introduced by a platform update. That constraint needs to survive code reviews, staging deploys, and the pressure to ship fast.

Three incidents in 13 months is not a string of bad luck. It's a signal about the gap between how fast Lovable can ship new capabilities and how thoroughly those capabilities get tested before they reach production.

The question to sit with is not which credentials to rotate this time. It's whether the platform will hold the next time they ship.

Breach disclosed April 20, 2026 by @weezerOSINT. Reported by The Register and The Next Web.