Full Report
A lesson in how not to respond to vulnerability reports Vibe-coding platform Lovable is pooh-poohing a researcher’s finding that anyone could open a free account on the service and read other users' sensitive info, including credentials, chat history, and source code. However, the company’s story keeps changing: First it attributed the publicly exposed info to "intentional behavior" and "unclear documentation," then threw bug-bounty service HackerOne under the bus.…
Analysis Summary
# Incident Report: Lovable BOLA Vulnerability and Data Exposure
## Executive Summary
Vibe-coding platform Lovable experienced a significant data exposure event caused by a Broken Object Level Authorization (BOLA) vulnerability and conflicting project visibility settings. The incident allowed any user with a free account to access other users' sensitive information, including source code, database credentials, and AI chat histories. Despite an initial report via a bug bounty program, the vulnerability remained open for 48 days due to miscommunication between Lovable and its triage partner, HackerOne.
## Incident Details
- **Discovery Date:** March 3, 2026 (Initial report)
- **Incident Date:** February 2026 – April 2026
- **Affected Organization:** Lovable (Lovable.dev)
- **Sector:** Artificial Intelligence / Software Development
- **Geography:** Global
## Timeline of Events
### Initial Access
- **Date/Time:** March 3, 2026 (Reported by @weezerOSINT)
- **Vector:** Broken Object Level Authorization (BOLA) via API calls.
- **Details:** A researcher registered a free account and discovered that API endpoints lacked sufficient ownership validation, allowing access to resources belonging to other users.
### Lateral Movement
- **Details:** Not applicable in the traditional sense; however, the attacker (researcher) moved from a standard free account profile to accessing third-party project repositories and backend configurations via unprotected API calls.
### Data Exfiltration/Impact
- **Details:** Exposure of source code, developer chat histories, database credentials, and customer PII (Personally Identifiable Information) contained within project chats for every project created before November 2025.
### Detection & Response
- **March 3, 2026:** Researcher submits bug report via HackerOne.
- **Mid-March 2026:** HackerOne/Lovable closes report as "Duplicate" or "Intended Behavior," failing to escalate.
- **April 20, 2026:** Researcher goes public on X (formerly Twitter) after 48 days of inaction.
- **April 20, 2026 (Morning):** Lovable denies breach, claiming "intentional behavior" and "unclear documentation."
- **April 20, 2026 (Evening):** Lovable admits to a backend regression that re-enabled access to private chats and reverts the API change.
## Attack Methodology
- **Initial Access:** Legitimate account creation (Free Tier).
- **Persistence:** Not required; vulnerability was persistent in the API logic.
- **Privilege Escalation:** Exploiting BOLA to gain access to data typically restricted to project owners or Enterprise users.
- **Credential Access:** Extraction of database credentials stored in plaintext within source code or AI chat logs.
- **Discovery:** Five API calls to enumerate and access public/private project data.
- **Collection:** Manual or scripted gathering of chat histories and source code.
- **Exfiltration:** Standard HTTPS API responses.
- **Impact:** Data leak of sensitive intellectual property and credentials.
## Impact Assessment
- **Financial:** Potential loss of valuation; legal/compliance risks regarding exposed customer data.
- **Data Breach:** High. Exposure of credentials, source code, and AI prompts across all tiers.
- **Operational:** Temporary suspension of public project features; emergency backend patching.
- **Reputational:** High. Critical failure in the vulnerability disclosure process and inconsistent public PR messaging.
## Indicators of Compromise
- **Behavioral indicators:** Unusual volume of API requests to `lovable[.]dev` project endpoints from free-tier accounts targeting non-owned project IDs.
## Response Actions
- **Containment:** Retroactively patched the API to ensure project chats remained private regardless of project status.
- **Eradication:** Reverted a backend permission unification change from February that had introduced the regression.
- **Recovery:** Disabled the ability for Enterprise customers to set projects to "Public."
## Lessons Learned
- **Regression Testing:** Significant security vulnerabilities were introduced during "backend unification," indicating a lack of regression testing for security-critical permissions.
- **Vulnerability Disclosure Maturity:** Closing a high-severity report as "intended behavior" without deep technical review led to a public PR crisis.
- **Documentation as Defense:** Relying on "unclear documentation" as a defense for data exposure is insufficient; security should be "secure by default" (e.g., private-by-default logic).
## Recommendations
- **API Security:** Implement strict Object Level Authorization checks for all API endpoints.
- **Bounty Oversight:** Improve the triage process between internal security teams and external partners (HackerOne) to ensure critical reports are not dismissed.
- **Secret Management:** Implement secret scanning to prevent users from including database credentials in source code/chats, as these may be exposed if a project is marked public.