On 20 April 2026, a security researcher posted that any free account on Lovable — the AI coding platform valued at $6.6 billion — could access another user's source code, database credentials, AI chat histories, and live customer data. The vulnerability had been reported 76 days earlier and was never properly escalated.
Within 24 hours, the coverage framed it as a vibe coding security crisis. The framing is understandable. It is also imprecise. And the imprecision matters, because it points to the wrong solution.
What the vulnerability actually was
The flaw was a Broken Object Level Authorisation vulnerability — BOLA. Ranked #1 in the OWASP API Security Top 10. The API checked whether a user was authenticated. It did not check whether that authenticated user had permission to access the specific resource being requested. Five API calls from a free account was enough to retrieve another user's full project.
BOLA is not exotic. It is the most prevalent API security failure in production systems globally — which is exactly why OWASP ranks it first. It appears consistently in manual penetration tests, automated scans, and incident disclosures. What made the Lovable case notable was the scale: every project created before November 2025 was potentially affected. And the timeline: a backend permissions change on February 3rd accidentally re-enabled access to public project chats, researchers reported it on February 22nd and March 3rd, both reports were closed without escalation, and the vulnerability remained open until public disclosure on April 20th.
Why this keeps happening
The vibe coding framing suggests the problem is AI generating insecure code. That is part of it — between 40% and 62% of AI-generated code contains security vulnerabilities depending on the study, and Georgia Tech tracked 35 CVEs attributed to AI coding tools in March 2026 alone. But the Lovable platform-level vulnerability was not in the generated code. It was in the platform's own API authorisation layer.
The deeper pattern — the one that connects the platform incident to the generated code incidents — is the same in both cases: there is no systematic verification that the code enforces what the product is supposed to do.
When an AI generates a full-stack application from a natural language prompt, it optimises for functional correctness. The app loads. The data displays. The user flow works. What the AI does not do is reason about your threat model. It does not check whether the access control logic it generated matches the ownership boundaries you intended. It does not verify that the authentication function it wrote actually blocks what it is supposed to block. One of the Lovable incidents from February 2026 involved exactly that failure — inverted authentication logic that granted anonymous users full access while blocking authenticated ones. The intent was to restrict access. The implementation did the opposite. The code ran without errors.
The verification layer that does not exist yet
Every major AI coding platform generates code. None of them systematically verify that what was generated enforces what the product was designed to do.
This is the gap. Not the code quality gap — there are SAST tools for that. Not the dependency vulnerability gap — there are SCA tools for that. The gap between stated product intent and actual code behaviour — the question of whether the system you described is the system that was built — has no systematic answer in the current tooling landscape.
That is the gap I have spent the last year building IntentGuard to close. It is an automated code audit platform that reads your stated product intent against your actual codebase and produces structured findings — with file paths, line references, and framework control mappings — on every place where the two diverge. It maps against 16 compliance frameworks including OWASP API Top 10 on every audit. BOLA is covered. Not because of the Lovable incident — it was covered before I read this story. It is covered because BOLA is #1 on OWASP API Top 10, which means it belongs in every serious compliance audit of every API-facing codebase.
What you should do right now
If you have projects on any vibe-coded platform created before late 2025:
Rotate every API key and database credential. Do not wait to confirm whether you were specifically affected — assume you were and rotate now. The cost of rotating credentials you did not need to rotate is low. The cost of not rotating credentials that were exposed is not.
Audit your Supabase row-level security. The majority of vibe-coded platforms provision Supabase backends with RLS disabled. If you have a Supabase project connected to a Lovable, Bolt.new, or similar app, check whether RLS is enabled on every table that stores user data. The Supabase dashboard shows this per table.
Scan for hardcoded secrets in your source code. Tools like GitGuardian, Gitleaks, or TruffleHog will run against your repository and flag credentials embedded in code. This takes less than ten minutes to set up.
For every API endpoint that returns or modifies user-specific data: write a test that authenticates as User A, requests a resource belonging to User B, and verifies the response is a 403. This is the single most effective test for BOLA and it is the one that most vibe-coded applications skip entirely.
The broader point
The Lovable incident is one data point in a consistent trend. The trend is that code is being generated and shipped at a rate that human review cannot match, into production systems that handle real user data, without any systematic verification that the code enforces what the product was designed to do.
That is a solvable problem. The solution is not to slow down AI-assisted development — that ship has sailed. The solution is to build the verification layer that currently does not exist.
IntentGuard is in final pre-launch hardening. Waitlist at intentguard.dev if this is directly relevant to what you are building.
Top comments (0)