This one's barely a week old, so I want to write it down while it's still fresh, because I think the timeline itself is the most useful part of the story.
What actually happened, in order
- January 28: Moltbook launches, an AI-agent social network built entirely through vibe coding.
- January 31, late evening: Wiz researchers discover the app's Supabase database is exposed, a hardcoded, unrestricted API key with no row-level security enabled at all.
- Same day: the exposure gets secured within hours of being found.
- February 2: Wiz publishes the full writeup, making the exposure public. Roughly 1.5 million API auth tokens exposed, along with about 35,000 email addresses and private agent-to-agent messages that included plaintext API keys for other services.
Four days from launch to a fully public, detailed disclosure. That's not a slow burn. That's about as fast as this category of mistake can possibly surface.
Why I'm not surprised, and why that's the actual point
This is the same shape of failure that's shown up in nearly every major AI-app-security story over the past year: a hardcoded key with no row-level security behind it, sitting on a Supabase-style backend, reachable by anyone who thinks to look. It's not a new attack technique. It's not a clever exploit. It's the identical missing checkbox that caused the Lovable disclosure back in May, just wearing a different app's name this time.
What strikes me about Moltbook specifically is how little time existed between the idea and the exposure. Four days is barely enough time to onboard a first batch of users, let alone notice a security gap on your own. The speed that makes vibe coding remarkable is the exact same speed that skips the step where someone asks "who else can read this."
What actually saved this one from being worse
Two things went right here, and they're worth naming specifically because they're the difference between a bad day and a genuinely damaging one. Someone was actually looking, in this case a research team that treats scanning newly launched apps as part of their job, not a random stroke of luck. And once found, it got fixed within hours, not weeks. Both of those are choices, not accidents, and neither one depends on the app never having a gap in the first place, because apparently that gap is close to inevitable at this speed of building.
The thing worth actually taking from this
If you're building something this month with a Supabase or similar backend, the single highest-value five minutes you can spend is confirming row-level security is turned on for every table, and that the policy behind it actually restricts access instead of quietly evaluating to true for everyone. That's the entire lesson from Moltbook, from the Lovable disclosure in May, and from most of the incidents I've written about since. The mistake doesn't change. Only the app's name does.