Vibe Coding Hacked: Three Real Breaches and What Went Wrong

Vibe coding gets hacked — not through exotic exploits, but through the predictable gaps AI tools leave in the authorization layer. Three documented incidents in 2025–2026 prove the pattern. Moltbook lost 1.5 million API authentication tokens three days after launch. Lovable had a broken authorization flaw open for 48 days affecting millions of user projects. Base44's authentication system was bypassed using a value that was publicly visible in every app URL.

All three had working products. All three had real users. All three failed at the same layer — not the code that makes the app work, but the code that decides who is allowed to access what.

This is the pattern behind every vibe coding security incident we have tracked. Understanding it takes about ten minutes. Fixing the equivalent in your own app takes less time than that.

The Moltbook Breach: What RLS Failure Looks Like in Production

Moltbook launched as a vibe-coded social network in January 2026. The product gained thousands of users in its first days. Three days after launch, a security researcher examined the network traffic and discovered the Supabase database powering Moltbook had no row-level security configured on any table.

Every table was accessible to any authenticated user. There was no exploit involved — no injection, no token theft, no sophisticated attack chain. A researcher with a valid account made ordinary API calls and received data that belonged to other users. 1.5 million API authentication tokens and 35,000 email addresses, extracted through the same mechanism the app used to serve legitimate requests.

The app worked. The product experience was intact. The breach was entirely separate from functionality — authorization had never been added.

The technical cause: Supabase databases without RLS enabled return all rows to any authenticated request. The AI tool that scaffolded Moltbook created the database structure and connected it to the app. It did not add row-level security policies because no prompt asked it to.

What this means for founders: If your app was built with Lovable, Bolt, Cursor, or any AI tool with Supabase, and you did not explicitly configure RLS, your database is likely in this state right now. Check every table in your Supabase dashboard. Enable RLS. Test denial — sign in as a second user and confirm they cannot read the first user's rows.

Our guide to Supabase RLS for AI-built apps covers every policy pattern you need and the test method to verify each one.

The Lovable Incident: What BOLA Looks Like in a $6.6B Platform

Lovable is not a small startup. It is a platform with eight million users and a $6.6 billion valuation. In April 2026, security researcher @weezerOSINT disclosed a mass data breach affecting every Lovable project created before November 2025.

The vulnerability was broken object-level authorization (BOLA) — the same class of flaw that sits at the top of the OWASP API Security Top 10. By creating a free Lovable account, any user could read another user's source code, database credentials, AI chat history, and customer data. Five API calls. No technical sophistication required.

The flaw had been reported to Lovable's bug bounty program 48 days earlier. The report was closed without escalation.

Lovable's public response after disclosure:

1. Posted that it "did not suffer a data breach"
2. Described the exposed data as "intentional behaviour"
3. Blamed its own documentation
4. Blamed its bug bounty partner HackerOne
5. Later apologised for the apology

The vulnerability was eventually fixed. The trust damage from 48 days of inaction and the subsequent response pattern is ongoing.

The technical cause: BOLA happens when an API endpoint checks that a user is authenticated but does not check that the user owns the resource they are requesting. Lovable's internal API authenticated requests by session but did not bind resource lookups to the requesting user's identity.

What this means for founders: If your app was built by an AI tool, every API route and server action that returns user-owned data should be checked. The question is not "does this endpoint require login?" The question is "does this endpoint verify the logged-in user owns the data they are requesting?" These are different questions, and AI tools answer the first one without being asked about the second.

See our breakdown of BOLA and IDOR in AI-built apps for the exact code pattern to add.

The Base44 Incident: What Platform-Level Risk Looks Like

Base44 is a vibe coding platform — similar to Lovable or Bolt — where businesses build internal tools, HR systems, knowledge bases, and customer-facing applications using AI. In July 2025, Wiz Research discovered a critical authentication bypass in the platform itself.

The flaw was in Base44's registration and email verification API endpoints, which were publicly accessible and required no authentication. To exploit the vulnerability, an attacker needed only an application's app_id — a value that was hardcoded into every app's URL and visible in public manifest files. Using that app_id, an attacker could create a verified account in any private application built on Base44, bypassing all authentication controls including Single Sign-On (SSO).

