When authentication is optional: the 🦞Moltbook API catastrophe

In late January 2026, Moltbook launched as an experimental social platform with explosive early growth: within days, tens of thousands of users were registered and the platform was buzzing. Everyone, bypassing all the basic security protocols, let their Molt/ClawdBot join Moltbook.

Well, that growth masked a fundamental security failure.
The backend used open source database infrastructure (likely Supabase-style) that exposes REST APIs by default.
Uh, where’s the problem you ask? Authentication was missing or misconfigured, leaving API keys, login tokens, and associated email addresses exposed on public endpoints that required no credentials to access.

Researchers confirmed that with nothing more than a simple HTTP request, anyone could enumerate accounts, extract API keys, and take over any user account on the platform.
My, myself and I, created a virtual ambiance to run ClawdBot and played a bit with the Moltbook environment: easy to have your bot post whatever you want to, to whom it may concern (and more).

A magnific design-level misstep!

The tech part – nerdy and rude

Here’s what was exposed:

• API Keys
  not obfuscated, not protected, publicly accessible without authentication – meaning anyone who knew where to look could harvest them in bulk

• Session Tokens
  available for enumeration and replay: an attacker could hijack active sessions without triggering logout or detection

• User Email Addresses
  tied directly to accounts, perfect for credential stuffing, phishing, or correlation attacks across platforms (also those are related to a valid X account, which verification is mandatory for joining Moltbook)

• IDOR at Scale
  Insecure Direct Object References allowed enumeration of the entire user base: change an ID parameter, get a different user’s data – rrrrrrepeat until you’ve scraped everything!

In practical terms: a malicious actor could impersonate any user, post content under their identity, inject malicious payloads into their activity, or pivot to external services using their leaked credentials. Chef’s kiss.

Ay Carramba!

API keys are credentials.
They grant programmatic access to services.
When they’re public, attackers don’t hack: they walk in the front door.

Let’s say it again. Exposed API keys are routinely weaponized:

• cloud resource hijacking: spin up compute instances, rack up bills, mine crypto
• data exfiltration: access databases, file stores, email archives, related identities
• lateral movement: pivot to connected services using compromised credentials
• supply chain attacks: inject malicious code into automated pipelines

Since API are now a hard skill, this kind of exposure isn’t a fringe issue, I see it as a systemic vulnerability waiting to be exploited at scale.

..oh, the controls, you say?

Security controls should have been baseline (spoiler: they aren’t):

• authentication on every Endpoint
  If an endpoint returns sensitive data, it requires authentication. No exceptions. No “read-only means safe” assumptions.

• secrets vaulting
  API keys should NEVER EVER be stored in plaintext. They should NEVER EVER be embedded in client-exposed code. They should be rotated regularly and scoped to least privilege.

• Role-Based Access Control (RBAC)
  Not every user needs access to every resource (let’s limit, please). Permissions should be granular, explicit, and enforced at the API layer.

• rate limiting and anomaly detection
  Bulk enumeration should trigger alerts. Sequential ID access patterns should be flagged. Abnormal API usage should be investigated.

• automated security scanning
  IDORs, exposed endpoints, and missing auth headers are detectable with basic tooling. These should be caught in CI/CD, not in production after launch.

This is foundational API security. The fact that it was missing is more concerning than the breach itself =/

Lessons for production systems

Ok, lemme be the BOFH I still am: this wasn’t a 0day or an APT: was a backend that shipped without authentication.

My 2cents, for developers:

• treat API keys as passwords: vault them, rotate them and NEVER EVER log them
• default to deny: every endpoint should require explicit authentication unless you have a documented reason otherwise (and I bet you don’t have)
• test your APIs like an attacker: enumerate IDs, modify parameters, try to access resources you shouldn’t be able to reach

My 50cents (no pwn intended), for security teams:

• API misconfigurations are low-hanging fruit for attackers: automated scanning should be continuous, not point-in-time
• authentication bypass vulnerabilities scale: one exposed endpoint can leak an entire database (one ring ro rule them all)
• incident response plans should include API key rotation: if keys are compromised, assume they’re already in use

For architects (no cents, I don’t go mad at architects XD):

• novelty doesn’t excuse fundamentals: moving fast is valuable and shipping without auth is negligent
• API-first platforms have API-first attack surfaces: design for that reality from day one

Wrapping up

Moltbook’s experiment became a case study in what happens when velocity outruns rigor.
Millions of API keys, tens of thousands of exposed emails, user accounts that could have been commandeered. Not because of a clever attack, but because the backend never stopped the keys from leaking in the first place.

If your platform runs on APIs (and most do) this architectural oversight shouldn’t be repeated – at least not in experimental apps, or in enterprise systems. Not anywhere that credentials control access to sensitive actions or data.