The Vibe-Coding Breach Timeline: Enrichlead, Tea, Base44, Moltbook

You built something with an AI tool, it works, and now a headline about some other app getting hacked has you wondering: could that be me? It's a fair question. The apps in the news weren't built by careless people. They were built by founders moving fast with the same tools you're using.

The good news is that vibe coding breaches are not random. They cluster around a handful of repeatable mistakes. Once you've seen the pattern a few times, you can spot it in your own app — and you stop being surprised by the next headline.

This post walks through four of the most-discussed incidents in order: Enrichlead, the Tea app, Base44, and Moltbook. For each one, you'll get what happened, the real root cause, and the lesson. By the end, the common thread will be obvious.

⚡ TL;DR

• The same few root causes show up again and again: missing access rules on the database, unsecured storage, and auth that trusts the wrong thing.
• In almost every case the public-facing key or ID was not the bug. The bug was a missing or broken rule behind it.
• None of these required a sophisticated attacker. The gaps were findable in minutes by anyone who looked.

Enrichlead — March 2025

What happened. Enrichlead was a lead-enrichment app its founder publicly described as built with Cursor and "zero hand-written code." Shortly after launch, the wheels came off fast. Within about two days, people had bypassed the paywall to use paid features for free, the app's API keys were maxed out by outside usage, and the database filled with garbage data. The founder ended up shutting it down.

The real root cause. This wasn't one exotic exploit. It was the absence of basic server-side checks. When an app is generated to "just work" in a preview, the rules that separate a paying user from a free one — and the rules that stop a stranger from writing junk into your database — often never get written. The app demos perfectly because nothing is testing those boundaries. Real users do.

The lesson. "It works in the preview" is not the same as "it's secure." A working demo proves the happy path. It tells you nothing about what happens when someone pokes at the edges. (Cursor itself is a capable tool — the issue is what it leaves to you. More on that in Is Cursor safe?.)

Tea app — July 2025

What happened. Tea was a women's safety app. In July 2025, an unsecured legacy Firebase storage bucket exposed roughly 72,000 images — including about 13,000 selfies and photos of government IDs that users had uploaded for verification. A second breach then exposed more than 1.1 million private direct messages. The fallout has since consolidated into class-action litigation in California.

The real root cause. The data leaked because a storage bucket — a folder of files in the cloud — was left open. Firebase, like most backends, will happily serve files to anyone if the rules protecting them are missing or too permissive. The sensitive part here wasn't a leaked password. It was that the bucket holding the most sensitive possible data (faces and IDs) had no working lock on it.

The lesson. Storage is data too. Founders obsess over the database and forget that uploaded files — profile photos, IDs, receipts, attachments — live in a separate store with its own rules. If you collect ID documents, the bucket holding them deserves more scrutiny than anything else you own. (We break this incident down in full in the Tea app breach.)

Base44 — July 2025

What happened. Base44 is an AI app-building platform. In July 2025, Wiz Research found an authentication bypass. Each app had a public app_id. Using that public ID plus a pair of undocumented "register" and "verify one-time-password" endpoints, anyone could create a fully verified account inside any private app — sidestepping the single sign-on (SSO) the app was supposed to require. Wix patched it in under 24 hours. There was no evidence anyone had exploited it in the wild. Around 20,000 users were on the platform at the time.

The real root cause. The app_id being public was never the problem — identifiers like that are meant to be visible. The problem was that the sign-up endpoints didn't check whether the person was allowed to join. They trusted the request instead of verifying the user. SSO was the intended front door, but a side door had been left unlocked and undocumented.

The lesson. A public identifier is not a secret, and treating it like one is the wrong lesson. The right question is always: does the endpoint behind this ID actually check permission? This is the difference between something being visible (fine) and something being unprotected (the real risk). (Full write-up: Is Base44 safe?.)

Moltbook — January 2026

