On February 3rd, 2026, CVE-2026-25253 was publicly disclosed. The vulnerability had been quietly patched in OpenClaw version 2026.1.29, released on January 30th. But by the time the disclosure went public, Shodan scans had already found over 42,000 OpenClaw instances exposed to the internet. Sixty-three percent of them were running unpatched versions.
The vulnerability was classified as CWE-669: Incorrect Resource Transfer Between Spheres. In plain terms: OpenClaw's web interface trusted data it should not have trusted, from sources it should not have trusted, and the consequence was complete machine compromise through a single mouse click.
Here's exactly how it worked.
The Attack Chain
The attack exploits OpenClaw's Control UI — the web-based dashboard that users access to manage their instance. The UI connects to the OpenClaw gateway via WebSocket. The critical flaw: the UI reads the gateway URL from a URL parameter and connects to it automatically, without validating the origin.
Step 1: Crafting the malicious page.
The attacker creates a webpage containing JavaScript that opens a WebSocket connection. The page is hosted on any domain the attacker controls.
Step 2: Luring the victim.
The attacker sends the victim a link — in an email, a Slack message, a forum post, a social media DM. The link points to the attacker's page with a carefully crafted URL parameter that specifies the victim's OpenClaw gateway address.
Step 3: Token exfiltration.
When the victim clicks the link, their browser loads the attacker's page. The JavaScript on that page opens a WebSocket connection to the victim's OpenClaw gateway. Because the Control UI doesn't validate the Origin header on WebSocket connections, the gateway accepts the connection. The attacker's JavaScript extracts the authentication token from the WebSocket handshake.
Step 4: Full takeover.
With the authentication token, the attacker has full administrative access to the OpenClaw instance. They can execute arbitrary commands on the host machine, read and write files, access environment variables containing API keys, and install persistent backdoors.
The entire chain — from click to compromise — executes in milliseconds. The victim sees nothing unusual. They clicked a link and a webpage loaded. They have no indication that their AI agent, and by extension their machine, has been compromised.
Why This Vulnerability Existed
CVE-2026-25253 wasn't a subtle bug. Cross-Site WebSocket Hijacking has been a known vulnerability class since 2012. The fix — validating the Origin header on WebSocket connections — is documented in every web security guide. So why did OpenClaw ship with this flaw?
The answer lies in architectural decisions made early in the project's history.
OpenClaw's plugin ecosystem depends on the permissive WebSocket model. Third-party tools, browser extensions, and automation scripts all connect to the gateway via WebSocket. Validating the Origin header would break compatibility with tools that connect from different origins — which is precisely what the plugin ecosystem does.
The OpenClaw team knew about this. Internal issues dating back to early 2025 discuss the WebSocket trust model. The decision was to defer the fix because "changing the WebSocket authentication model would require a breaking change to the plugin API." Security was traded for backwards compatibility, and the trade went wrong.
This pattern — deferring security fixes to avoid breaking changes — is common in fast-growing open source projects. It's also how critical vulnerabilities accumulate. Each individual deferral seems reasonable. The compound risk grows silently until something breaks.
The Exposure Problem
The vulnerability alone would have been serious but manageable if OpenClaw instances weren't accessible from the internet. But they were. Over 42,000 of them.
OpenClaw's default configuration binds the gateway to 0.0.0.0 — all network interfaces, including public ones. The setup documentation doesn't prominently warn about this. Users who deploy OpenClaw on a VPS, a cloud instance, or any machine with a public IP address are immediately exposed.
Security researchers at SecurityScorecard's STRIKE team mapped the exposure across 82 countries. The highest concentrations were in the United States, Germany, China, and India — correlating with developer population density. Many exposed instances showed signs of corporate deployment: custom SSL certificates, internal hostnames, enterprise cloud provider IP ranges.
The implication: CVE-2026-25253 wasn't just a risk to hobbyists running OpenClaw on their laptop. It was a risk to companies that had deployed AI agents with access to internal systems, credentials, and data.
The Patch and Its Limitations
OpenClaw version 2026.1.29, released January 30th, addresses CVE-2026-25253 by adding Origin header validation to the WebSocket handler. Connections from non-whitelisted origins are rejected.
The patch works for the specific vulnerability. But it doesn't address the underlying architectural issues:
- •The gateway still binds to 0.0.0.0 by default
- •Skills still run with the same OS-level permissions as the OpenClaw process
- •The Node.js dependency tree still contains 1,200+ packages
- •Authentication still relies on bearer tokens rather than cryptographic pairing
CVE-2026-25253 was the vulnerability that got a CVE number. It wasn't the only attack surface. Between January and March 2026, OpenClaw accumulated 31 published CVEs including command injection, SSRF, path traversal, and prompt-injection-driven code execution. The WebSocket flaw was the door that opened; the missing security architecture was the reason there was nothing behind the door.
Architectural Lessons
The difference between "has a vulnerability" and "is fundamentally insecure" matters.
Every software project has vulnerabilities. The question is whether the architecture limits the blast radius when a vulnerability is found. A vulnerability in a system with proper sandboxing, least-privilege permissions, and defense in depth is a problem that gets patched. A vulnerability in a system with no sandboxing, full OS-level permissions, and a permissive trust model is a breach.
OpenClaw's architecture placed it in the second category. Not because of any single decision, but because of a pattern of decisions that prioritized developer experience and ecosystem growth over security constraints.
ZeroClaw's architecture makes different trade-offs. The deny-by-default allowlist, the Rust memory safety guarantees, the gateway pairing model, and the absence of a plugin marketplace don't make it invulnerable — nothing is invulnerable. But they limit the blast radius. A compromised ZeroClaw skill can't read files outside its workspace. A ZeroClaw gateway can't be connected to without a cryptographic pairing key. A ZeroClaw binary has no dependency tree to poison.
These aren't features bolted on after a crisis. They're constraints baked into the architecture from the first commit. And that distinction — security as architecture versus security as patches — is what CVE-2026-25253 taught the AI agent community.
What to Do Right Now
If you're running OpenClaw:
- 1.Update to version 2026.1.29 or later immediately
- 2.Check whether your gateway is exposed to the internet: `ss -tlnp | grep openclaw`
- 3.If it's bound to 0.0.0.0, change the bind address to 127.0.0.1 in your configuration
- 4.Audit your installed skills against the known-malicious list published by Koi Security
- 5.Rotate any API keys, tokens, or credentials that were accessible to the OpenClaw process
- 6.Consider whether your threat model still permits running a JavaScript-based AI agent with full OS permissions
If you're evaluating AI agent frameworks:
Ask three questions before anything else. What permissions does a skill or plugin get by default? What happens when a vulnerability is found — is the blast radius contained? And is the framework's default configuration secure, or does security require manual hardening?
The answers tell you more about a framework's security posture than any feature list.