Vibe Coding Security: What the Lovable Breach Taught the Industry

On the evening of April 20, 2026 a security researcher posting under the handle weezerOSINT published a thread showing that any free Lovable account, in five API calls, could read another tenant's source code, database credentials, AI chat history, and end-user data. The first public response from Lovable called the exposure intentional behaviour and blamed the documentation. The second response blamed HackerOne. The third response, hours later, conceded that the first two had been dismissive and shipped a fix inside a two-hour window. By then the story was no longer about a single endpoint on a single platform. It was about the way every vibe coding tool currently in market produces authentication, the way every triage pipeline currently in market routes security reports, and the way every founder who has ever typed "build me an app with login" inherits a set of structural vulnerabilities they cannot see. This article walks through what actually happened, why it was inevitable, and the handful of things every vibe-coded application has to do to avoid becoming the next headline.

What actually happened at Lovable between February and April 2026

The vulnerability at the centre of the disclosure is a Broken Object Level Authorization flaw, usually shortened to BOLA and listed by OWASP as the most common API weakness in production systems. BOLA happens when an endpoint accepts an identifier from the client, looks up the object with that identifier, and returns it without first checking that the authenticated user has any right to see it. In Lovable's case the endpoint in question, api.lovable.dev/GetProjectMessagesOutputBody, returned full project message histories, AI reasoning traces, tool-use records, and the source code the platform had generated for the project, keyed only by project identifier and with no ownership predicate on the query. A signed-in user could iterate identifiers and read any project ever created before November 2025.

The exposure was not a single oversight at launch. Lovable had shipped ownership checks for new projects during 2025, precisely because the company understood the risk. Then in early February 2026 an internal refactor that the team described as a permissions unification re-enabled public visibility of chat histories and source for every legacy project, silently reverting a prior fix. The regression held from February 3 to April 20, a seventy-six day window during which anyone with a free account could exfiltrate data the platform had nominally promised to isolate. Valid researcher reports arrived on HackerOne starting February 22 and were closed without escalation because Lovable's own triage documentation described public-chat visibility as intended. A separate BOLA report filed on March 3 was marked Informative, then a follow-up report was marked a duplicate and closed. The clock from that first BOLA report to public disclosure reads forty-eight days. During those forty-eight days the vulnerability remained exploitable, the reporters remained ignored, and the internal escalation path that should have routed the report from a triager to a security engineer did not exist in any operational form.

Affected projects include Connected Women in AI, a nonprofit that had a Supabase service role key embedded in its generated source code, which in turn opened up the backing database to anyone who read the source. Accounts tied to Nvidia, Microsoft, Uber, and Spotify employees appeared in the exposed corpus. Lovable has since admitted, in a follow-up post, that it broke its own fix during an intermediate deploy, extending the exposure window further than the initial disclosure implied.

The Moltbook leak three months earlier was the same story

Lovable was not the first signal. In January 2026 an AI social network called Moltbook, built end to end on Lovable by a founder who has publicly stated he did not write a single line of code, leaked 1.5 million API authentication tokens belonging to OpenAI and Anthropic customers, along with thirty-five thousand email addresses and private agent-to-agent messages. The cause was a Supabase database with row-level security disabled and public read and write access enabled by default. The breach landed inside three days of launch. Wiz, the cloud security firm that first documented the incident, framed it as a vibe coding cautionary tale. At the time most readers treated it as a one-off story about a non-technical founder who skipped a checkbox. Three months later, with Lovable itself as the platform bleeding, it became clear that Moltbook was not an exception. It was a preview.

A Q1 2026 assessment of more than two hundred vibe-coded applications found that ninety-one and a half percent contained at least one vulnerability traceable to AI hallucination. More than sixty percent exposed API keys or database credentials in public repositories. A large-scale GitHub study filed on arXiv as paper 2510.26103 found that between forty and sixty-two percent of AI-generated code contains security vulnerabilities depending on the measurement method, and that AI-written code produces flaws at roughly two point seven times the rate of human-written code. The ProjectDiscovery 2026 AI Coding Impact Report documented that engineering velocity has accelerated while security team headcount has not, with forty-nine percent of respondents attributing most of their acceleration to AI-assisted coding. The numbers describe a category, not a company.

The structural cause the headlines keep missing

Read enough incident reports and a shape emerges. The bug at Lovable was BOLA. The bug at Moltbook was disabled row-level security. The bug at the next platform will be something else. But the mechanism that produces each bug is the same three-part failure, and understanding it is the only way to stop treating each disclosure as surprising.

The first part is that large language models infer authentication from the prompt. When a founder writes "build me a task app where users can log in and save their own tasks," the model generates what looks like a complete auth surface. It adds a login page, a register page, a session cookie, a user table, and a tasks table with a user_id column. What it almost never adds, unless the prompt specifically demands it, is the enforcement layer that ties the two tables together on every read. The Supabase row-level security policy that says a user may select only tasks where auth.uid() equals user_id is missing. The API route that filters by the authenticated caller is missing. The front end looks correct, the database schema looks correct, and the only thing wrong is invisible. A user with any valid session can query any row. This is not a bug in the model in the usual sense. It is a predictable consequence of training on corpora where authentication is usually described in words and rarely enforced at the row level in the same file. The model completes the pattern it has seen most often, which is the pattern of a happy-path tutorial.

The second part is that platform regressions rewrite the security posture of applications the builder has not touched. Lovable's unification of permissions in February 2026 re-exposed every project created before November 2025. No vibe coder shipped a new build. No prompt changed. The security state of their application shifted because the platform shifted underneath it. Any AI tool that abstracts infrastructure this way inherits the same failure mode, because the builder has no diff to review and no staging environment to smoke-test. The platform is both the operating system and the security boundary, and when the platform regresses the application regresses with it.

