LOVABLE ($6.6B) SHIPPED A BOLA. THE VIBE-CODING PLATFORM JUST GOT VIBE-CODED.

Lovable ($6.6B valuation) just shipped a BOLA. Change a project ID in the URL, free account, pull anyone’s entire source tree. .env files, live Supabase URLs, API keys. The platform that pioneered vibe coding just got vibe-coded by its own users.

What got exposed

The disclosure, covered by techsoma.africa, describes a Broken Object Level Authorization flaw on Lovable’s own platform — the number one entry on the OWASP API Security Top 10.

Mechanic:

• Attacker signs up for a free Lovable account.
• Finds an endpoint that serves a project by its ID.
• Swaps the project ID in the URL for someone else’s.
• The backend verifies who the caller is, but does not verify the caller owns the resource.
• The caller receives the target project’s full source tree.

What was inside those source trees, per the researcher:

• .env files with live secrets
• Supabase project URLs with valid keys
• Third-party API keys
• In one demonstrated case: an actively developed admin panel for a real-world non-profit

Why it’s a bigger story than the CVE

Lovable’s whole pitch is that vibe coders don’t need to think about this class of mistake — the platform is supposed to take care of auth, tenancy, and data boundaries. BOLA is the canonical “the platform forgot tenancy” bug. It’s what every Supabase-RLS mistake we’ve catalogued in the wild looks like, except shipped by the platform that claims to prevent those mistakes for you.

Two things compound this:

1. Every live Lovable project deploys to Supabase. A .env leak with a live Supabase anon key is not “credentials got exposed” — it is “someone has direct access to the rows.” If the target’s RLS is anything less than strict, the data behind the key is gone.
2. API keys in a leaked .env are chained blast radius. Stripe keys, SendGrid keys, Anthropic keys, GitHub tokens. Any of those is a second attack surface, unlocked for free.

What Lovable builders should do right now

1. Rotate every secret in every deployed project. Treat .env as burned until proven otherwise: Supabase service key, Supabase anon key, any third-party API keys you pasted in.
2. Audit Supabase RLS on every table. If your leaked anon key can read rows you would not hand to a random attacker, RLS is not configured. Not “probably not” — not configured.
3. Check your Stripe and SendGrid logs for activity you did not initiate. Keys that leaked hours ago may still be in active use.
4. Wire up secret rotation into your workflow. If rotating a project’s secrets is more than a one-command task, make it one. You are going to be rotating again.
5. Scan the deployed thing. A compromise of the builder-platform means apps built on it are effectively pre-compromised until you verify otherwise.

The pattern is not new

This is the same pattern as the February 2026 Lovable report we covered — 170+ breached databases out of 1,645 scanned, mostly RLS and credential exposure. It’s the same pattern as the Vercel / Context.ai breach — one AI-adjacent vendor compromise cascades into production access. It’s the same pattern that the ToxicSkills + MCP study documented for agent skills.

The pipe has three links now — platform → credentials → deployed app — and any one of them is enough. The only defense that survives a supply-chain link being broken is probing the deployed app directly.

That is what VibeEval does. Given the current state, running a scan against every Lovable project you’ve shipped this year is not paranoia — it is hygiene.

Source: techsoma.africa — Vibe-Coding Nightmare: Is the Lovable AI Data Breach Real?