A HackerOne report called it "intended design." It was a free pass to your database.
A security researcher needed five API calls to read another stranger’s database password on Lovable. Not an edge case, not a jailbreak — a documented, reproducible path, open to any free account, against every project built on the platform before November 2025. Source code, Supabase credentials, Stripe customer IDs, and the full AI chat history where a founder had argued with the model about their own table structure — all of it readable by someone who never signed up for that project.
Someone had already told Lovable. A HackerOne report (#3583821) flagged the flaw on March 3, 2026. It was triaged, folded into an older ticket, and closed. Lovable’s own read, at the time, was that this was intended design. Forty-eight days later, with nothing patched, the researcher who filed it — disclosing publicly on X on April 20 — published the exploit instead, along with a proof against a real project: a Danish nonprofit called Connected Women in AI. Full admin panel, full source, the works. Lovable fixed it within the week of going public, not the week of being told.
This is the part worth sitting with if you’ve ever filed a bug and watched it sit: the gap wasn’t technical. The fix, once it landed, was a standard object-level authorization check — look up who’s asking before returning what they asked for. Forty-eight days is how long “intended design” survives contact with an audience instead of a form.
Three weeks later, on May 7, the Israeli security firm RedAccess gave Axios and WIRED a different number: 380,000 publicly reachable projects, scanned across Lovable, Base44, Replit and Netlify, no exploit required — just the URL, because these platforms ship a new project set to public by default and leave the owner to find the toggle. About 5,000 of those were actively leaking something real: medical records, clinical trial data, unredacted customer-service transcripts, a shipping company’s port schedules, a bank’s internal financials. A few were phishing pages, built on Lovable, wearing Bank of America’s and FedEx’s logos.
Four separate companies, four separate codebases, the same two defaults: ship public, and don’t check who’s asking. Broken object-level authorization (BOLA) has been the #1 entry on OWASP’s API Security Top 10 since the list existed — it’s not an exotic bug, it’s the first thing a security review looks for, and it’s exactly the kind of invisible plumbing an AI model won’t write unless you know to ask for it specifically. Most people generating an app in one prompt don’t know that question exists.
I read these incidents the way I read everyone else’s generated output — not to feel smug about it, but because figuring out who ends up holding the data is the same question I’ve been building FOKL’s answer to, which right now is only “the data never leaves the one device it’s on,” nothing shipped, nothing to click. The honest version of that bet is boring: there’s no backend to leave public.
FAQ
What was the Lovable BOLA vulnerability?
A broken object-level authorization (BOLA) flaw in the AI app builder Lovable let any free account read another user's project source code, Supabase database credentials, Stripe customer IDs and full AI chat history, for any project created before November 2025, using five API calls. Security researcher @weezerOSINT disclosed it publicly on X on April 20, 2026, after it sat unfixed for 48 days.
How long was the Lovable data exposure open before it was fixed?
The flaw was first reported through a HackerOne report (#3583821) on March 3, 2026. Lovable's triage team closed it, treating the behavior as intended design. It remained unpatched for 48 days, until the researcher who filed it disclosed the exploit publicly on April 20, 2026, with Lovable shipping a fix within the week that followed.
Is Lovable the only AI app builder affected by data exposure issues?
No. On May 7, 2026, the Israeli security firm RedAccess told Axios and WIRED it had scanned 380,000 publicly reachable projects built across Lovable, Base44, Replit and Netlify, and found roughly 5,000 actively leaking sensitive data such as medical records, financial documents and unredacted customer-service transcripts. All four platforms shared the same default: new projects set to publicly accessible unless the owner manually changes that.
What is broken object-level authorization (BOLA)?
BOLA is a security flaw where an application returns data for whatever object ID is requested without checking whether the requester is actually allowed to see it. It has been the #1 entry on OWASP's published API Security Top 10 for years, making it one of the most common and well-documented API vulnerabilities, not a novel or exotic one.
Why do AI-generated apps leak data more often than hand-built ones?
An object-level authorization check is invisible, boring plumbing that an AI code generator won't write unless a prompt specifically asks for it, and most non-developers using a one-prompt app builder don't know that question exists. Combined with platforms that default new projects to publicly accessible, the result is a structural pattern rather than a single company's mistake.
Made with FOKL — little apps your family keeps.