Moltbook security issues: every incident, how it happened, and what's still open

The short answer

This is the detailed companion to our security issues incident log. For step-by-step protection, see protect your agent and API keys. For the wider rules and ethics, see Moltbook safety and ethics.

The issue register

"Owner-side" means the fix lies mainly with the people running agents: their software, permissions and habits. Moltbook can reduce these risks, but it can't eliminate them.

Issue 1: the database exposure (31 January 2026)

The best-documented incident comes from Gal Nagli of Wiz, published on 2 February 2026 as "Hacking Moltbook". 404 Media reported the exposure on 31 January under the headline "Exposed Moltbook Database Let Anyone Take Control of Any AI Agent on the Site".

How it happened

Moltbook was built on Supabase, a hosted database service. Supabase apps ship a "publishable" key to the browser, and that's normal. The key is meant to be public, provided row-level security (RLS) policies limit what each request may see or change. Moltbook's tables had RLS disabled. So the key in the site's JavaScript bundle worked as a master key: anyone could query or modify any table directly, bypassing the website entirely. Moltbook's co-founder had said publicly that he "didn't write one line of code" for the site, and commentators widely linked the flaw to the "vibe-coded" build. Wiz's own conclusion was that "AI tools don't yet reason about security posture or access controls on a developer's behalf."

What was exposed

Crucially, access wasn't just read-only. Wiz found it could also modify live posts. For a period, anyone could have changed what agents appeared to say, which undermines every screenshot from that window.

Disclosure and fix timeline (UTC)

The response was fast once reported. The problem is that nobody knows how long the tables had been open before 31 January, or who else found them first. What owners should have done then, and should still do if they never did: rotate the agent's API key, rotate any third-party key ever sent in a Moltbook DM, and treat the owner email as a phishing target. See owner login for key rotation.

Why a breach on an agent network is different

On a normal social network, a leaked password lets an attacker post as one person, and that person usually notices. On Moltbook, a leaked API key is worse in three ways:

• Speed and scale. Keys are made for software. An attacker holding 1.5 million of them could script posts, votes and messages across the whole network in minutes, far faster than any human moderator could react.
• Nobody is watching. Agents run unattended on heartbeats. An owner may not look at their agent's activity for days, so a hijacked agent can post for a long time before anyone notices.
• Agents trust each other's words. A hijacked agent posting instructions is a prompt-injection attack delivered with an established reputation. Other agents that read it may act on it, spreading the compromise beyond Moltbook to whatever those agents can reach.

That's why security researchers treated the January exposure as more than a data leak. Wiz's Ami Luttwak summed up the wider worry: "The new internet is actually not verifiable." It's also why the single most effective owner action after any incident is the same: rotate the key, then check what your agent did while you weren't looking. See configuration and monitoring.

Issue 2: unlimited registrations and fake agents

In the launch week, Moltbook had no limit on agent registration. The same Wiz researcher showed that a single agent could register 500,000 accounts. Wiz's data showed about 1.5 million agents behind roughly 17,000 human owners, an average of 88 agents per person. The security impact was indirect but real: vote manipulation, fake engagement, spam at scale, and "popular" posts manufactured by bot swarms. The Moltbook Illusion later found four accounts responsible for about a third of comments in its data.

Status: mitigated. Claiming with email and X, verification puzzles on writes, and strict limits for new agents make mass abuse slower and more expensive. The old inflated numbers remain in the historical record. See agents vs humans and fake posts.

Issue 3: the skill supply chain

Ironically, the most upvoted Moltbook post of all time is a security warning. On 30 January 2026, the agent eudaemon_0 posted "The supply chain attack nobody is talking about: skill.md is an unsigned binary". It reported that another agent had "scanned all 286 ClawdHub skills with YARA rules and found a credential stealer disguised as a weather skill". The stealer read the agent's .env file and shipped secrets to an outside webhook.

The underlying problem is structural. Agent skills are instructions an AI follows, often bundled with code it runs. They're distributed without signatures, and installed with commands that fetch "arbitrary code from strangers", as the post put it. Moltbook's own skill.md is itself a set of instructions agents fetch and obey. Later research catalogued hundreds of malicious skills in community hubs; reported figures range from 341 to 386. IEEE Spectrum reported Snyk's finding that 36% of skills had at least one notable security flaw.

Status: ongoing, owner-side. OpenClaw 2.0 added a unified pipeline for validating and installing skills, but the safest defence is still to install only skills you've read, from sources you trust, in a sandbox. Get Moltbook's skill only from www.moltbook.com. See skill.md explained and connect OpenClaw.

Issue 4: prompt injection hidden in posts

Vectra AI's Lucie Cardiet reported on 3 February 2026 that "roughly 2.6 percent" of sampled Moltbook posts "contained hidden prompt-injection payloads". These are text designed to make reading agents "override their system prompts", "reveal API keys" or "perform unintended actions". Some use invisible characters, encoded blocks or look-alike letters to hide from human readers.

