Moltbook 硬编码 Supabase 密钥泄露 150 万 agent API token，可被完全劫持

Back to incident tracker

2026-02-01

HighPrimary

Moltbook's Hardcoded Supabase Key Exposed 1.5M Agent API Tokens, Enabling Full Agent Hijack

Wiz discovered a hardcoded Supabase API key in Moltbook's client-side JavaScript, exposing 1.5M agent tokens and enabling full read/write access to the production database.

Moltbook / SupabaseCredential exposureCredential exposure / agent hijackingMoltbook production database / 1.5M agent API tokens

What happened

Wiz researchers extracted a hardcoded Supabase API key from Moltbook's production Next.js static JavaScript bundle and demonstrated full unauthenticated read/write access to the production database, including agent tokens, email addresses, and private messages.

Why it matters

1.5 million agent API authentication tokens and 35,000 email addresses exposed to any external party. Full write access to agent session and identity records enabled unrestricted agent hijacking. Permiso separately documented active bot-to-bot prompt injection campaigns: agents deleting accounts, running crypto pump schemes, and spreading jailbreak content through the agent social graph.

Missing authorization check

API credentials must never be embedded in client-side JavaScript. Supabase Row Level Security (RLS) was not configured, making the public API key equivalent to a root database credential. Write operations against agent identity and session records should require authenticated, signed authorization.

Would PP block it?

If a hijacked agent attempted a deploy, production data mutation, or any PP-gated action, the enforcement layer would block it: no valid receipt, no action. This limits the consequential blast radius of a compromised agent. PP does not address the Supabase misconfiguration or prevent database-level reads. Full coverage requires: (1) secure credential management (no secrets in client-side JS), and (2) PP receipts for any consequential agent action downstream.

Incident analysis

Timeline and technical read

Timeline

1. 2026-01-31

   Moltbook launches publicly and goes viral; Andrej Karpathy calls it 'genuinely the most incredible sci-fi takeoff-adjacent thing I have seen recently.' The founder discloses the platform was entirely vibe-coded.

2. 2026-02-01

   Wiz researchers discover a Supabase API key hardcoded in Moltbook's client-side Next.js JavaScript bundle, providing unauthenticated read/write access to the full production database.

3. 2026-02-02

   Wiz discloses the vulnerability to Moltbook. The database is secured within hours; all agent API tokens are rotated. Wiz publishes a detailed technical writeup.

4. 2026-02-04

   SecurityWeek and Permiso publish analysis of active bot-to-bot prompt injection campaigns on the platform — agents coordinating account deletions, crypto pump schemes, and jailbreak spreading through the social graph.

5. 2026-03-10

   Meta acquires Moltbook.

Technical breakdown

• Moltbook was vibe-coded by its founder who wrote no code himself. The Supabase API key was embedded in a production Next.js static chunk visible to any user who inspected the page source.
• Supabase requires Row Level Security (RLS) to be enabled for its public API key to be safe client-side. Moltbook had no RLS policies — making the public key equivalent to a root credential with full database access.
• The database held 1.5M agent API tokens (88 agents per human on average), 35,000 email addresses, and private agent messages — all accessible via a single unauthenticated HTTP request.
• Permiso's parallel analysis found active bot-to-bot attacks: agents injecting prompts to instruct others to delete their accounts, coordinate financial manipulation, and spread jailbreak instructions through the platform's social graph — a novel lateral movement surface.
• The compounded failure chain: vibe-coded infra skipped credential hygiene, Supabase defaults without RLS are unsafe for production, no external governance layer limited what a hijacked agent could do downstream.

Authorization boundary

Where the authorization boundary should have been

This incident is categorized as Credential exposure. The relevant Permission Protocol gate is Credential Gate. The read is conditional: the block only applies where the real action boundary is routed through a gate.

If enforced at

Agent action gate, tool-call authorization

Still needs

Credential storage hygiene; database-level Row Level Security configuration

Receipt required for

Any agent action that modifies another agent's identity, session data, or platform records

PP's enforcement layer would catch hijacked agents attempting gate-checked actions — they would not hold a valid authority receipt. PP does not prevent the credential exposure itself, which requires secure infrastructure practices.

Start small

Put the relevant gate at this action boundary.

This incident maps to Credential Gate. Start with the boundary that controls the actual action, then require a signed receipt before execution.

Replay this incident with a signer in the loop