What do you do when a security researcher says anyone can open a free account on your coding platform and read other users’ credentials, chat history and source code — and your explanation keeps changing? That is the dilemma facing Lovable, a "vibe-coding" platform, after a researcher published a finding about broadly exposed user data and the company responded in ways that the researcher and outside observers have flagged as evasive.
The researcher’s finding
According to reporting, a researcher found that anyone who created a free account on Lovable could access other users’ sensitive information. The reporter summarizes the exposed material as including credentials, chat history and source code. The researcher’s finding prompted scrutiny of how the platform handles access controls and user data.
Lovable’s shifting explanations
Lovable has disputed the characterisation of the event as a straightforward leak. The company initially pointed to what it called "intentional behavior" and "unclear documentation" to explain why information appeared publicly accessible. The company subsequently changed its explanation and placed blame on bug-bounty platform HackerOne, according to the same report. Observers in the article describe Lovable’s public posture as "pooh-poohing" the researcher’s discovery.
Why this matters
- For technologists: A report that free accounts could access others’ credentials, chats and source code raises immediate questions about authentication, authorization and data segregation controls. Even without independent verification in this summary, the described failure modes are the kinds of issues security teams try to catch early.
- For users: If true, the finding represents a potential exposure of account secrets and private communications — the very kinds of assets users rely on platforms to protect.
- For platform operators and bug-bounty programs: The episode illustrates reputational and operational risks when vulnerability reports and their handling are public. The account of Lovable first attributing exposure to internal choices and documentation, then blaming a third-party bug-bounty facilitator, highlights how response narratives can themselves become the story.
- For adversaries: Public descriptions of possible access paths can either invite exploitation or accelerate fixes, depending on how quickly and transparently a vendor responds.
Conclusion
Lovable’s reported back-and-forth — from dismissing the finding to blaming documentation and a bug-bounty provider — underscores a simple truth: the credibility of a security response depends not only on technical fixes but on consistent, transparent communication. When explanations change, stakeholders are left to weigh messy signals: the researcher’s claim of broad exposure on one hand, and a company’s shifting accounts on the other. Which side wins that credibility contest will shape whether users feel safe, researchers keep reporting, and platform operators learn fast enough to prevent the next incident.
