In April 2026, it came out that anyone with a free account on Lovable — a $6.6 billion “vibe coding” platform used to build apps without writing code by hand — could read the source code, database credentials and AI chat history of thousands of other people’s projects. It took five API calls. The flaw had been reported 48 days before it went public.
What actually happened
A security researcher known as @weezerOSINT reported the vulnerability to Lovable’s bug bounty program on March 3, 2026. It was a BOLA (Broken Object Level Authorization) flaw: the app checked that a user was logged in, but never checked whether they had permission to view THAT specific project. By changing an identifier in the request, any free account could reach other users’ projects — source code, Supabase credentials hardcoded into the code, AI chat conversations, and customer data included.
The flaw affected every project created before November 2025 — thousands of applications. A related case, found in February 2026 by a different researcher, had already exposed 18,697 user records from a single app built on the platform, including student accounts from universities like UC Berkeley and UC Davis.
When it went public on April 20, 2026, Lovable’s initial response was to deny any data breach had occurred, attribute it to “intentional behaviour,” and blame unclear documentation. They later apologised. The flaw was patched for new projects, but never fixed for the ones that already existed.
Why this can happen to a European SME too
The mistake wasn’t the idea of generating code with AI — it was a permissions check nobody verified independently before launch. This is exactly what happens when an SME (or the agency building its site or app) uses AI tools to ship something fast — a form, a client dashboard, a small internal tool — and publishes it without anyone checking whether permissions actually work as intended.
The question to ask isn’t “did the AI write secure code?” It’s simpler: did anyone, using an account with no privileges, actually try to access data that shouldn’t be reachable? That check — changing an ID in a URL or request and seeing what happens — can be done by anyone, no security expertise required, and it would have caught this flaw in Lovable before it ever affected anyone.
What to do if your site or app uses AI-generated code
- Test permissions manually: using a test account with no privileges, try to access “another user’s” data by changing IDs in the URL.
- Never leave credentials or keys in code the AI generates — it’s one of the most repeated failures in apps built this way (we saw it too in the Moltbook case).
- Get an outside review before launching anything that handles customer data, even if an AI “wrote” it over a weekend.
- Keep the site reviewed on an ongoing basis, not just at launch — permissions can break in a later update, exactly as happened here.
If you’re not sure where to start, here’s what vibe coding is and the basic risks worth watching, and with WP Shield we review and keep an eye on your site on an ongoing basis, not just on launch day.
Frequently asked questions
What is a BOLA flaw in simple terms?
It’s when an app checks that you’re logged in, but doesn’t check whether you have permission to see the specific piece of data you’re requesting. It’s one of the most common security flaws in web applications, AI-generated or not.
Does this mean I shouldn’t use AI tools to build websites or apps?
No — it means whatever the AI generates needs the same basic security review as any other code before it handles real customer data. The problem isn’t the tool; it’s publishing without verifying.
How do I know if my site has a similar flaw?
A basic review tests exactly this: logging in with a no-privilege account and trying to view data that shouldn’t be reachable. If that test has never been run on your site, it’s the first step to take.
Sources: The Register, Halborn.