Full Report
1 exposed database. 35,000 emails. 1.5M API keys. And 17,000 humans behind the not-so-autonomous AI network.
Analysis Summary
# Incident Report: Exposed Moltbook Database via Client-Side Credentials
## Executive Summary
The AI social networking platform Moltbook suffered a significant security incident due to a misconfigured Supabase database that was accessible via hardcoded, publishable credentials within the client-side JavaScript bundle. This misconfiguration allowed unauthenticated read and write access to the entire production database, exposing 1.5 million API keys and 35,000 user email addresses. The vulnerability was discovered by external researchers (Wiz), and the issue was remediated by the Moltbook team within hours of disclosure.
## Incident Details
- **Discovery Date:** Prior to February 2, 2026 (Date of reporting)
- **Incident Date:** Not explicitly stated, but occurred when the JavaScript bundle was deployed containing exposed credentials.
- **Affected Organization:** Moltbook (AI Social Network)
- **Sector:** Technology/Social Networking (AI Platform)
- **Geography:** Not disclosed
## Timeline of Events
### Initial Access
- **Date/Time:** Unknown (Pre-February 2, 2026)
- **Vector:** Exposure of sensitive code in client-side JavaScript bundles.
- **Details:** Researchers browsing the Moltbook website inspected client-side JavaScript files (`https://www.moltbook.com/_next/static/chunks/18e24eafc444b2b9.js`) and found hardcoded Supabase connection details, including a publishable API key.
### Lateral Movement
- **Details:** The exposed **publishable** Supabase API key granted unauthenticated read and write access to the *entire* production database via the PostgREST/GraphQL endpoints, allowing attackers to query, modify, or delete all platform data without needing to pivot internally.
### Data Exfiltration/Impact
- **Details:** The exposed database contained 1.5 million API authentication tokens, 35,000 email addresses, and private messages between agents. The platform's stated structure (AI agents) was contrasted by the discovery that the network was primarily driven by 17,000 humans operating bots.
### Detection & Response
- **Details:** The vulnerability was discovered by Wiz threat researchers conducting a non-intrusive security review. The issue was immediately disclosed to the Moltbook team. The team secured the misconfiguration within hours with assistance from Wiz researchers, and all data accessed for research/verification was deleted.
## Attack Methodology
- **Initial Access:** Configuration Data Leakage (Hardcoded credentials in client-side JavaScript).
- **Persistence:** Access was maintained via the exposed API key until remediation.
- **Privilege Escalation:** Not applicable; the exposed key already provided extensive access (read/write to all tables).
- **Defense Evasion:** The underlying issue was a configuration oversight ("vibe-coded" development leading to security gaps), not an active attempt to evade security tooling.
- **Credential Access:** Direct extraction of infrastructure credentials (Supabase API Key).
- **Discovery:** Researchers used standard web inspection tools to analyze bundled JavaScript files.
- **Lateral Movement:** Not required; the key provided blanket access to the Supabase backend.
- **Collection:** Unauthenticated reading of all database tables via Supabase endpoints.
- **Exfiltration:** Data (API keys, emails, messages) was exfiltrated by researchers for verification purposes, and implicitly available for malicious exfiltration prior to fix.
- **Impact:** Unauthorized data disclosure and potential account takeover via stolen API keys.
## Impact Assessment
- **Financial:** Not disclosed.
- **Data Breach:** Exposure of **1.5 Million API Authentication Tokens**, **35,000 Email Addresses**, and **Private Agent Messages**.
- **Operational:** The platform's core functionality (agent registration/interaction) was compromised, allowing humans to easily create millions of fake agents due to a lack of proper verification mechanisms.
- **Reputational:** Significant negative publicity highlighting security flaws in "vibe-coded" AI applications.
## Indicators of Compromise
- **Network Indicators (Defanged):**
- Supabase Project URL: `hxxps://ehxbxtjliybbloantpwq[.]supabase[.]co`
- **File Indicators:**
- Client-side JavaScript bundle containing secrets: `.../_next/static/chunks/18e24eafc444b2b9[.]js`
- **Behavioral Indicators:**
- Unauthenticated Read/Write operations on the Supabase backend.
- Mass creation of "agent" accounts via automated POST requests without verification.
## Response Actions
- **Containment measures:** Immediate remediation by the Moltbook team upon notification, securing the misconfigured Supabase instance.
- **Eradication steps:** Verification by researchers that access was revoked and access rights were appropriately scoped.
- **Recovery actions:** Deletion of all data accessed during the research and verification phase. (Implied subsequent rotation of credentials, though not explicitly stated).
## Lessons Learned
- **Vulnerability Pattern:** Hardcoding sensitive infrastructure credentials (like API keys for services such as Supabase) directly into client-side, publicly delivered JavaScript bundles is a critical and recurring vulnerability, especially in rapidly developed ("vibe-coded") applications.
- **Authentication/Authorization Gaps:** The platform lacked sufficient checks, allowing any user (or script) to post content disguised as an "AI agent" without proving AI status, leading to platform manipulation.
- **Data Exposure Revealed Scale Discrepancy:** The breach exposed that the platform was overwhelmingly human-controlled (17,000 humans vs. 1.5M purported agents), undermining the platform’s public narrative.
## Recommendations
- **Strict Credential Management:** Avoid baking *any* infrastructure-level secrets into frontend/client-side code, even Publishable Keys, if they grant read/write access to sensitive production data. Move all configuration to secure backend environments.
- **Principle of Least Privilege:** Ensure that client-side API keys (if necessary) only have permissions limited to the absolute minimum functions they require (e.g., read-only access to non-sensitive tables).
- **Input Validation:** Implement robust verification mechanisms to distinguish between human actors and actual intended AI agents, or enforce access controls based on verified system usage, rather than purely based on an agent identity token.
- **Security Review:** Incorporate necessary security reviews/audits early in the development cycle for applications leveraging "vibe-coding" or rapid AI-assisted development.