Lovable has now managed three distinct security incidents in about a year. The first was a May 2025 study showing that 170 of 1,645 sampled Lovable apps had unauthorized access issues. The second was a February 2026 incident where a researcher found 16 vulnerabilities - including backwards authentication logic - in a featured app with 18,000 real users. And then there's the third one, which is the subject of this entry: a broken object-level authorization flaw in Lovable's own API that exposed every project created before November 2025 to any free-tier user who bothered to poke at the right endpoints.

BOLA - Broken Object Level Authorization - is ranked first on OWASP's API Security Top 10. It's been at or near the top of that list since OWASP started publishing it. It's not obscure; it's the most common and well-documented class of API vulnerability there is. The flaw: your API verifies that a request is authenticated, but doesn't verify that the authenticated user is authorized to access the specific object they're requesting. You can log in, then ask for someone else's data, and the server gives it to you because you proved you're a user - just not that you're the right user for this particular resource.

This is what Lovable shipped, apparently, for an undetermined period before March 2026.

Five Calls From a Free Account

The mechanics were straightforward. Lovable's /projects/{id}/* endpoints checked for a valid Firebase authentication token - so you had to be logged in - but didn't verify that the authenticated user owned the project identified by {id}. Which means a free-tier account holder could substitute any other project's ID into the URL and retrieve that project's data.

What data? Everything Lovable stores per project: the full source code, the database credentials (Supabase keys and connection strings), and the entire AI conversation history - every prompt the developer ever typed, including error logs they pasted, architectural discussions, and any credentials they shared mid-session for convenience.

A security researcher figured this out and documented it in five API calls. Not five days of work. Five API calls.

The researcher filed a report with Lovable's bug bounty program on HackerOne on March 3, 2026. This is the correct, responsible thing to do. You find a vulnerability, you report it privately to give the company a chance to fix it before it becomes public knowledge. Standard responsible disclosure.

The Fix That Wasn't

Lovable patched the ownership check - but only for new projects. Projects created before November 2025 remained exposed.

When the researcher filed a second report documenting that the existing projects were still vulnerable, Lovable marked it as a duplicate and closed it. The rationale, apparently, was that the original issue had been "fixed" because new projects were no longer affected. The existing projects - every project on the platform with a creation date before November 2025 - didn't count as the same bug, or something.

Forty-eight days elapsed between the initial March 3 report and the public disclosure on April 20.

Whose Data Was Exposed

The affected projects included work by people at recognizable organizations. Connected Women in AI was named in reports; records linked to employees at Nvidia, Microsoft, Uber, and Spotify were referenced. This was not limited to hobbyist weekend projects - people were building real things on Lovable and those projects were sitting open.

The AI conversation history is the part that matters most. A vibe-coding session isn't just code - it's error messages with context, architectural decisions, business logic descriptions, and credentials pasted in mid-session because the AI needed them. All of that was accessible.

Lovable also stores project source code and Supabase connection credentials per project, because the platform provisions and manages database backends as part of its service. So in addition to reading someone's AI conversations, an attacker could extract the database credentials and connect directly to the underlying Postgres instance. The source code tells you how the app works; the credentials let you get into the database.

Lovable's Evolving Response

When the researcher went public on April 20, 2026, Lovable's response was not "we had a bug and here's what we did about it." It was a sequence of contradictory positions that, taken together, form a case study in how not to handle a disclosure.

Position 1: Lovable initially posted that it "did not suffer a data breach." This is technically deniable - no one confirmed mass exploitation - but characterizing "every project before November 2025 was readable by anyone with a free account for 48 days" as "no breach" is the kind of statement that requires a very specific definition of the word breach.

Position 2: Lovable described the accessible data as "intentional behaviour." This framing suggests the company believed unrestricted cross-account project access was a design choice, which raises obvious questions about what the intended design was.

Position 3: Lovable blamed its own documentation for the confusion. Unclear documentation about what data is publicly accessible is a separate problem from an API that hands you other users' source code when you substitute their project ID.

Position 4: Lovable blamed HackerOne for closing the follow-up report without escalation. This is the most creative of the four positions. HackerOne operates the bug bounty platform; Lovable sets the policies, reviews the reports, and decides what gets fixed. Marking a report as a duplicate that isn't actually a duplicate is an outcome of whoever made that call at Lovable.

None of these positions involved saying "we made a mistake and here's how we're fixing it" until after the public blowback.

Why BOLA Keeps Happening

How does a company with a $6.6 billion valuation ship the most common API flaw on the planet?

Part of the answer is that authorization bugs are genuinely easy to miss in certain development patterns. If your API layer is built as a series of authenticated endpoints - you check for a valid token at the middleware level and then pass control down to the endpoint handler - it's easy to forget that checking "is this user logged in" is not the same as checking "is this user allowed to access this specific resource." The authentication check passes; the authorization check never runs.

Automated security testing often catches SQL injection, XSS, and input validation failures because those have well-understood patterns that scanners know to look for. BOLA is harder for automated tools to find because it requires understanding what data belongs to which user, which depends on business logic the scanner doesn't know.

None of this explains leaving the old projects exposed after discovering the bug, or closing the follow-up report as a duplicate. That part is just a process failure.

This Is the Third Time

Vibe Graveyard already has two Lovable incidents. The public-buckets study (Lovable public buckets) documented the structural pattern of Lovable apps shipping with exposed Supabase storage because the AI doesn't reliably enable access controls. The EdTech app incident (Lovable EdTech app) showed a featured app with backwards authentication logic exposing 18,697 users.

This incident is different in kind: it's not a flaw in apps that Lovable's users built; it's a flaw in Lovable's own infrastructure. The platform itself was the attack surface. The previous two incidents were about what happens when AI generates insecure code for end users. This one is about Lovable's own API being misconfigured in a way that exposed its entire user base.

All three incidents share a common thread: the access control didn't work. Something was supposed to be private and wasn't. The reason varies - AI-generated code with no RLS, backwards authentication logic, missing BOLA checks - but the failure mode is the same each time. In a platform that markets itself on the premise that AI can safely build and host production applications, this pattern deserves more than a HackerOne triage error as an explanation.

Lovable's user base includes people building real applications for real users. Some of those users' project histories contain credentials. Some of those credentials are probably still in use. The company has not confirmed how many accounts accessed data they shouldn't have during those 48 days.