A security researcher filed a HackerOne report against Lovable, the $6.6bn vibe-coding platform, on 3 March 2026. Lovable closed it without escalation, citing “outdated internal documentation” given to the triage team. The underlying flaw — a Broken Object Level Authorisation (BOLA) bug in Lovable’s API — meant anyone with a free account could read another user’s source code, database credentials, AI chat history and customer data with as few as five API calls. It affected every project built on the platform before November 2025 and stayed exploitable for 48 days after the report was first filed.
This is the third documented security incident tied to Lovable, and it lands alongside a wider pattern: researchers have found comparable authorisation failures across other vibe-coding platforms this year, including a platform-wide authentication bypass on Base44 and a zero-click remote-code-execution bug on Orchids. Industry-wide testing puts the rate of AI-generated code shipping with at least one security flaw at 40–62%, and one 2026 study found 91.5% of vibe-coded apps had at least one hallucination-related flaw.
The structural problem, not just the bug
What makes the Lovable case worth flagging isn’t the vulnerability class — BOLA bugs are common and well understood — it’s the disclosure failure. Lovable had no audit trail to detect that a closed, “fixed” report was still being actively exploitable, and no process that could catch the gap once the bug bounty channel had already failed once. That’s a governance problem, not a coding problem, and it’s specific to platforms where a huge number of independently built apps share one underlying authorisation layer: a single missed fix doesn’t affect one product, it potentially affects every project the platform has ever hosted.
So what
If you or your team have built anything commercially important on a no-code or AI app-builder platform, this is worth an honest audit: what happens to your product, your users’ data, and your reputation if the platform’s shared infrastructure has a flaw like this one — and how would you even find out? It’s a fair question to put to any platform vendor, and a fair reason to move a product from prototype to a properly engineered, independently reviewed codebase once it’s carrying real user data or real revenue. Our custom software development work is built for exactly that transition — get in touch if you’re weighing whether your product has outgrown its builder.