1.5 million keys and not one line of code
The most viral AI launch of 2026 shipped the exact vulnerability we keep writing about: a Supabase backend with row-level security switched off and the public key sitting in the frontend. Here is why it keeps happening, and what a release gate catches before it does.
- security
- vibe coding
On January 28, 2026, Moltbook launched: a Reddit-style social network built for AI agents, where autonomous bots post, comment, and earn karma while humans watch from the sidelines. It went viral almost immediately. Its founder, Matt Schlicht, was refreshingly candid about how it was built. “I didn’t write a single line of code for @moltbook,” he posted. “I just had a vision for the technical architecture, and AI made it a reality.”
Three days later, the entire production database turned out to be readable and writable by anyone with a browser.
What Wiz found
On January 31, security researchers at Wiz spotted a Supabase API key hardcoded into Moltbook’s client-side JavaScript, and, as they detail in their writeup (Hacking Moltbook), Row-Level Security was switched off across the tables. That combination is total: a publishable key is meant to be public, and RLS is the thing that makes it safe to publish. With RLS disabled, the public key was not a client credential, it was an unauthenticated admin login to production.
The exposed surface was not small:
- 1.5 million API authentication tokens
- 35,000 email addresses
- 1.5 million agent profiles tied to roughly 17,000 human account owners
- 4,060 private agent messages that contained plaintext OpenAI API keys
Wiz verified that writes landed instantly in the live feed, which means an attacker could not just read everything, they could rewrite posts and inject instructions straight into the agents running on the platform. To their credit, the Moltbook team moved fast once notified: initial contact went out at 21:48 UTC on January 31, and every table was locked down by 01:00 UTC on February 1. The fix took hours. The exposure had been live since launch.
We already wrote about this exact bug
If this feels familiar, it should. In the most common vulnerabilities in vibe-coded apps we walked through CVE-2025-48757, a CVSS 9.3 flaw where Lovable-generated projects shipped Supabase databases with missing Row-Level Security and let the public client key read and write arbitrary tables. More than 170 production apps were confirmed exposed.
Moltbook is that same bug, shipped again, on the highest-profile AI launch of the year. Same backend, same missing guardrail, same public key doing a job it was never meant to do. The only thing that scaled was the blast radius.
Why the model does this to you
An AI assistant asked to “build a social app with a Supabase backend” will wire up a working app. It will initialize the client with the anon key, write the queries, and hand you something that runs on the first try. What it will not do, unless you know to demand it, is enable Row-Level Security and write a policy for every table, because that step is invisible in a demo. The app looks identical with RLS on or off. The difference only shows up when a stranger points a script at your database.
That is the shape of nearly every vibe-coding breach: not exotic, not clever, just a safe-by-default step the model skipped because skipping it still produced code that ran. The person prompting cannot catch what they did not write and would not recognize as missing.
What a release gate catches here
Moltbook did not need a bigger model or a slower team. It needed one look across the whole surface before the app went public. A five-layer scan flags every piece of this before launch:
- Secrets: the Supabase key committed into the frontend bundle, and the OpenAI keys sitting in message records, both surface as exposed credentials.
- Configuration: a Supabase project with RLS disabled is a misconfiguration finding on its own, independent of any single query.
- Code: client-side database access with no server-enforced authorization is the broken-access-control pattern static analysis is built to catch.
Any one of those three is a release blocker. All three together add up to a no-go decision, which is the whole point: not five separate reports to triage, but one answer before the thing is live. We laid out how the layers fit together in the five layers of a release gate.
Vibe coding built Moltbook in an afternoon and it built the leak in the same afternoon. The build was never the risk. Shipping it without a look was.