What happened. Moltbook was an AI-powered social network running on a Supabase backend. In January 2026, Wiz found that it was missing Row Level Security (RLS) — the database rule that decides which user can see which rows. The result: roughly 1.5 million API keys and about 35,000 user emails were exposed. Worse, some of the leaked direct messages contained plaintext OpenAI keys that users had pasted into the app.

The real root cause. This is the canonical Supabase mistake. Supabase apps talk to the database directly from the browser, using a public key. That's by design. The protection is supposed to come from RLS — a per-user filter the database enforces on every query. With RLS missing, the public key could read tables it should never have been able to touch. The key wasn't the leak. The missing rule was.

The lesson. For the large share of vibe-coded apps built on Supabase, RLS is the single most important thing to get right. An exposed public key is normal. A table without a real access policy is a wide-open door. (Here's the plain-English version: Supabase RLS explained.)

How to check your own app

You don't need a security team to run the same checks an attacker would. Walk through the four failure modes above against your own app:

1. Server-side rules (Enrichlead). Can a non-paying user reach a paid feature by editing a request? Can a stranger write to your database without an account? If the only thing stopping them is the UI hiding a button, that's not protection.
2. Open storage (Tea). Open your storage buckets. Is anything that holds private files — photos, IDs, documents — readable without authentication? Try opening a file URL in a private browser window.
3. Auth side doors (Base44). Does every endpoint that creates or modifies data check who is asking, not just that someone asked? Public IDs in your URLs are fine; unauthenticated endpoints behind them are not.
4. Database access rules (Moltbook). If you use Supabase, does every table with user data have RLS enabled with a policy that actually restricts rows? If you use Firebase, are your Security Rules locked down?

The pattern behind every one of these

Read the four incidents back to back and the same shape appears each time.

The public part — the key, the app_id, the visible identifier — was almost never the actual vulnerability. People panic about exposed keys because they're easy to see. But in Base44 the app_id was supposed to be public, and in Moltbook the Supabase key was supposed to be public. The breach happened because the rule behind the public thing was missing or broken.

The real root causes were boring and repeatable:

• No server-side authorization — the app trusted the browser to enforce limits (Enrichlead, Base44).
• Unsecured storage — a bucket of sensitive files left readable (Tea).
• Missing database access rules — tables exposed because RLS wasn't there (Moltbook).

None of these required a clever attacker. They required someone to open the network tab, notice an endpoint, and try it. That's the uncomfortable part: the gap that ends your app is usually findable in minutes by anyone curious enough to look.

And there's a second pattern. In several cases the issue appeared after the app was working and launched — sometimes long after, in legacy infrastructure nobody revisited. AI tools ship new code on every prompt. Each new feature is a new chance to introduce one of these four gaps. Security isn't a one-time check before launch; it's something you keep doing because the surface keeps changing.

FAQ

Were these apps hacked because they were vibe-coded?

Not exactly. They were hacked because of specific missing controls — open storage, missing access rules, unverified endpoints. AI tools make those mistakes more common because they optimize for a working demo and leave security to you. But the same gaps appear in hand-written code. The tool didn't doom the app; the unchecked default did.

Should I be rotating my API keys after reading this?

For the public keys — the Supabase anon key, a Firebase web config, a pk_live_ Stripe key — no. Those are meant to ship in the browser, and rotating them changes nothing. The keys that matter are the secret ones (like a service_role key or an OpenAI key), and the rule is: never put those in frontend code in the first place. The fix for these breaches is fixing the rules, not the keys.

How fast can someone actually find a gap like this?

Minutes, in most of these cases. An open bucket is one URL. A missing RLS policy shows up the moment someone queries your public API. Researchers like Wiz found Base44 and Moltbook precisely because these gaps are mechanical to detect. If a researcher can find it, so can anyone else.

The bottom line

Four breaches, one story: the visible key is rarely the problem, and the same few missing rules — server-side authorization, locked storage, real database policies — cause leak after leak. An attacker can find these gaps in minutes by reading your app's traffic. The point is to find them first, and to keep checking, because your AI ships new code (and new holes) on every deploy.