I have written before about how AI vendors sometimes respond to security reports as if the real problem is the person pointing at the fire, not the fire itself. The latest Register piece on Lovable is another good example of that pattern [1].
It covers a reported security flaw in Lovable, the vibe-coding startup that has attracted a lot of attention and a lot of money. Basically, a researcher found that anyone with a free Lovable account could access sensitive data belonging to other users, including source code, database credentials, AI chat histories, and customer information [1].
Which is pretty sh*t, but also pretty standard... What makes it more interesting is the way Lovable responded.
The FUBAR
The flaw was a classic Broken Object Level Authorization issue, or BOLA [1]. In English, the API was returning data without properly validating whether the person asking for it was entitled to see it. The researcher reportedly needed only five API calls from a newly created free account to pull back exposed material [1].
This was a straightforward access control failure with obvious consequences.
Lovable's first instinct was denial
For me, the problem was not the poor handling of the issue, it was how they handled it. Companies ship poor and broken access controls all the time. It was their excuse...
Lovable's initial public response was that it had "not suffered a data breach" and that the visibility of code in public projects was intentional behaviour [1].
This is the sort of response that always reads as if legal and communications got to the keyboard before engineering or incident response did (and no, I never recommend that for award-winning public relations. Have them involved, never leading).
- First, deny the framing.
- Second, narrow the scope.
- Third, imply the researcher has misunderstood the product.
Only later, when the pressure does not go away, do they admit that something more serious may have happened after all.
1984 anyone?
Those who control the present control the past, and those who control the past control the future.
Later, Lovable changed its position [1]. The company apologised and said the earlier statement had not properly addressed the issue. It then set out a timeline which sounds more plausible and more useful than the original response:
- at one stage, marking a project as public exposed both code and chat history to viewers;
- until May 2025, free users could not create private projects at all;
- in May 2025, private projects were enabled for free users;
- in December 2025, private projects became the default for all tiers;
- in February 2026, a backend permissions consolidation accidentally re-enabled access to chat histories from public projects [1].
That explanation is far more credible than simply saying no breach took place. It at least acknowledges that permissions changed over time and that a regression may have reintroduced exposure. But it also raises an awkward question. If the situation was complicated enough to require that sort of detailed chronology, why was the first public response so absolute?
That is usually a sign that the organisation responded defensively before it understood its own facts.
Lovable's later explanation also blamed HackerOne for not escalating the report [1]. According to the company, HackerOne triage staff decided that visibility of chat histories in public projects was intended behaviour and therefore closed the submission without escalating it internally [1].
Could a triage decision have gone wrong? Certainly. That happens. But from the outside, blaming the intermediary does not answer the questions users actually care about.
The update after publication
Lovable now states that it only became aware of the issue on April 20, 2026, and that it addressed it immediately [1]. The spokesperson also said users could switch projects between public and private at any time, and that chat histories from public projects were no longer visible to other users [1]. That may well describe the current state of the platform. It does not do much to improve confidence in how the issue was first handled.
A technical failure is one thing. A credibility failure layered on top is another.
I do not think this case matters only because Lovable got something badly wrong. I think it matters because it fits a broader pattern that has been showing up across AI vendors and AI-adjacent tooling.
That is not a mature response model. It is a reputational containment model.
That is one reason the Lovable story landed so squarely with me. It does not stand on its own.
I wrote recently about the Model Context Protocol mess in my own blog post, The MCP won't let me be... Anthopic AI MCP security flaw [3]. In that case, researchers at Ox Security described a protocol-level architectural issue that they said put up to 200,000 servers and LangFlow projects at risk, with more than 150 million cumulative downloads across the ecosystem [3]. Anthropic's position, as I discussed there, was to classify the behaviour as expected and leave sanitisation as the responsibility of downstream developers [3].
This is exactly the same. Reclassify the flaw as design intent, move responsibility down the stack, and avoid owning the risk at the architectural level.
There are other examples too. In January 2026, The Register reported that Anthropic had quietly fixed three flaws in its Git MCP server which researchers said could be chained into remote code execution or file overwrite through prompt injection [4]. Quiet fixes are better than no fixes, but they are not the same thing as a transparent and accountable disclosure posture.
Then there was the April 2026 reporting on AI agents integrated with GitHub Actions. Researchers showed how those agents could be hijacked to steal API keys and tokens, while Anthropic, Google, and Microsoft had not warned users at the time of publication [5]. Again, the technical problem was serious. The public response posture was serious too.
Even Lovable had already shown up in similar reporting earlier this year. In February 2026, The Register covered a case involving a Lovable-hosted application that allegedly exposed around 18,000 users and contained basic security flaws [6]. That earlier piece asked a question that is relevant again here. How much security responsibility belongs to the platform, and how much can realistically be pushed onto end users?
The answer is simple enough. If you build a platform that encourages rapid application generation and handles other people's code and data, you do not get to shrug when predictable access control and configuration failures occur. That responsibility does not disappear just because the product is marketed as easy, creative, or AI-assisted.
Be clear, be honest, be transparent.
References
[1] J. Lyons, "Vibe coding upstart Lovable denies data leak, cites 'intentional behavior,' then throws HackerOne under the bus," The Register, Apr. 20, 2026. [Online]. Available: https://www.theregister.com/2026/04/20/lovable_denies_data_leak/
[2] J. Lyons, "AI vendors' response to security flaws: It wasn't me," The Register, Apr. 19, 2026. [Online]. Available: https://www.theregister.com/2026/04/19/ai_vendors_response_to_security/
[3] K. Niĉolas, "The MCP won't let me be... Anthopic AI MCP security flaw," Kieren Niĉolas Blog, Apr. 19, 2026. [Online]. Available: https://www.kierennicolas.com/blog/the-mcp-wont-let-me-be-anthopic-ai-mcp-security-flaw
[4] J. Lyons, "Anthropic quietly fixed flaws in its Git MCP server that allowed for remote code execution," The Register, Jan. 20, 2026. [Online]. Available: https://www.theregister.com/2026/01/20/anthropic_prompt_injection_flaws/
[5] The Register, "Agents hooked into GitHub can steal creds, but Anthropic, Google, and Microsoft haven't warned users," Apr. 15, 2026. [Online]. Available: https://www.theregister.com/2026/04/15/claude_gemini_copilot_agents_hijacked/
[6] C. Jones, "Lovable-hosted app littered with basic flaws exposed 18K users, researcher claims," The Register, Feb. 27, 2026. [Online]. Available: https://www.theregister.com/2026/02/27/lovable_app_vulnerabilities/