# PIR-2026-0040 - Moltbook misconfigured database exposes ~1.5M agent API keys with unauthenticated read/write

- `id`: PIR-2026-0040
- `title`: Supabase key in client-side JS with Row Level Security disabled gives anyone read/write over Moltbook's entire production DB, including ~1.5M agent tokens
- `date_occurred`: 2026-01 (exposed from platform launch in late January 2026)
- `date_detected`: 2026-01-31 (Wiz researchers; maintainer contacted 21:48 UTC)
- `date_disclosed`: early 2026-02 (Wiz blog + broad press)
- `status`: corroborated (primary researcher timeline + maintainer confirmation + independent coverage)

### The agent
- `agent_description`: Moltbook, a viral social network exclusively for autonomous AI agents (mostly OpenClaw-based) posting on heartbeat cycles; solo founder; codebase almost entirely AI-generated (founder said he "didn't write a single line of code").
- `operator_type`: individual (solo founder)
- `autonomy_level`: platform agents run autonomous-within-policy; the failure itself is operator-side configuration, not agent behavior
- `model_stack`: n/a for the failure path (platform serves OpenClaw-based agents on various models)
- `harness`: Supabase backend + client-side JavaScript bundles

### Authority (what the exposure granted to anyone)
- `authority_scope`: credentials (~1.5M agent API tokens - impersonation/hijack of any agent on the platform), data access (~35K user emails, verification codes, 4,060 private agent DM conversations, some containing plaintext OpenAI keys), write access to the production DB (feed/command injection into any agent)
- `funds_at_risk_usd`: unknown (some platform agents held crypto wallets; exposed plaintext OpenAI keys were spendable)
- `blast_radius`: customers/third parties (every registered agent and its owner)

### The failure
- `root_cause`: credential-exposure (primary); contributing operator-error (misconfiguration)
- `failure_locus`: operator-config (Supabase Row Level Security not enabled; publishable API key shipped in client-side JS)
- `mechanism`: The Supabase publishable key shipped in client-side JavaScript while Row Level Security was missing/misconfigured, granting unauthenticated read AND write to the entire production database. Anyone could read ~1.5M agent API tokens, ~35K user emails, and private agent DMs, and could write to agents' feeds - that is, hijack or command-inject any agent on the platform. Wiz found the flaw within minutes of examining the public code bundles.
- `adversary_present`: unknown (none confirmed; the window was open since launch)
- `exploitation_status`: researcher-demonstrated (Wiz demonstrated full read/write against production; no confirmed in-wild exploitation of the window)

### Impact
- `severity`: near-miss (full exposure, zero confirmed realized loss - reclassified from the candidate's "degraded", see Verification notes)
- `direct_loss_usd`: 0 confirmed
- `indirect_loss_usd`: unknown (rotation burden across ~1.5M agent tokens plus exposed third-party keys)
- `downtime`: none material (fixes applied live)
- `data_exposure`: agent tokens, user emails, verification codes, private agent DMs including plaintext third-party API keys - readable by anyone during the window; confirmed access only by the researchers

### Detection and recovery
- `detected_by`: third-party (Wiz researchers)
- `time_to_detect`: days from launch exposure; minutes once anyone competent looked
- `time_to_recover`: ~3.2 hours from first contact (first tables secured 23:29 UTC Jan 31; final fix 01:00 UTC Feb 1)
- `remediation`: RLS enabled and tables secured stepwise; write access blocked
- `structural_fix`: unknown beyond the immediate configuration fix; the AI-generated codebase itself remains the standing risk every outlet flagged
- `controls_that_worked`: responsible disclosure plus a responsive maintainer (full fix ~3 hours after a cold DM); nothing preventive worked

### Evidence
- `telemetry_grade`: operator-logs (researcher screenshots/timeline + maintainer confirmation; no independent audit of who else may have accessed the DB)
- `sources`:
  - https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys (primary, researcher)
  - https://thecyberexpress.com/moltbook-platform-exposes-1-5-mn-api-keys/ (independent)
  - https://www.infosecurity-magazine.com/news/moltbook-exposes-user-data-api/ (independent)
  - https://www.bankinfosecurity.com/moltbook-gave-everyone-control-every-ai-agent-a-30710 (independent)
  - `independence`: good - primary researcher plus multiple independent outlets.
- `aiid_incident_id`: 1364 (https://incidentdatabase.ai/cite/1364/) - cross-reference; primaries verified independently
- `confidence`: high on exposure scope, root cause, and fix timeline; the unknowable is whether any third party used the window before Wiz did

### Verification notes
1. Discovery date corrected: Wiz found and reported the exposure on 2026-01-31 (maintainer contacted 21:48 UTC), not 2026-02-01 as the candidate had it; remediation completed 2026-02-01 01:00 UTC.
2. Severity reclassified degraded -> near-miss: full exposure with zero confirmed realized loss matches the schema's near-miss definition and the PIR-2026-0045 precedent for exposed-but-unabused credentials. The v0.1 `exploitation_status` field now carries the found-in-production distinction the candidate's "degraded" was trying to express.
3. The candidate's "~29.6K waitlist emails" figure was not confirmed in the sources checked (they cite ~35K user emails, private messages, verification codes); omitted rather than carried.

### Corrections

- 2026-08-19: Added `aiid_incident_id` cross-reference (AIID 1364), matched against the AIID weekly database export (2026-08-17). A cross-reference, not a re-verification; no claim changed.