OpenClaw Security: The Problems and How to Fix Them
OpenClaw has had three CVEs in 2026, a coordinated malware campaign on ClawHub, and over 135,000 exposed instances. Here is what went wrong and what you should do about it.
OpenClaw Security: The Problems and How to Fix Them
I like OpenClaw. I use it daily. But the security situation is bad enough that I think every user needs to understand what's going on and take specific steps to protect themselves. This isn't FUD. These are real CVEs, real attacks, and real data exfiltration happening right now.
The CVEs
CVE-2026-25253: One-click remote code execution. This is the worst one. OpenClaw's WebSocket interface didn't validate the origin header, which meant any website you visited could connect to your running agent and execute commands. You open a malicious webpage, it connects to your local OpenClaw instance, and now an attacker has shell access to your machine through your agent. SecurityScorecard found 135,000 exposed instances. Think about that number.
CVE-2026-27646: Sandbox escape. Disclosed March 23, 2026, this one affects all versions before 2026.3.7. The /acp spawn endpoint could be used to break out of any sandbox restrictions and run arbitrary code with the full permissions of the OpenClaw process. If you were relying on OpenClaw's limited sandboxing or even NemoClaw's OpenShell, this bypassed it.
CVE-2026-26322: Server-side request forgery. The Gateway tool had an SSRF vulnerability with a CVSS score of 7.6. An attacker could use it to scan internal networks, hit internal APIs, and access services that should never be reachable from outside. If your OpenClaw instance was on a corporate network, this could be used as a pivot point.
The ClawHavoc campaign
Starting January 27, 2026, researchers began tracking a coordinated attack campaign on ClawHub, the skill marketplace. They found over 1,184 malicious skills uploaded across multiple accounts. The campaign used several techniques:
Staged downloads. The skill looks harmless at first. It does what it claims. But after a delay or a certain number of uses, it pulls down a second-stage payload that does the actual damage.
Reverse shells via Python. Many of the malicious skills contained obfuscated Python code that opened reverse shells back to attacker-controlled servers. Once connected, the attacker had interactive access to the victim's machine.
Direct data grabs. Some skills just immediately exfiltrated interesting files. SSH keys, browser credential stores, environment variables with API keys.
macOS targeting. A subset of skills deployed the Atomic Stealer payload specifically on macOS. This thing grabs browser credentials, Keychain data, SSH keys, and cryptocurrency wallet files. If you were running OpenClaw on a Mac with a hot crypto wallet, this was specifically designed to empty it.
Social engineering in READMEs. Some malicious skills had fake "Prerequisites" sections in their README files that told users to run shell commands as part of setup. These commands installed backdoors.
MITRE published an ATLAS investigation into the campaign. Microsoft's security blog put out a post recommending that organizations treat OpenClaw as "untrusted code execution with persistent credentials." That's a damning assessment from two major security research groups.
What you should do
Here's the concrete list. Do all of these.
Update to version 2026.3.7 or later. This patches CVE-2026-27646 and CVE-2026-25253. If you're on an older version, you're vulnerable to one-click RCE. Update today.
Bind to localhost. Change your Canvas Host bind address from 0.0.0.0 to 127.0.0.1. This prevents network-adjacent attacks against the WebSocket and web interfaces.
Run in an isolated VM. Don't run OpenClaw on your main development machine with access to everything. Use a dedicated VM or container with only the files and network access the agent actually needs. If the agent gets compromised, the blast radius stays inside the VM.
Audit every ClawHub skill before installing. Read the source code. Check what files it accesses, what network calls it makes, what shell commands it runs. Look at the author's other skills. If anything looks off, don't install it.
Use dedicated credentials. Don't give OpenClaw your personal API keys for services. Create dedicated keys with minimal permissions, scoped to only what the agent needs. If the agent's credentials get stolen, the attacker gets limited access instead of your full account.
Monitor outbound network traffic. Watch what your OpenClaw instance is connecting to. Unexpected connections to unfamiliar IPs or domains are a red flag. Tools like Little Snitch on macOS or iptables logging on Linux can help.
Consider NemoClaw. If you're on Linux, NemoClaw's OpenShell sandbox, default-deny networking, and Privacy Router address most of these issues architecturally. It's alpha software with its own limitations, but the security posture is significantly better than bare OpenClaw.
Perspective
None of this means you shouldn't use OpenClaw. The functionality is genuinely useful. But the default security posture assumes a level of trust that the ecosystem hasn't earned yet. A marketplace with over a thousand malicious plugins is not a marketplace you can trust blindly.
Treat your OpenClaw agent the way you'd treat any process running untrusted code: isolate it, limit its permissions, monitor its behavior, and don't give it access to anything you can't afford to lose.
