Lovable Data Leak: BOLA Vulnerability and App Security Risks

The BOLA vulnerability in the Lovable code was the result of an accidental regression in how the project managed permissions. In the past, all free-tier account data was publicly accessible, including code, data, and chats with the Lovable API. In December 2025, projects were made private by default, and the Lovable API was patched to make chats private for public projects created before that date.

In February 2026, an update to Lovable’s permission management backend accidentally re-enabled access to chats for public projects. This issue was identified and ethically reported to Lovable, which patched it for new projects but not existing ones. However, existing project chats remained open, prompting a second bug bounty report that was marked and closed as a duplicate.

This issue was initially described as “intentional behavior” by Lovable. Later, the company blamed its own documentation for the issue. Next, it blamed HackerOne, the company that managed the bug bounty and closed both reports without escalation while believing that public project chats were intentional. Finally, the company issued a public apology for the issue, acknowledging that pointing to documentation issues wasn’t enough.

The Lovable incident only affected public projects. All free-tier projects created after December 2025 were unaffected since these are made private by default. Similarly, enterprise apps created after Lovable removed the option for public apps at this tier are safe, while previous public projects may have been impacted.

For public projects, source code, data, and the app are intended to be public, while chats with the project’s AI are private (after December 2025). Making this chat history public could leak several types of sensitive data, including:

• Shared Secrets: The Lovable chat is where users describe their intended application for the AI to build and where they debug errors. As part of the debugging process, users may paste error logs, API keys, login credentials, and other secrets that could be extracted from chats once they were made public.
• Business Logic: In addition to secrets, the chat history contains the underlying logic of an application. A founder developing a new application will describe exactly what they want it to do, including their complete business plan. Insight into business plans, marketing strategy, etc., can be extremely valuable to potential competitors.
• Personally Identifiable Information (PII): When building an application, a user might provide samples of database records or other information to help the tool build the database. Since these chats are believed to be private, this might include real PII that would be exposed when chat histories are made public.
• Business Data: Beyond a particular app’s logic, a vibe coder might also reveal other information about their business, such as its name, infrastructure, customer volume, etc. This provides an in-depth profile of the business that could be used by competitors or an attacker planning a social engineering attack.

As a “public” project, a certain amount of information is expected to be freely available for these projects. However, users who expect their chat histories to be private could be revealing a great deal of highly sensitive information.

This incident also highlighted the fact that many Lovable users may have misunderstood what it meant for their projects to be “public.” Often, this was interpreted as meaning that other users would have access to the application itself. Since many users are non-technical, they might not have realized that public projects provide access to the project’s source code and data as well.

Public source code and data are an intentional feature according to Lovable; however, it introduces significant security risks, such as:

• Vulnerability Detection: With access to the source code, an attacker can more easily look for vulnerable code or business logic. If vulnerable apps are released in production, then they can be exploited to steal sensitive data or money.
• Credential Leaks: Some Lovable-coded apps may include hardcoded API keys to provide access to various services. Access to these codebases allows attackers to extract credentials for unauthorized access to users’ accounts on these services.
• PII Exposure: Some Lovable users may have provided real data to the app or embedded database credentials within their code. This could allow an attacker to access the databases in question and extract PII.

Prior to December 2025, all free-tier projects were public by default, and free users could only make public projects before May 2025. Since many of the tool’s users are non-technical — the platform is designed to vibe-code apps — they may have been revealing more information than they intended on these public plans even before the chat history leak.

Vibe coding is already notoriously dangerous due to the potential for AI hallucinations. If an LLM introduces vulnerabilities or design logic errors into the code, non-technical users are unlikely to notice, call out, and fix the issues. Additionally, the bloated codebases of many vibe-coded apps mean that even technical users don’t review every line of code that they receive, leading to vulnerabilities slipping in through the cracks.

The Lovable leak of chat histories and the fact that code/data are public on older free projects exacerbates this risk. Users who created apps before December 2025 may expose their source code and app data to attackers for vulnerability analysis, credential extraction, and PII collection.

Vibe coding is a valuable tool, but it must be paired with software security best practices, such as security by design and pre-release code audits. For help with ensuring that your application is designed in accordance with security best practices and reviewed for exploitable vulnerabilities before deployment, get in touch with Halborn.