The OpenClaw Security Crisis: Exposed AI Agents, CVE-2026-25253, and the ClawHavoc Supply Chain

In early 2026, an open-source hobby project became the year's first major agentic-AI security crisis. OpenClaw - originally Clawdbot, then briefly Moltbot - is a local-first autonomous AI agent that runs shell commands, drives a browser, and reads your email, calendar, and files. It went viral, tens of thousands of people installed it, and within weeks it produced a verified one-click remote code execution flaw, a malicious-skill supply-chain campaign, a breach that leaked roughly 1.5 million agent tokens, and tens of thousands of control panels sitting open on the public internet. None of it required nation-state tooling. It required only that nobody was keeping track.

This advisory separates the verified facts from the viral numbers. The core incident is real and primary-sourced - NVD, GitHub Security Advisories, Koi Security, Censys, and SecurityScorecard all published on it. A few headline exposure figures circulating online, such as 220,000 or 245,000 agents, are not corroborated by any primary scanner and should be treated as unverified. The underlying lesson is bigger than any single count: OpenClaw is the canonical case study in shadow AI, and the crisis was, at root, a discovery and inventory failure.

What OpenClaw is

OpenClaw is a self-hosted, local-first autonomous agent. It runs on a user's own machine, connects to chat channels like WhatsApp, Telegram, Slack, and Signal, keeps a Markdown-based memory, and operates on an autonomous heartbeat daemon that wakes up and acts without a human prompting each step. Its adoption pattern tells the story: bottom-up, by enthusiasts, for productivity, not through any procurement or security-review process - often on always-on machines like Mac minis.

That adoption pattern is the whole story. OpenClaw installs itself with broad access - shell execution, browser automation, file and inbox access - and connects to external communications, all under the user's own credentials and entirely outside the security team's view. It is the textbook definition of shadow IT, ported to the agent era. We have written about why AI agents are the new shadow IT; OpenClaw is that argument made concrete at scale.

The anchor flaw: CVE-2026-25253

The verified anchor of the crisis is CVE-2026-25253, a one-click remote code execution flaw rated CVSS 8.8 (HIGH) with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H and classified as CWE-669 (incorrect resource transfer between spheres). It affects OpenClaw before 2026.1.29 and is documented by NVD, MITRE, and GitHub Advisory GHSA-g8p2-7wf7-98mq, with vendor and third-party write-ups from SonicWall, runZero, and others. It was first addressed in 2026.1.29 (released around January 29-30, 2026), with public disclosure on February 3.

The mechanics are a clean example of trusting attacker-controlled input across a trust boundary. The Control UI reads a gatewayUrl value from the page's query string and automatically opens a WebSocket to that URL - sending along the stored gateway authentication token. An attacker who lures a victim into opening a crafted link harvests that token, then connects directly to the victim's instance, can rewrite config such as sandbox and tool policies, and invokes privileged actions.

The detail that makes this severe: it works even against localhost-only deployments. Many users assumed that binding OpenClaw to 127.0.0.1 kept it private. But the victim's own browser initiates the outbound connection, so an external attacker never needs to reach the listener directly - the browser carries the token out. "Localhost" was never a security boundary here.

The victim's browser does the attacker's networking. Binding to localhost did not help, because the leak rode an outbound connection the victim's own client initiated.

The initial 2026.1.29 fix added a confirmation prompt whenever gatewayUrl changes, deterring the silent one-click path; later releases added stricter origin and host validation. This is the same class of failure we see across AI tooling: agent-readable input transmitted ahead of an explicit trust decision. It rhymes with the MCP-configuration auto-execution flaws covered in securing AI coding agents and CLIs, and it is exactly the kind of authentication-handling defect a generic network or EDR control will not flag, because the traffic looks like the agent doing its normal job.

ClawHavoc: the skill supply chain

OpenClaw's power comes from skills - third-party extensions distributed through a marketplace called ClawHub. Skills are the agent-era equivalent of npm or PyPI packages, and they inherited the same supply-chain problem, made worse by a near-absent publishing bar: the only requirement to publish was a GitHub account at least a week old, with no code review or scanning. Koi Security audited all 2,857 skills on ClawHub and found 341 malicious ones. Of those, 335 belonged to a single coordinated campaign, which researchers named ClawHavoc.

The skills posed as legitimate tools - crypto wallets, trading bots - and socially engineered users into installing "prerequisites" via ClickFix-style prompts that delivered the Atomic macOS Stealer (AMOS). Once running, they exfiltrated browser credentials, keychains, Telegram data, SSH keys, crypto wallets, and, crucially, the tokens stored in ~/.clawdbot/.env. Some skills carried reverse-shell backdoors for persistent access, and the campaign also targeted Windows hosts.

Note the number. Koi's audited, authoritative figure is 341; later reporting expanded the scope to 824 or 1,184 malicious skills as scanning widened beyond the initial audit, so those larger counts reflect a broader window rather than a contradiction. ClawHavoc is, in effect, a typosquatting-and-trojan campaign moved up one layer of abstraction - from code dependencies to agent skills. The defensive playbook is the same one we describe in the AI supply chain attacks defenders guide, and it sits in the same family as the Shai-Hulud npm worm: the package surface is now the agent's tool surface.

The Moltbook breach

Moltbook was a social network built for OpenClaw agents to interact with each other. Its Supabase backend was left unsecured in one of the most basic ways possible: Row Level Security was disabled and the publishable key was embedded in the client-side JavaScript, so anyone could read the key from the page and query the agents table directly.

