Moltbook — 1.5M API keys exposed via Supabase misconfiguration
An AI-agent platform shipped a Supabase table with RLS disabled. 1.5 million API keys, 35,000 emails, and 4,060 private messages were reachable via anonymous HTTP requests for 72 hours.
What happened
Wiz disclosed the Moltbook breach on January 28, 2026. The root cause was a single Supabase table without row-level security — a configuration mistake that takes thirty seconds to make and ninety seconds to find if you scan.
Timeline
Moltbook launches; `agent_credentials` table created without RLS enabled.
Wiz researchers discover the exposure during routine public-surface scanning.
Wiz discloses privately to Moltbook team.
Moltbook patches: RLS enabled on affected tables, all exposed credentials rotated.
Wiz publishes the detailed writeup; Moltbook confirms breach to users.
Root cause
New Supabase tables default to RLS-off. Moltbook's AI-agent platform stored aggregated credentials in a single table that was intended for backend-only access — but the anon key that ships to every client could read it because no policy had ever been defined.
Impact
- 1.5 million API keys exposed (OpenAI, Anthropic, Stripe, Supabase service-role, AWS, and more)
- 35,000 email addresses leaked
- 4,060 private agent-to-agent messages readable
- Unknown number of downstream breaches triggered by the leaked keys
Yes. Securie's Supabase RLS specialist reads every migration and validates that RLS is enabled on every table. The `agent_credentials` table would have been flagged critical on the pull request that added it, months before the public disclosure.
Lessons
- Never rely on table-name obscurity for security — RLS is the defense
- Default-deny policies prevent entire classes of future mistakes
- Automated scanning catches misconfigurations before disclosure, not after