Lovable denies data breach after researcher exposes user data through simple API calls

Lovable Security Vulnerability Exposes Sensitive User Information

A security vulnerability in Lovable, the Stockholm-based vibe-coding platform valued at $6.6 billion, allowed users with free accounts to access sensitive information belonging to other users, including source code, database credentials, AI chat histories, and customer data 1

1

. Researcher @weezerOSINT revealed on Monday that accessing this user data exposed required only five API calls from a free account, with no offensive hacking techniques needed 2

2

. The researcher reported finding that "Lovable has a mass data breach affecting every project created before November 2025," though Lovable denies data breach claims 1

1

.

Broken Object Level Authorization at the Heart of Data Exposure

The data exposure stems from a Broken Object Level Authorization (BOLA) vulnerability, which occurs when an API exposes endpoints that allow users to access or modify sensitive data belonging to other users due to missing ownership validation 1

1

. The researcher demonstrated that making a Lovable account and conducting simple research using xAI's Grok 4.2 model took just 30 minutes, a task that would have taken hours or days before AI tools became available 2

2

. Companies including Uber, Zendesk, and Deutsche Telekom all use Lovable's vibe coding AI tool, according to its latest funding announcement 1

1

.

Shifting Explanations and HackerOne Blame

Lovable's response to the security vulnerability has evolved significantly since the issue became public. Initially, the AI firm attributed the publicly exposed information to "intentional behavior" and unclear documentation, claiming that chat messages and code visibility in public projects was by design 1

1

. The company then shifted blame to its bug bounty partner HackerOne, stating that reports were "closed without escalation because our HackerOne partners thought that seeing public projects' chats was the intended behaviour" 1

1

. The researcher had reported the flaw 48 days before going public, with HackerOne submission records showing a March 3 date, but Lovable labeled it a "duplicate submission" and left it open 1

1

.

Evolution of Public Project Settings and Chat Visibility Settings

Lovable explained that users could initially select either "public" or "private" options for projects, with public projects making both chat and code visible to anyone 3

3

. The company realized over time that many users interpreted "public" differently, assuming it applied only to published apps rather than underlying chats or development data 3

3

. Early free-tier users had no option to create private projects and had to upgrade to paid plans for privacy features until May 2025, when Lovable started letting free-tier users make private projects 1

1

. For enterprise customers, the ability to set visibility to public for new projects has been disabled since May 25, 2025 .

Technical Error Reopened Access to Chat Data

In December 2025, Lovable made all projects private by default across all tiers and "retroactively patched our API so public project chats couldn't be accessed, no matter what" 1

1

. However, in February, while unifying permissions in the backend, the company accidentally re-enabled access to chats on public projects 1

1

. This technical error was what @weezerOSINT reported via the bug bounty program. Lovable acknowledged in its apology that its earlier communication "didn't properly address" the problem, clarifying that the issue was not a Lovable data breach but "a mix of unclear product design and a technical error" 3

3

.

Implications for AI Firm Accountability

The incident represents another example of an AI firm shirking responsibility for security flaws in its products, raising questions about accountability standards in the rapidly growing AI development tools sector 1

1

. Founded in 2023, Lovable raised $330 million in December at a $6.6 billion valuation, making the security vulnerability particularly concerning given the platform's scale and enterprise client base 4

4

. The company's shifting narrative—from claiming intentional behavior to blaming unclear documentation to pointing fingers at HackerOne—highlights challenges in how startups handle security disclosures. Lovable stated it has now reversed the change and ensured that chats in public projects are no longer accessible, adding "We understand that pointing to documentation issues alone was not enough here. We'll do better" 3

3

. HackerOne declined immediate comment, stating they need to review details carefully before responding 1

1

.