The exposure leaked roughly 35,000 emails and about 1.5 million agent API and claim tokens across more than 32,000 registered agents, and private messages reportedly contained plaintext provider API keys. Researcher Jameson O'Reilly (Dvuln) documented the misconfiguration and demonstrated full account takeover. With those tokens, an attacker could act as any agent - issuing commands and reading data under the agent's identity. The breach is a reminder that agent identity is non-human identity, and that agent tokens are credentials that need the same inventory, rotation, and least-privilege treatment as any other secret.

The exposure numbers, with honest caveats

Here is where careful sourcing matters most. The widely cited 135,000 figure is real and traces to a primary scanner: SecurityScorecard's STRIKE team reported 40,000+ exposed instances in its first 24-hour scan window, then 135,000 later the same day as its dashboard methodology expanded - both numbers are genuine and measure slightly different things. The figures that come from scanners are these:

So the honest framing is: tens of thousands to low-six-figures of unauthenticated OpenClaw control panels were reachable on the public internet, and roughly a third of those were exploitable for RCE. The 135,000 headline is a defensible primary-sourced peak from STRIKE's expanding measurement; the 220,000 and 245,000 numbers that circulate in secondary blogs are not backed by any scanner and should be treated as unverified.

The 138-CVE claim, precisely

The widely repeated "138 CVEs" figure traces to a live tracker maintained by security engineer Jerry Gamblin (github.com/jgamblin/OpenClawCVEs), which reconciles GitHub advisories with CVE publication status and accounts for the project's prior names. The 138 was an April 6, 2026 snapshot over a roughly 63-day window - about 2.2 per day - and it mixes published CVEs with advisories still awaiting CVE assignment, so it is best read as an advisory count, not 138 formally assigned NVD identifiers.

Either way, the volume is real and the velocity is the actual story; the patch lag - tens of thousands of instances still unpatched after fixes shipped - is what turned a flaw into a crisis. A high CVE count on a young project is not automatically damning, but a high count combined with a self-installed, unmanaged footprint and no central patch path is exactly the combination that produces sustained exposure.

How this maps to agentic-AI threat frameworks

OpenClaw is a near-perfect specimen of the failure modes the field has already named. It combines all three elements of Simon Willison's lethal trifecta (June 16, 2025): private-data access, exposure to untrusted content, and external communication. Once an agent has all three, prompt-injection-driven exfiltration becomes trivial - there is nothing left to stop tainted instructions from turning data access into a send.

• Lethal trifecta (Willison): OpenClaw has private data, untrusted content, and external comms by default.
• OWASP Top 10 for LLM Applications 2025, LLM01 Prompt Injection (#1): untrusted content reaching an agent with tools is the primary risk class - see the OWASP Top 10 for LLM applications guide.
• OWASP LLM06 Excessive Agency: excessive functionality, permissions, and autonomy - OpenClaw's broad access and heartbeat daemon are the textbook example.
• MCP / skill supply chain: third-party skills are the new unvetted dependency surface; ClawHavoc is the agent-era trojan campaign - background in the MCP server security complete guide.

Concrete controls for a security team

The response to OpenClaw is the response to any shadow-AI sprawl, in order: find it, contain the known flaws, then govern it continuously. Patching alone does not help if you do not know where it runs.

1. Discover every instance. Search the fleet for OpenClaw, Clawdbot, and Moltbot processes, listening ports (default TCP/18789), and the ~/.clawdbot/ directory - on laptops and servers alike. Most were self-installed without security review, so an asset list will not show them.
2. Patch and de-expose. Upgrade anything before 2026.1.29 to close CVE-2026-25253, and remove any instance reachable from the public internet. Do not rely on localhost binding - it did not stop the token leak.
3. Audit installed skills. Inventory every ClawHub skill in use and remove anything matching the ClawHavoc campaign or any skill that asks users to install out-of-band 'prerequisites'.
4. Rotate exposed credentials. Force-rotate any token stored in ~/.clawdbot/.env and any agent token that touched Moltbook, and treat exposed emails as phishing targets.
5. Constrain identity and scope. Move agent-to-service auth to OAuth 2.1 + PKCE with least-privilege, scoped tokens rather than one high-privilege identity, and require human-in-the-loop approval on exfiltration-capable actions (outbound HTTP, email and chat sends).
6. Monitor behavior and keep a record. Apply policy gating to the heartbeat daemon's actions, and route every permission change and anomaly into an audit trail your GRC team can query.

Where continuous agent and MCP visibility fits

Strip away the individual flaws and the OpenClaw crisis has one shape: organizations had no idea how many instances, skills, tokens, or permissions existed inside their walls. Every control above depends on a prior answer - what do we have, and what can it do - and that answer did not exist. This is the exact gap the Anomity category addresses: continuous discovery and inventory of every AI agent and MCP server across the fleet, vetting of skills and tools against a supply-chain feed (the layer that would surface a ClawHavoc), an inventory of agent tokens and the permissions behind them, behavior and anomaly monitoring on autonomous daemons, and an audit trail for GRC.

Anomity complements the network, EDR, DLP, and GRC tooling you already run; it covers the agent and MCP layer those tools were never built to inventory. OpenClaw is simply the most public proof of the principle behind the whole category: you can't govern what you can't see. For the broader pattern, see AI agents are the new shadow IT and the AI supply chain attacks defenders guide; when you are ready to inventory and govern agents across your fleet, request early access.