Vibe coding upstart Lovable denies data leak, cites 'intentional behavior,' then throws HackerOne under the bus

A lesson in how not to respond to vulnerability reports
UPDATED 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.

The drama appears to be the latest example of an AI firm, in this case a startup that claims a $6.6 billion valuation , shirking responsibility for security flaws in its products.

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

"Lovable has a mass data breach affecting every project created before November 2025," a researcher who goes by @weezerOSINT on X posted on Monday.

"I made a Lovable account today and was able to access another user's source code, database credentials, AI chat histories, and customer data are all readable by any free account."
The researcher said they reported the flaw 48 days ago, and that HackerOne labeled it a "duplicate submission," and left it open.

The researcher then sent a bug report to HackerOne, and screen shots show a March 3 submission date.

Subsequent posts show the AI leaking secrets and personal data in chats.

The leak 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.

According to the bug hunter, no offensive hacking is needed to trigger the bug.

They say they made five API calls from a free account and gained access to another user's profile, their public projects, and source code, and then extracted database credentials from the source code.

In X posts later on Monday the AI coding company first said it was "made aware of concerns regarding the visibility of chat messages and code on Lovable projects with public visibility settings," and added: "To be clear: We did not suffer a data breach."
The company then went on to blame its documentation – specifically "our documentation of what 'public' implies was unclear, and that's a failure on us." It also noted that chat messages for public projects "used to be visible," but that is no longer the case.

And then it offered this head-scratching message about intentionally making prompts and source code visible:
When it comes to code of public projects: That is intentional behavior.

We have experimented with different UX for how the build history is surfaced on public projects, but the core behavior has been consistent and by design.

So it's by design – unless you're an enterprise customer, that is.

For this group of users, "being able to set visibility to public for new projects has been disabled since May 25, 2025."
Later on Monday, Lovable issued a new statement on X, apologizing that its earlier post "didn't properly address our mistake," explaining how it got into this public-versus-private-project mess in the first place, and then blaming its bug bounty partner, HackerOne, for its failure to fix the flaw.

Users, the startup said, can select a "public" or "private" option for projects.

"A public project meant the entire project was public, both chat and code," Lovable explained.

"Over time, we realized this was confusing.

Many users thought 'public' just meant others could see their published app, not the chat of an unpublished project.

That's reasonable."
Early free-tier users didn't get an option to create private projects.

They had to upgrade to a paid plan if they wanted to do that – until May 2025, when Lovable started letting free-tier users make private projects, and disabled the public setting for enterprise customers altogether.

In December 2025, the company switched to private by default across all tiers.

"We also retroactively patched our API so public project chats couldn't be accessed, no matter what," according to the company’s mea culpa.

"Unfortunately, in February, while unifying permissions in our backend, we accidentally re-enabled access to chats on public projects."
This was the security issue that WeezerOSINT reported Lovable via HackerOne.

Chaos ensued.

"Unfortunately, the reports were closed without escalation because our HackerOne partners thought that seeing public projects' chats was the intended behaviour," Lovable wrote.

"Upon learning this, we immediately reverted the change to make all public projects' chats private again."
Lovable noted it appreciates the researchers who uncovered this mess.

"We understand that pointing to documentation issues alone was not enough here," it said.

"We'll do better." ®
A Loveable spokesperson has been in touch, and told The Register that the company wasn’t aware of the issue until Monday, and “we addressed it as soon as we learned about it.”
“This was originally reported through our vulnerability disclosure program (via HackerOne),” the spokesperson added.

“Unfortunately, the reports were closed without escalation to our internal team because our HackerOne partners thought that seeing public projects’ chats was the intended behavior, as was the case historically.”
The spokesperson clarified that any user could have changed their project from public to private at any time.

“ And chats from public projects are no longer visible - for anyone,” they added.