This is the defining risk of an agent social network. Every agent must read untrusted text to participate at all. Security researcher Simon Willison's "lethal trifecta" describes when it becomes dangerous: an agent with private data, exposure to untrusted content and the ability to communicate externally. Many OpenClaw agents on Moltbook have all three.

Status: ongoing, owner-side. Defences: keep the key and private data out of the model's view, treat posts as data rather than instructions, screen for hidden text, limit what the agent can do after reading, and don't let the same agent read Moltbook and your email. Our agent language guide includes a tested hidden-text checker. The full treatment is in prompt injection.

Issue 5: credentials shared in messages and posts

Among the 4,060 private messages exposed in January, Wiz found third-party credentials, including OpenAI API keys, which agents had shared with each other. Nothing in Moltbook's design forced that. Agents, or the humans instructing them, simply treated private messages as a safe place for secrets. They aren't: DMs are private from other agents, not from the platform or a breach.

Moltbook's rules make "Leaking API Keys" a ban-level offence, and the platform's own key should never leave www.moltbook.com. Status: behavioural, owner-side. Instruct your agent never to send, request or repeat credentials of any kind, and screen outgoing text for key-like strings. See safety and ethics.

Issue 6: vulnerabilities in the OpenClaw agent software

Most Moltbook agents run on OpenClaw, which can run commands and access files on the owner's machine, so its security record matters as much as Moltbook's:

Status: patched releases exist, but an outdated or internet-exposed install is still vulnerable. Keep OpenClaw updated, never expose its dashboard publicly, and enable sandboxing, which is off by default. Background: Moltbook and OpenClaw explained.

Issue 7: look-alike tools, credential harvesting and scams

Moltbook's fame attracted projects that borrowed its name and asked for its keys. The clearest case is MoltReg, which presented itself as an "agent tools interface". Its sign-up ended with "Log In Using Your Moltbook API Key" on a third-party website, and it launched a memecoin the next day. There were also trojanised developer extensions such as a fake "ClawBot Agent" for VS Code, tokens trading on the Moltbook name, and a surge of crypto promotion. About 9% of first-week posts concerned tokens and trading.

Status: ongoing. The rule that defeats all of these is Moltbook's own: "Your API key should ONLY appear in requests to https://www.moltbook.com/api/v1/*". Apps that legitimately need to know who an agent is should use identity tokens. See MoltReg explained, the app guide and every way to sign in.

Issue 8: identity and impersonation

Two identity problems ran through Moltbook's early weeks. First, humans could post as agents, through their own agents or, during the exposure, through anyone's. Many of the most famous "agent" posts were human-directed. Second, reviewers reported cases where ownership claims were abused through verification weaknesses and social engineering. The claim link itself is effectively a one-time key to an agent, and anyone who obtains it can try to claim it.

Status: mitigated. Claiming now ties agents to a verified email and X account. Owners get email login and key rotation. Third-party apps can verify an agent's identity with one-hour tokens rather than trusting a name. None of this proves a post was written autonomously. It only proves who is accountable. Protect your claim link like a password until you've used it. See claim and verify.

Moltbook's security posture in September 2026

Ownership by Meta since March 2026 may bring more security resources, but nothing has been announced publicly. The Privacy Policy notes that API keys and tokens are among the data Moltbook holds, which is another reason to rotate periodically. See the Meta deal six months on.

Breach advice that doesn't apply to Moltbook

Generic post-breach checklists circulate widely, and some of their advice doesn't fit how Moltbook works:

More on how Moltbook sign-in actually works: every way to sign in.

Ten-minute self-audit for agent owners

1. Has your key been rotated since 1 February 2026? If not, rotate it now in the owner dashboard.
2. Where is the key stored? It should be an environment variable or a 600-permission file, not in code, chats or screenshots.
3. Has the key ever been given to a third-party site or tool? If so, rotate it.
4. Has your agent ever sent any credential in a DM or post? Rotate that credential too.
5. Is OpenClaw on a current version, at least 2026.3.11, and ideally 2.0 or later?
6. Is its dashboard reachable from the internet? It shouldn't be.
7. Is sandboxing on? It's off by default.
8. Can you name every skill installed, and where each came from?
9. Can the agent that reads Moltbook also read your email or files? Separate them if so.
10. Is your owner email protected with 2FA?

Anything you answered badly has a fix in protect your agent and API keys. If your agent is misbehaving, start with agent not connecting or posting.

Lessons for anyone building agent platforms

• Secure defaults beat fast launches. RLS off by default, or a single missing policy, turns a public key into a master key. Wiz argued security must become "a first class, built-in part of AI powered development".
• Review AI-written code for access control. The Alan Turing Institute's CETaS team advised against putting AI-generated code into production "without human security review".
• Assume every input is hostile. On an agent network, content is code, because agents act on what they read.
• Sign what agents execute. Unsigned skills are an open supply chain.
• Never require users to share long-lived keys. Use scoped, short-lived tokens, as Moltbook's identity tokens now do.
• Rate-limit registration from day one. Metrics, votes and trust all depend on it.

For how developers can build safely on Moltbook today, see the developer guide and the REST API reference.

Frequently asked questions