Why Lovable's BOLA Bug Stayed Open for 48 Days

On March 3, 2026, a security researcher reported a Broken Object-Level Authorization vulnerability to Lovable's HackerOne bug bounty. The vulnerability exposed source code, Supabase database credentials, AI chat histories, and user profile data (names, job titles, LinkedIn profiles, Stripe customer IDs) across thousands of Lovable projects. Lovable closed the report as duplicate. The platform patched the vulnerability for newly created projects. Existing projects stayed exposed.

On April 20, 48 days later, the vulnerability was publicly disclosed by TheNextWeb. The patch for existing projects arrived after that public disclosure, not before.

Read the timeline again. The bug bounty system worked. A researcher found the bug, reported it through the official channel, and Lovable received the report. The 48-day window is not the time it took to find the bug or to write a patch. It is the time between Lovable having the patch and Lovable applying the patch to the projects that needed it.

That window is the post.

What happened in Lovable's 48-day BOLA window?

A researcher reported the BOLA via HackerOne on March 3, 2026. Lovable closed the report as duplicate, applied the patch to newly created projects, and left existing projects exposed. The vulnerability was publicly disclosed on April 20. Lovable extended the patch to existing projects after the disclosure, (per TheNextWeb's reporting).

The Broken Object-Level Authorization class of bug is OWASP's #1 ranked API security risk. The Lovable implementation exposed data through the _public_ data flag, which controls whether records are accessible without authentication. The disclosure made it clear the flag's runtime behavior didn't match what builders expected when they used it.

Two prior incidents frame the policy reading. In May 2025, a sample of 1,645 Lovable apps found 170 (10.3%) with unauthorized-access issues and roughly 70% with row-level security disabled. In February 2026, researcher Taimur Khan disclosed 16 vulnerabilities (six critical) in a Lovable-featured app, exposing 18,697 user records including 4,538 student accounts from UC Berkeley and UC Davis. Three incident clusters in 12 months at a platform that closed December 2025 at a $6.6 billion valuation with 8 million users. The frequency isn't the headline. The response pattern is.

Why isn't this just a security-maturity problem?

It looks like one. The standard read of any three-in-twelve-months incident pattern is a company in security-maturity phase: fix the bugs, learn from each incident, hire a CISO, retain auditors, move on. That reading would explain a normal growing company. What it doesn't explain is the operational shape of Lovable's response.

Maturity-phase companies don't close bug bounty reports as duplicate and selectively patch one customer cohort. They patch the new flow and the old flow in the same change, even when the cost is higher. They escalate disputed closures when the original researcher pushes back. They publish incident retrospectives that name what they did wrong without distributing blame across documentation and partners.

The vibe-coding platform discourse has mostly stayed inside the maturity-phase read. Lovable, Bolt, Cursor, Replit, v0 are all young-ish platforms expanding faster than their security teams can scale. The incidents are unfortunate. The fixes will come. That reading isn't stupid. It would explain a normal company's growing pains. What it can't absorb is the specific shape of the 48-day window and what happened on April 20 once the disclosure became public.

What did Lovable's response look like?

Per TheNextWeb's structural reporting, Lovable's response to the BOLA disclosure cycled through four framings within a single day: denial that a breach had occurred, blame on the documentation for the _public_ flag being unclear, blame on HackerOne partners for closing the original report, and a partial apology acknowledging that pointing to documentation alone was not enough.

Lovable's framing of the exposed data is the line that does the structural work.

That framing is not the speech of a security-maturity-phase company catching up to its own scale. It is the speech of a platform whose first response to disclosure is to redefine the disclosure as the expected behavior of the product. Maturity-phase companies fix the bug, hold their breath, get cornered by the disclosure, apologize once, and move on. Posture-driven companies cycle through four denial frames in a single day.

The difference is not "Lovable is bad and Replit is good." I wrote in May about Replit and Vercel framing their security tooling launches differently. Replit framed its work as vibe-coding-specific. Vercel framed its as shifted-left-generic. The framing disagreement was the structural news. Lovable now adds a third position: the disagreement about whether the data exposure is a problem at all. Three platforms, three positions on what the vibe-coding security problem actually is, and only Lovable's pre-supposes that the exposure is by design.

The 48-day window is the operational expression of that position. Lovable patched new projects fast because new projects are the future revenue surface. Existing projects became a press-cycle question rather than a patch-cycle question. The choice to split those two responses is institutional.

What's the broader pattern from Q1 2026?

Security research surfaced in Q1 2026 found that 91.5% of vibe-coded applications contained vulnerabilities traceable to AI hallucination patterns, (per Android Headlines' coverage of the cluster). Gartner separately forecasts 60% of all new code will be AI-generated by end of 2026. The two numbers describe a doubling surface area on a 91.5% base failure rate.

Hold those two numbers next to the 48-day window.

The forecast says the surface area is doubling. The research says the base rate of vulnerability inside that surface area is 91.5%. The Lovable case says the institutional response to the resulting breaks, at one $6.6 billion platform, is: patch the new cohort fast, deprioritize the existing cohort, cycle through four denial frames if disclosure forces a response. That math does not get better with time, because the variable that determines the outcome is not the percentage of vulnerable code. It is the relationship between the platform and the builder when something the builder shipped is found to be exposing user data.

This is why this story is a who-creates-is-changing story, not just a security story. The vibe-coding wave is bringing domain experts and founders into building. Those are exactly the people who would not catch a BOLA bug in their own app's API by reading the AI-generated code. They are also building in regulated industries (healthcare, finance, education) where domain expertise is the moat. The platform's relationship with these new builders is the structural question of the next decade. Eight million Lovable users just got one answer to that question.

What does this mean for builders choosing a platform?

The choice when you pick a vibe-coding platform is not "which tool generates the cleanest code." The choice is "whose incident-response model am I trusting with my users' data." That choice is not legible from feature lists. It is legible from how the platform handled its last three security incidents.

Look at the pattern of those responses. A platform that treats shipped builders as collaborators escalates closed-as-duplicate reports when the original reporter pushes back. It patches existing projects in the same change as new projects. It publishes incident retrospectives that name what it did wrong without distributing blame across documentation and partners. It does not characterize exposed user data as expected behavior.

This isn't an aspirational standard. Several adjacent vendors operate at it today (the Vercel and Replit defender-stack post named two of them). The alternative to Lovable's posture is not "more mature security." It is treating shipped builders as the customers they are. The pillar the manifesto names for this is clients-are-co-creators, and the operational test is the response sequence after something breaks.

The 91.5% Q1 2026 base rate is the field. The Gartner 60% forecast is the trajectory. Lovable's 48-day window is one data point on what platforms do with that field and trajectory. The platforms that treat shipped builders as collaborators will have a different decade than the platforms that cycle through four denial frames in a single day. The next 60% of code being written is the rest of the story.