The third part is that bug reports do not escalate. This is the failure that matters most in the Lovable case and the one that generalises most cleanly. Lovable's triage team received at least three valid reports through HackerOne before public disclosure. Every one of them was closed against an internal document that treated the behaviour as intended. The triager was not wrong according to the playbook they had. The playbook was wrong. There was no mechanism that allowed a report about visible chat histories to climb from a product decision into a security review, because the organisation had not separated product decisions from security decisions. The same pattern produces every well-known incident where a company "knew about the bug for months." Knowledge that sits in a ticket queue without an escalation path is indistinguishable from ignorance.

Stack these three parts and the pattern is complete. The model ships auth that looks right. The platform ships defaults that are not right. The disclosure pipeline does not escalate. Every AI tool in the vibe coding category fits this shape. The next incident will look different in the specifics and identical in the anatomy.

Why every vibe-coded application inherits this risk profile

A founder building on v0, Bolt, Replit Agent, Cursor Composer, or any comparable tool is depending on two compounding inferences. The tool infers how auth should work from the prompt. The builder infers that the tool has done the inference correctly because the login screen appears and the test user can log in. Neither inference interrogates the actual enforcement layer. The result is a population of applications where the shape of security is present and the substance is absent.

This is visible in the field right now. Researchers poking at randomly sampled Lovable and Bolt deployments routinely find exposed service-role keys in client bundles, Supabase instances with row-level security disabled, webhook endpoints with no signature verification, and admin routes that are reachable with any authenticated session rather than an authenticated session belonging to an admin. These are not exotic findings. They are the same five or six categories repeating across every platform, because the same three-part failure produces them.

The risk profile also concentrates at the worst possible moment, which is the moment the application starts to grow. A Lovable or Bolt app that nobody uses is not exploited. A Lovable or Bolt app that starts to trend on Product Hunt becomes a target within hours. The category that rewards shipping fast is the category that rewards exploiting fast, and the researcher who finds a hole in a ten-thousand-user app can publish a thread that reaches the founder before the founder reaches production logs.

The lessons every vibe coder has to absorb this week

A mandatory audit layer is the first lesson, because everything else depends on it. Before a vibe-coded application reaches production it needs a human developer to read the generated code with security as the single evaluation criterion. That review has to cover the row-level security policies on every table, the scope of every service-role key and where it is referenced, the list of public versus authenticated endpoints, the tenant isolation predicate on every list query, and the presence of any secret inside the client bundle. This review takes a competent backend engineer somewhere between three and eight hours for a typical Lovable project and catches the overwhelming majority of the failure modes described above. It is the cheapest intervention available and the one most founders skip.

The second lesson is a disclosure surface. Every vibe-coded application should publish a security.txt file at /.well-known/security.txt listing a contact address, a preferred language, and a public commitment to acknowledge reports inside forty-eight hours. The file itself is five lines and takes ten minutes to deploy. It does two things that matter disproportionately to its cost. It tells friendly researchers where to send a report before they publish, which is the single biggest determinant of whether a disclosure becomes a Twitter thread or a patched bug. And it signals to the rest of the industry that the application has an owner who expects reports and knows how to handle them. The absence of a security.txt is itself a signal, and researchers who find something on an application without one are substantially more likely to publish rather than email.

The third lesson is an actual bug bounty or disclosure program, even at a small scale. HackerOne and Bugcrowd both offer free or low-cost self-serve tiers, and the presence of a program with clear scope and a credible triage commitment routes reports into a workflow where they cannot be silently closed. The failure mode at Lovable was not that reports arrived. It was that reports arrived and there was no path from triage to a security owner. A bounty program forces the construction of that path as a condition of operating.

The fourth lesson is that platform regressions are the vibe coder's problem, not the platform's. Subscribe to the changelog of whatever tool generated the application. Re-run a short suite of authentication tests after every platform update, including a test where an account with one user's credentials attempts to read a second user's data. The test takes five minutes to run if it is scripted and never finishes if it is manual. Script it. Run it on a schedule. The Lovable February regression would have shown up on any such test inside forty-eight hours rather than seventy-six days.

The fifth lesson, which reaches past individual applications, is that the vibe coding category now requires the same posture the SaaS category required in 2013 when the first wave of Heroku apps started leaking credentials through exposed environment endpoints. A shared baseline of practice has to emerge. Platforms need secure defaults, which means row-level security on by default, service-role keys never reachable from client code, and permissions unifications shipped behind a documented migration. Builders need an audit layer they cannot skip. Researchers need disclosure surfaces they can reach. The incidents will keep happening until each side of the triangle raises its floor.

Where WitsCode fits in the vibe-coded audit workflow

WitsCode runs a fixed-scope audit engagement for teams that have built on Lovable, Bolt, v0, Replit Agent, or a comparable tool and want a human developer to read the generated code before they scale. The engagement covers the row-level security policies, the key scope and secrets hygiene, the tenant isolation predicates, the BOLA exposure on every list endpoint, the CORS and webhook signature posture, and the public versus authenticated surface map. It ends with a security.txt published on the production domain, a disclosure workflow wired into an inbox that a human reads, and a short scripted test suite that will catch the next platform regression inside hours rather than months. If the Lovable timeline taught the industry anything, it is that the gap between a vibe-coded prototype and a production application is a security gap, and that gap closes only when a human reads the code. That is the work. Send the project and a description of the stack to the contact address on witscode.com and we will scope the audit inside a business day.