
Bottom line first. The most widely repeated OpenClaw security rule — “if it only runs locally, it’s safe” — didn’t hold up against this vulnerability. Even with the gateway bound only to loopback (127.0.0.1), the moment the victim’s browser opened a connection from inside to outside, it went straight through. The door was locked; the mail slot wasn’t. This piece lays out how big the incident actually was, with dated numbers, what the community actually stopped trusting, which pieces of self-hosting advice in circulation are right and which are wrong, and where this operating setup itself actually stands on all of it.
🔴 What Actually Happened — In Dated Numbers
On January 29, 2026, OpenClaw patched CVE-2026-25253 (CVSS 8.8). The Control UI took the gatewayUrl value from the query string without validation, auto-connected via WebSocket, and sent the auth token along in the process. One malicious link was all an attacker needed.
What matters more is what came next. The official security advisory put it plainly — “This vulnerability works even on instances bound only to loopback, because it’s the victim’s browser making the outbound connection.” Even if the gateway itself was never exposed externally, once the browser becomes the bridge between inside and outside, none of that matters.
Right after the patch, exposure surveys poured in. Taken separately, the numbers look like different studies. In reality, it’s the same story, growing over hours.
| Point in time | Exposed / vulnerable instances | Source |
|---|---|---|
| SecurityScorecard initial search (title-match only) | 24,034 | SecurityScorecard |
| SecurityScorecard final published figure (favicon fingerprinting, 2026-02-09) | 40,214 (42.9K unique IPs, 82 countries) · 15.2K RCE-vulnerable · 53.3K correlated with prior breaches | SecurityScorecard |
| The Register’s report (same day, a few hours after the STRIKE report) | 135,000+ · RCE-vulnerable up from 12,812 to 50,000+ | The Register |
The Register called out that jump directly — the 135,000+ figure as of its writing was, by its own account, a gap of just a few hours from the roughly 40,000 the STRIKE report showed the same day. RCE-vulnerable instances climbed from 12,812 to over 50,000 in the same window. “OpenClaw binds to 0.0.0.0:18789 by default — meaning it listens on every network interface, including the public internet” is stated directly in the SecurityScorecard report itself. In other words, exposure wasn’t the exception. It was the default.
😤 What the Community Actually Stopped Trusting
Trust didn’t collapse over one already-patched CVE. Three things stacked up.
First, exposure being the default configuration in the first place. Second, marketplace trust broke down. Security firm Koi found malicious skills on ClawHub, OpenClaw’s skill marketplace, and later reported that number climbing from 341 to 824 — AMOS keychain stealers, reverse shells, and typosquatting all mixed in.
Third, “patched” didn’t mean “done.” In April 2026, CVE-2026-44112 landed — a TOCTOU (time-of-check/time-of-use) race condition where a manipulated symlink in a sandbox filesystem write lets you write outside the boundary. Patched in 2026.4.22. CVSS scores diverge by source — NIST rates it 6.3 (MEDIUM), VulnCheck rates it 9.6 (CRITICAL) on 3.1 and 8.4 (HIGH) on 4.0. This piece isn’t going to referee which is right, but flattening that into one number wouldn’t be honest.
🧭 The Self-Hosting Advice Going Around — What’s Right, What’s Wrong
Start with the myth that broke. “Safe because it only runs locally” is, as shown above, just wrong in the face of this vulnerability. Loopback binding means nothing against an attack where the browser is the bridge.
Another piece of advice that circulates a lot — “just have the agent check its own configuration.” That’s reassurance dressed up as safety. The thing you’re handing the check to (the agent) is the exact thing whose trustworthiness is in question. A system auditing itself isn’t verification.
There’s advice that holds up, too. Security consultancy Oso’s self-hosting hardening principles: isolate on a separate machine, VM, or container; keep it off production networks; never expose the control plane directly to the internet — use a VPN, strong auth, and tight firewall rules instead (they mention Tailscale); put every tool behind an allowlist with deny-by-default; make read-only the default; turn off third-party skill auto-install/auto-load; and always have a way to kill it immediately.
🔧 Our Hardened Setup — Where It Actually Stands
This operation has been running OpenClaw over an SSH tunnel connecting a WSL2 gateway to a Mac Mini remote node. Checking it against the list above, point by point:

The gateway is bound only to loopback, and an auth token is required. A macOS LaunchDaemon keeps the SSH tunnel alive automatically, so there’s no path at all for the Mac Mini node to reach the WSL2 gateway’s WAN IP directly. That covers the “isolation” and “no WAN exposure” items on Oso’s list. But even this setup isn’t complete against what was confirmed above — loopback binding does nothing against a browser-bridge attack. This revision shortened the auth token rotation interval and turned off third-party skill auto-install. “A way to kill it immediately” is still manual, left as the next item to clean up.
🤔 So Is OpenClaw Actually Unusable?
There are three counterarguments worth being honest about.
First, “irredeemably broken” overreads the February panic. The 2026.1.29 patch genuinely shipped, and the official roadmap published May 15, 2026 (signed by core maintainer Jesse Merhi) spells out specifics: an fs-safe pattern library to stop boundary violations, Proxyline to control network outbound, a ClawHub quarantine system that auto-isolates confirmed-malicious releases, an exec approval system routing approvals through Slack, Telegram, or iMessage, and a 148-rule OpenGrep rule pack tied to advisories. This isn’t a team going quiet and waiting it out — it’s a published roadmap actually shipping.
Second, isolation has limits. No matter how tightly you scope a VM or container’s network boundary, none of it stops indirect prompt injection — malicious instructions hidden inside external content (a web page, an email, a document) that the agent trusts and pulls in, then executes. Isolation stops “this process from touching the rest of the system.” It doesn’t stop “this agent from being fooled.”
Third, VM-grade isolation isn’t free. Boot latency is measurably worse than a container’s — this research didn’t turn up a verified enough source to cite an exact multiplier, so no number is given here. What is clear: which profiles are worth paying that cost for, and which ones are fine with container isolation, are two different answers.
✅ So Which Isolation Tier Should You Actually Pick
Laying industry advice next to actual operating experience, the right tier splits by profile.
| Self-hosting profile | Recommended isolation tier | Key measures |
|---|---|---|
| Casual solo homelab (no external access needed) | Process/container isolation + loopback binding | Auth token required, ClawHub auto-install off, stay aware of browser-bridge attacks specifically |
| Always-on exposed service (remote access needed) | Container/VM boundary + VPN tunnel | No direct WAN binding, Tailscale/SSH tunnel, have a kill switch |
| Small team / production | Dedicated machine or full VM separation | Least-privilege API, signed skills only, anomaly-detection logging |
Whichever tier you pick, one thing holds across all of them — don’t use “it’s local, so it’s safe” as a security justification. That sentence already failed to protect against one real incident. What’s unverified should be stated as unverified — neither the VM latency multiplier nor 44112’s exact severity gets forced into a conclusion here.

📚 References
- NVD — CVE-2026-25253
- OpenClaw Official Security Advisory GHSA-g8p2-7wf7-98mq
- SecurityScorecard — Beyond the Hype
- The Register — OpenClaw instances open to the internet
- Koi — ClawHavoc
- NVD — CVE-2026-44112
- Oso — The Clawbot/Moltbot/OpenClaw Problem
- OpenClaw — Where OpenClaw Security Is Heading (2026-05-15)