Enterprise HR systems, PII databases, internal communication tools — all applications built on Base44 that had SSO configured for access control were accessible to anyone who knew the URL structure.

Wix, which acquired Base44, fixed the vulnerability in less than 24 hours of notification and confirmed no evidence of exploitation. The speed of the fix does not change the architectural lesson: when you build on a vibe coding platform, a vulnerability in the platform affects every application you build on it, regardless of how carefully you wrote your own code.

The technical cause: Undocumented registration endpoints with no authentication and no rate limiting, relying on application app_id values for identification rather than cryptographic verification. The app_id was public by design.

What this means for founders: Platform-level vulnerabilities are outside your direct control. You cannot audit or fix the platform's authentication mechanism. What you can control: the data your app stores, the access controls you apply to it, and whether your app functions correctly even if the platform's authentication is bypassed. Defense-in-depth — RLS, server-side authorization, encrypted data — matters more when the platform layer cannot be fully trusted. See our Base44 security guide for the specific checks that apply.

The Most Common Unreported Incident: API Credits Drained Overnight

The three breaches above have documentation, timestamps, and postmortems because they involved user data exposure. There is a fourth category of vibe coding security incident that happens far more frequently and goes almost entirely unreported: API key theft and credential abuse.

The pattern: a founder builds a quick AI feature. An AI tool scaffolds the OpenAI or Anthropic call directly in client-side code. The key goes into the JavaScript bundle. Automated scraping services — some run by competitors, some by credential resellers, some by bots running continuously across the internet — detect the key within hours using pattern matching. Within 24 hours, the key is generating requests. The founder wakes up to a $3,000–$40,000 bill.

This is not a hypothetical scenario. It is a documented pattern. Several founders have posted about this publicly. The common thread: the AI tool suggested the direct client-side implementation because it was the simplest working solution. The founder tested it, saw the feature work, and shipped. The key was in the bundle the entire time.

What makes this different from the three cases above: there is no breach notification requirement for API billing abuse. There are no affected users to notify. The harm is financial, direct, and unrecoverable in most cases — OpenAI, Anthropic, and Stripe generally do not refund charges from compromised keys unless the abuse is extreme.

The fix is the same as risk #1 in this guide: every external API call goes through a server-side route. The key lives in server-only environment variables. If you have already shipped with a client-exposed key, rotate it immediately and verify the new key is in a server-only context before redeploying. See our guide to handling an exposed API key for the exact recovery steps.

What All Three Breaches Have in Common

The pattern is not coincidence.

In every case:

• The product worked — users could use the app as intended
• The vulnerability was in the authorization layer, not the feature layer
• Happy-path testing never found it — because testers always use their own data
• AI tools generated the working code — and left the security layer incomplete

The vibe coding security gap is not that AI tools produce bad code. It is that AI tools produce code that works as specified — and security is never specified in the prompt.

What to Do If You Have Already Shipped

If you have shipped a vibe-coded app and have not run a security pass, these are the three checks that cover the majority of breach risk:

1. Check Supabase RLS on every table. Open your Supabase dashboard, go to the Table Editor, and look for any table with "RLS disabled" shown. Enable RLS. Then look at every existing policy and confirm it contains a reference to auth.uid(). A policy without auth.uid() scopes access to all authenticated users, not the requesting user.

2. Check resource ownership in every API route. For every route that returns or modifies data: does the database query include a WHERE user_id = [authenticated user's ID] constraint? If the query looks up data by ID alone and relies on the application to verify ownership, it has a BOLA vulnerability.

3. Check where your Supabase service role key is imported. Search your codebase for service_role and SUPABASE_SERVICE_ROLE_KEY. Every file that contains these should have import 'server-only' at the top. If any of these files are imported by client components, the key has reached the browser.

Run a free security scan on Ubserve to cover these checks automatically. The scan takes two minutes, checks your live frontend for key exposure patterns, and gives you a score with specific findings. The full audit covers your entire stack including RLS coverage and authorization patterns.

The breaches above happened to apps with real users and real products. They did not happen because the founders were careless. They happened because the tools they used to build fast did not build the security layer for them, and no one checked before shipping.

The check takes less time than reading this article.

— Mr. Ballaz, Founder of Ubserve