Lovable says chat exposure on public projects came from a permissions error, after researchers warned sensitive project data was accessible
7 min. read 
Published on
Lovable, the AI app builder platform, says it has fixed a permissions issue that exposed chat data tied to public projects after researchers and users warned that older projects could reveal sensitive information. The company first denied that it had suffered a data breach, but later apologized and said a backend permissions change in February accidentally re-enabled access to chats on public projects.
That clarification matters because early reports described the issue as a critical Broken Object Level Authorization flaw that could expose source code, credentials, AI chat histories, and customer data from projects created before November 2025. Lovable has not publicly confirmed all of those details in the same terms. Instead, its latest public statement focuses on public-project visibility, chat exposure, and a permissions mistake that it says has now been corrected.
Access content across the globe at the highest speed rate.
70% of our readers choose Private Internet Access
70% of our readers choose ExpressVPN
Browse the web from multiple devices with industry-standard security protocols.
Faster dedicated servers for specific actions (currently at summer discounts)
The practical takeaway for users is simple. If you created public projects on Lovable, especially older ones, you should review them now, rotate any secrets that may have appeared in prompts or code, and verify that no sensitive data remains inside project chats, logs, or connected services. Lovable’s own documentation already makes clear that project visibility settings affect who can view projects, and its product materials have long tied private projects to paid tiers.
What happened, based on the public record
The controversy started when security researchers and users on X claimed they could access project-related data through Lovable’s API. One reported endpoint, GetProjectMessagesOutputBody, was described as returning project message histories, tool-use records, and other sensitive content without proper access checks. That claim spread quickly across security news sites and social media, where users also alleged that real company and nonprofit data appeared in exposed projects.
Lovable’s initial response pushed back. In a public statement, the company said it had not suffered a data breach and argued that visibility of code on public projects was intentional behavior. That answer triggered criticism because it did not clearly address whether chats, internal project context, or sensitive user data had also been visible.
Later the same day, Lovable published a fuller explanation and changed tone. The company said that public projects historically exposed both code and chat, similar to how public repositories work on GitHub, but admitted that many users likely understood “public” to mean only the published app was visible. It then said it had previously patched the API to block access to public-project chats, but a February backend permissions change accidentally re-enabled that access. The company says it has now reversed that change and made public project chats private again.
Why this has become a bigger security story
Even if Lovable rejects the phrase “data breach,” the incident still raises serious questions about secure defaults, permission design, and how AI-native builders handle sensitive project context. These tools often store much more than app code. They can also hold prompts, debugging history, environment details, and conversations that include API keys, customer records, and business logic.
That is why the dispute over terminology does not change the underlying risk. If public settings, unclear product language, or a backend permissions change let unrelated users view chats or project content they should not have seen, organizations still face exposure. For companies using AI builders in production or near-production workflows, that can turn a product UX decision into a security incident very quickly.
The timeline also matters. Lovable’s later statement says free users have not been able to create public projects since May 25, 2025, and all new projects became private by default in December 2025. That suggests the greatest risk likely fell on older public projects or projects affected by the later permissions regression. Still, users should not assume that means they are safe without checking. Older prompts, copied secrets, and linked third-party services can leave long tails.
What users should do now
]Anyone who built on Lovable before its newer private-by-default changes should review project visibility first. Then they should inspect chat histories, prompts, connected Supabase instances, GitHub sync settings, and any secrets that may have been pasted into the builder during development. Lovable’s documentation confirms that users can manage visibility from project settings, and that public projects can be remixed by others in some cases.
Teams should also rotate credentials that may have appeared anywhere inside project context. That includes API keys, service tokens, database passwords, webhook secrets, and admin credentials. If personal or customer data was used during testing, it should be treated as potentially exposed until logs and connected systems are reviewed. These are standard containment steps whenever a development environment may have leaked internal context.
For organizations evaluating AI app builders more broadly, this incident is another reminder that low-code speed does not remove the need for traditional security controls. Secrets should live in dedicated secret managers, not in prompts. Test data should be sanitized. Public and private project behavior should be verified directly, not assumed from labels alone. And builders that rely on chat-based workflows need especially clear boundaries around what gets stored, exposed, and shared.
Exposure claims vs. Lovable’s public response
| Issue | What researchers and reports claimed | What Lovable publicly said |
|---|---|---|
| Nature of the flaw | Reports described a BOLA-style API issue exposing project data on older projects | Lovable said it did not suffer a “data breach” and framed code visibility on public projects as intentional at first. |
| Chat visibility | Reports said project chats and internal histories were accessible | Lovable later admitted chats on public projects were accidentally re-exposed by a backend permissions change and said it fixed that. |
| Scope | Early reporting focused on projects created before November 2025 | Lovable said public-project behavior changed over time, with free public projects disabled in May 2025 and new projects private by default from December 2025. |
| Risk to users | Reports warned about exposed code, prompts, secrets, and customer data | Lovable acknowledged a privacy-impacting issue around chats on public projects and said it reverted the access. |
Key points for developers and security teams
- Review every Lovable project that was ever set to public.
- Rotate credentials that appeared in prompts, code, or connected services.
- Audit Supabase, GitHub, and deployment integrations for unintended exposure paths.
- Treat AI builder chat logs as sensitive development records, not harmless workflow notes.
- Verify default visibility behavior yourself before using any AI builder for real customer data.
FAQ
Not in Lovable’s own public wording. The company initially denied a breach, then acknowledged a permissions mistake that re-exposed chats on public projects and said it fixed the issue.
Lovable’s public statements clearly address public-project code visibility and the mistaken re-exposure of chats on public projects. Broader claims about credentials and customer data came from researchers and media reports, not from Lovable’s formal statement.
Based on public reporting and Lovable’s own timeline, older public projects appear to have carried the highest risk, especially before newer private-by-default behavior took effect.
Check project visibility, rotate secrets, review chats and prompts, and inspect connected services such as Supabase and GitHub for anything sensitive that may have been exposed.
Read our disclosure page to find out how can you help VPNCentral sustain the editorial team Read more
Improve this guide
User forum
0 messages