In April 2026, a security researcher showed that any free Lovable account could read another user’s source code, database credentials, and full AI chat history. Five API calls. By substituting a project ID.
Lovable is a $6.6 billion platform used by eight million developers. Its enterprise clients include Uber, Zendesk, and Deutsche Telekom. The vulnerability class — BOLA, or Broken Object Level Authorisation — has held the number one spot on the OWASP API Security Top 10 since 2019. The exposure window ran 76 days total. The window after a formal security report was filed: 48 days.
This article reconstructs the timeline, explains the mechanism, documents the company’s response, and gives you a concrete checklist if your team built on Lovable. This incident is part of a broader pattern documented in our vibe coding security reality check — worth reading for full context on what the category looks like across the board.
What Is a BOLA Vulnerability and Why Does Vibe Coding Produce Them So Reliably?
BOLA stands for Broken Object Level Authorisation. It is API1:2023 on the OWASP API Security Top 10 — OWASP being the Open Worldwide Application Security Project, the vendor-neutral body that ranks API security risks. BOLA has held the top spot since 2019.
Plain English version: the server checks that you are logged in, but it does not check whether the object you are requesting actually belongs to you. Any authenticated user can retrieve any other user’s data just by swapping a different ID into the API request. You are authenticated. The failure is one step later — the ownership check. In BOLA, that check simply does not exist.
Here is why vibe coding produces this so reliably. AI models are trained on code where authentication logic is everywhere — login flows, session tokens, JWT verification. Per-object ownership checks are not. The model generates a working login and wires it to API endpoints, but the authorisation layer — “does this user own this resource?” — is sparse in training data, so it is sparse in output. A senior developer writing a /projects/{id} endpoint includes an ownership guard almost by instinct. A vibe-coded equivalent generates the route, wires it to the database, and ships.
In Lovable’s case, the exploit chain required five API calls. Authenticate with a free account. Call /projects/{id}/*, /git/files, /git/file, /documents. Substitute someone else’s project ID. The API verified a Firebase auth token but never checked whether the authenticated user owned the project. The response was a 200 OK with the full source tree.
No SQLi. No XSS. No brute force. A different number in the URL.
If you want the full picture of vibe coding in production and how widespread this pattern has become across the category, that is worth reading separately.
The Lovable Breach Timeline: 48 Days, Five API Calls, No Offensive Hacking Required
The vulnerability was not there from the beginning. Lovable had actually removed it once before.
In March 2025, Lovable deliberately removed API access to chat history and source code for public projects. By November 2025, all new projects were private by default. Then on February 3, 2026, a backend refactor reintroduced the problem. Lovable’s own words: “While unifying permissions in our backend, we accidentally re-enabled access to chats on public projects.” Their testing pipeline did not catch it.
Here is the timeline:
February 3, 2026 — backend regression introduced; BOLA access re-enabled on public projects.
February 22, 2026 — first HackerOne report filed on the regression, per Lovable’s official incident response. Closed without escalation.
March 3, 2026 — independent security researcher Matt Palmer (@weezerOSINT) filed HackerOne report #3583821. Also closed without escalation.
March 3 to April 20 — the 48-day window. A known, formally reported vulnerability sat unpatched because Lovable’s HackerOne triage partners were working from outdated internal documentation that described public project chat visibility as intended behaviour.
April 20, 2026 — Matt Palmer published his public disclosure after receiving no patch. Lovable deployed a fix within two hours.
76 days total is the actual exposure window. 48 days is the disclosure failure window. Both figures are accurate. The 48-day framing matters because it measures how long a known vulnerability went unpatched after responsible disclosure. That is the number to focus on.
What Data Was Actually Exposed — and Whose $6.6 Billion Was at Risk?
More damaging than the source code access were the credentials embedded within it.
Hardcoded Supabase credentials — SUPABASE_URL, SUPABASE_PUBLISHABLE_KEY, SUPABASE_SERVICE_ROLE_KEY — were sitting right there in the exposed source trees. Third-party API keys in .env files: Stripe, SendGrid, Anthropic, GitHub tokens. Full AI conversation histories, including every prompt typed mid-session and every architectural discussion.
Each credential is a separate attack surface. A Supabase service role key bypasses Row-Level Security and grants full database read/write access. A leaked Stripe key can issue refunds or read payment data. A GitHub token can access private repositories.
Connected Women in AI, a Danish nonprofit, had an active admin panel demonstrated as an exploitable target — records included names, job titles, and Stripe customer IDs for individuals at Accenture Denmark and Copenhagen Business School. In a separate February 2026 incident, researcher Taimur Khan found 16 vulnerabilities in a Lovable-featured EdTech application — 6 rated critical — exposing 18,697 user records including 4,538 student accounts from UC Berkeley and UC Davis. The support ticket was closed without a response.
The $6.6 billion figure refers to Lovable’s December 2025 funding valuation. This is not a hobbyist tool. Uber, Zendesk, and Deutsche Telekom built on it in good faith. The platform’s enterprise credibility is what makes the security posture consequential. Gartner forecasts that 60% of all new code will be AI-generated by end of 2026. The scale of this exposure pattern is growing, not shrinking.
For the statistical basis for why BOLA appears so reliably in AI-generated apps, the research behind the numbers goes deeper than this single incident.
The Denial Cycle: How Lovable’s Response Made a Bad Situation Worse
All four stages of Lovable’s response happened on a single afternoon. April 20, 2026.
The Register documented the evolving responses in real time and later called it “a lesson in how not to respond to vulnerability reports.”
Stage 1 — “Intentional behaviour”: Lovable’s first X post stated “We did not suffer a data breach” and described the exposed data as intentional. “When it comes to code of public projects: That is intentional behavior… the core behavior has been consistent and by design.”
Stage 2 — Documentation blame: The framing shifted. Lovable acknowledged “our documentation of what ‘public’ implies was unclear.” The behaviour was no longer intentional, but the failure had been relocated to the user’s understanding rather than the platform’s API.
Stage 3 — HackerOne blame: Lovable pointed to its bug bounty partner: reports were closed without escalation because Lovable’s HackerOne partners thought that seeing public projects’ chats was the intended behaviour. Lovable’s official blog later confirmed the reports were closed “because of outdated internal documentation we provided to the triage team” — which puts the root cause back at Lovable.
Stage 4 — Partial apology: A new X post acknowledged the earlier post “didn’t properly address our mistake.”
Deny, deflect, blame process, partially apologise. It is a recognisable pattern in platform-side security responses — one that shifts liability toward the user without addressing the technical failure. For any vendor evaluation, treat this response cycle as a data point alongside the technical findings.
CEO Anton Osika published a blog post committing to remediation: the regression was fixed, all historically public projects made private, HackerOne triage restructured, and an automated pentesting partnership with Aikido Security announced. As of publication, no independent source has confirmed completion of the in-progress items. For what platform vendors should have built to prevent this, the governance obligations are worth reading directly.
Row-Level Security Off by Default: Why Lovable Is Not the Only Platform with This Problem
The BOLA vulnerability exposed the Supabase credentials. What those credentials accessed was its own problem.
Supabase’s Row-Level Security (RLS) restricts which rows a database user can read or write. When disabled, any authenticated connection can access every row in every table. Approximately 70% of Lovable-built apps shipped with RLS disabled.
Supabase is not at fault here. RLS is available, documented, and works. The vibe coding workflow produces the misconfiguration because the AI generates a working backend without enabling the security layer, and the developer does not know to turn it on.
Bolt.new, from StackBlitz, ships with Supabase RLS disabled by default as well. The Moltbook breach in January 2026 — a vibe-coded social network breached within three days of launch — exposed 1.5 million API tokens and 35,000 email addresses through the same misconfiguration.
A Q1 2026 assessment of more than 200 vibe-coded applications found 91.5% contained at least one exploitable vulnerability — the systemic research that shows Lovable is not an outlier. More than 60% exposed API keys or database credentials in public repositories. Lovable is the named case study. Bolt.new confirms the pattern is structural. Assume the rest of the category shares it until demonstrated otherwise.
What to Do If Your Team Built on Lovable Before April 2026
Lovable’s official statement confirms private projects and Lovable Cloud were not impacted. The exposure applied to public projects between February 3 and April 20, 2026. That said, treat any project created before April 20, 2026 as potentially exposed regardless of its current privacy setting — researchers demonstrated access to projects not set as publicly shareable. Rotate credentials; verify scope later.
Step 1 — Rotate Supabase credentials. Log into the Supabase dashboard. Navigate to Project Settings > API. Regenerate the service role key and the anon key. Update all environment variables in the Lovable project and any deployment pipelines. Treat all .env secrets as burned until verified otherwise.
Step 2 — Audit Row-Level Security. In the Supabase dashboard, navigate to Authentication > Policies. Confirm RLS is enabled on every table that stores user or business data. If disabled, enable it and define policies before redeploying. If you are not sure whether RLS was enabled when the project was built, assume it was not.
Step 3 — Rotate third-party API keys. Any API key hardcoded in a Lovable-built project should be treated as compromised: Stripe restricted keys, SendGrid API keys, Anthropic API keys, GitHub personal access tokens. Regenerate rather than revoke-and-recreate where that preserves existing integrations.
Step 4 — Scan for hardcoded secrets. Use a secrets scanner such as TruffleHog or GitLeaks to review the full repository history. Secrets committed in earlier commits remain accessible even after removal from the current branch.
Step 5 — Assess downstream exposure. If Supabase credentials were hardcoded and RLS was disabled, any authenticated user during the exposure window had full database read/write access. Assess what data was in the database and whether notification obligations apply under GDPR, CCPA, or the Australian Privacy Act. Document the incident, the remediation steps, and the timeline — relevant both to regulatory response and to any contractual obligations to enterprise customers.
Before resuming deployment, ask Lovable’s security team (via their Aikido Security partnership) for confirmation that in-progress remediation items are complete.
Frequently Asked Questions
What is the difference between the 48-day and 76-day figures in the Lovable exposure?
Both figures are accurate and refer to different things. 76 days is the actual exposure window: February 3, 2026 (when the backend regression was introduced) to April 20, 2026 (when the patch was deployed). 48 days is the disclosure failure window: March 3 to April 20 — how long a formally reported, known vulnerability went unpatched after Matt Palmer filed HackerOne report #3583821.
What does “no data breach” mean if my credentials were exposed?
Lovable’s first X post stated “We did not suffer a data breach” — meaning no confirmed evidence of unauthorised exfiltration of data. A data exposure means credentials and source code were accessible. A breach implies confirmed theft. Operationally, the distinction does not change what you need to do. If credentials were accessible, rotate them.
Was Lovable’s bug bounty process at fault, or was this HackerOne’s failure?
Matt Palmer filed HackerOne report #3583821 on March 3, 2026. It was closed without escalation. Lovable’s official account states the reports were closed “because of outdated internal documentation we provided to the triage team.” HackerOne declined to comment. Regardless of where the specific breakdown occurred, 48 days between formal report and patch is a failure of the bug bounty process. Full stop.
Does this mean Supabase itself is insecure?
No. Supabase provides Row-Level Security as a documented feature. The vibe coding workflow produces RLS-off configurations because AI code generators do not enable it by default and developers building with prompts do not know to turn it on. The vulnerability is in Lovable’s API, not Supabase’s platform.
Is my Lovable project affected if it was set to “private”?
Lovable’s official statement is that private projects and Lovable Cloud were never impacted. However, researchers disputed the “public project” framing and demonstrated access to projects not set as publicly shareable. Treat any project created before April 20, 2026 as potentially exposed and rotate credentials regardless of privacy setting.
Which other vibe coding platforms have the same RLS-off-by-default problem?
Bolt.new from StackBlitz ships with Supabase RLS disabled by default. A Q1 2026 assessment found 91.5% of vibe-coded applications contained at least one exploitable vulnerability — Lovable and Bolt.new are named cases, not isolated outliers.
What did Lovable commit to fixing, and has it been verified?
Confirmed completed: the permission regression was fixed; all historically public projects were made private. In-progress as of April 20, 2026: restructuring HackerOne vulnerability triage and communicating with affected project owners. No independent source has confirmed completion of in-progress items. Request confirmation from Lovable’s security team before resuming deployment on the platform.
What legal exposure could we face if company data was accessed via the Lovable breach?
If Supabase databases contained personal data — customer records, employee data, health information, financial data — the exposure may trigger notification obligations under GDPR, CCPA, or the Australian Privacy Act. The threshold is typically “likely to result in serious harm.” Consult legal counsel and document everything.
What questions should I ask a vibe coding platform before deploying it across my team?
Does the platform enforce object-level authorisation checks on all API endpoints? What is the default Row-Level Security configuration for database integrations? Does the platform have a public security disclosure policy, a bug bounty programme, and a documented escalation process that has actually been tested? What is the platform’s most recent penetration test date and can results be shared under NDA? How does the platform handle hardcoded secrets — does it scan generated code before saving, or store credentials as plaintext in the repository?
These are the questions the Lovable incident demonstrates were not being asked loudly enough.
For the full picture of where vibe coding security stands today — across platform incidents, research findings, adversarial use, and governance frameworks — see our comprehensive vibe coding security overview.
