Between March 18 and March 21, 2026, nine CVEs were publicly disclosed for OpenClaw. One scored a 9.9 out of 10 on the CVSS scale. Six were high severity. Two medium. One critical. Four days, nine holes, and a very uncomfortable spotlight on the self-hosting security model.
This isn’t a one-off event. The jgamblin/OpenClawCVEs tracker now lists 156 total security advisories, with 128 still awaiting CVE assignment. Belgium’s Centre for Cybersecurity issued a “Patch Immediately” advisory earlier in March for seven more CVEs in the Nextcloud Talk plugin alone, all scoring 9.2–9.4.
Here’s what happened, what each vulnerability does, and why the timing makes everything worse.
The Full Scorecard
| CVE | CVSS | Date | What It Does | Patched In |
|---|---|---|---|---|
| CVE-2026-22171 | 8.2 High | Mar 18 | Path traversal in Feishu media download → arbitrary file write | 2026.2.19 |
| CVE-2026-28460 | 5.9 Medium | Mar 19 | Allowlist bypass via shell line-continuation → command injection | 2026.2.22 |
| CVE-2026-29607 | 6.4 Medium | Mar 19 | Allow-always wrapper bypass → approve safe command, swap payload, RCE | 2026.2.22 |
| CVE-2026-32032 | 7.0 High | Mar 19 | Untrusted SHELL env variable → arbitrary shell execution on shared hosts | 2026.2.22 |
| CVE-2026-32025 | 7.5 High | Mar 19 | WebSocket brute-force, no rate limiting → full session hijack from browser | 2026.2.25 |
| CVE-2026-22172 | 9.9 Critical | Mar 20 | WebSocket scope self-declaration → low-priv user becomes full admin | 2026.3.12 |
| CVE-2026-32048 | 7.5 High | Mar 21 | Sandbox escape → sandboxed sessions spawn unsandboxed children | 2026.3.1 |
| CVE-2026-32049 | 7.5 High | Mar 21 | Oversized media payload DoS → crash the service remotely, no auth needed | 2026.2.22 |
| CVE-2026-32051 | 8.8 High | Mar 21 | Privilege escalation → operator.write scope reaches owner-only surfaces | 2026.3.1 |
The Worst One: CVE-2026-22172
A 9.9 CVSS score is about as bad as it gets. Here’s the mechanics.
When connecting to OpenClaw’s gateway via WebSocket using shared-token or password auth, the server lets the client declare its own scopes during the handshake. Log in as a regular user. Tell the server “I’m operator.admin.” The server says “okay.”
No exploit toolkit. No buffer overflow. No race condition. You just ask. Full administrative access — gateway operations, cron management, everything.
TheHackerWire called it a “self-declaration” vulnerability, which is a diplomatic way of saying the authorization check wasn’t there.
Patched in v2026.3.12 (March 13). If you’re running anything older, any authenticated user on your instance is one WebSocket message away from admin.
The Browser Attack: CVE-2026-32025 (“ClawJacked”)
Discovered by Oasis Security, this one is clever and deeply unsettling.
OpenClaw’s gateway had no rate limiting on authentication attempts from localhost. Sounds fine — until you remember browsers can open WebSocket connections to localhost. A malicious website you visit can:
- Connect to your local OpenClaw gateway
- Brute-force the password at hundreds of attempts per second
- Exploit the fact that localhost connections auto-approve device pairing
Full session access. Your agent compromised because you opened the wrong browser tab.
We covered ClawJacked in depth earlier — the March disclosure adds the CVE number and confirms the scope.
The Sandbox That Wasn’t: CVE-2026-32048
OpenClaw’s sandbox mode is one of the features people cite when arguing it’s safe to self-host. Turns out it had a fundamental flaw.
When a sandboxed session spawns a child process through sessions_spawn, OpenClaw failed to inherit sandbox restrictions. The child runs with sandbox.mode: off. A compromised sandboxed agent escapes confinement entirely — arbitrary code execution, data access, and DoS all on the table.
This is especially ironic given that NVIDIA built NemoClaw specifically to add better sandboxing around OpenClaw for enterprise use.
Two Ways Past the Same Boundary
CVE-2026-29607 and CVE-2026-28460 are thematically linked — both bypass OpenClaw’s command approval system, disclosed on the same day.
CVE-2026-29607 exploits the “allow always” feature. Approve a safe-looking wrapped command once, and the approval persists at the wrapper level, not the inner command. Swap the inner payload later → RCE without re-prompting.
CVE-2026-28460 bypasses the allowlist entirely using shell line-continuation characters. Different technique, same security boundary broken.
Together they demonstrate that OpenClaw’s human-in-the-loop approval model — one of its core safety claims — had fundamental implementation gaps.
The Patch Gap Problem
Here’s the timing detail that makes everything worse.
Several patches shipped weeks before the CVEs were published. Version 2026.2.22, which fixes five of the nine CVEs, released around February 22. The CVEs referencing it weren’t published until March 19–21. That’s nearly a month.
This is good practice from the OpenClaw team: fix the bug, ship the patch, then disclose. But it only works if people update. Most self-hosters don’t follow upstream releases daily. They wait for CVE publications, security advisories, or blog posts like this one.
Industry research suggests self-hosters take 1–4 weeks to apply non-critical patches after awareness. For these March 19 disclosures, many instances were exposed for a month after the fix existed. Some still are right now.
The Bigger Picture
This four-day flood isn’t an anomaly. It’s what happens when a project grows from enthusiast tool to infrastructure faster than its security surface can mature. OpenClaw went from 0 to 316,000+ GitHub stars in under five months. It runs with root-equivalent access on tens of thousands of machines.
The security establishment has noticed:
- Trend Micro published “CISOs in a Pinch: A Security Analysis of OpenClaw,” calling it root-access-equivalent with probabilistic-model risk
- Cisco labeled it “a security nightmare” for enterprise environments
- Microsoft released enterprise security guidance for OpenClaw deployments
- 42,900+ internet-exposed instances were found by researchers, with 15,200 vulnerable to RCE
And this is just one week. The 128 advisories still awaiting CVE assignment suggest the disclosure pipeline has months of backlog.
What to Do Right Now
1. Update immediately. At minimum, run v2026.3.12 or later. That covers the critical 9.9 scope escalation. Ideally, update to the latest release.
2. Bind the gateway to localhost. Don’t expose it on 0.0.0.0. Use Tailscale, SSH tunneling, or a reverse proxy with authentication.
3. Don’t rely on the sandbox alone. Until the sandbox inheritance fix (CVE-2026-32048) is verified in your version, assume sandboxed agents can escape.
4. Review your allow-always rules. The wrapper bypass (CVE-2026-29607) means old approvals may cover commands you didn’t intend.
5. Enable rate limiting on your gateway. The default configuration had none for WebSocket auth attempts.
6. Watch the CVE tracker. 128 advisories are still pending assignment. More CVE numbers are coming.
The Self-Hosting Tradeoff
None of this means OpenClaw is fundamentally broken. The project’s response time on patches has been fast — often same-day or next-day. The open-source model means every vulnerability gets public scrutiny and transparent fixes.
But the March flood makes one thing clear: self-hosting an AI agent that runs with system-level access is a continuous security commitment, not a set-and-forget deployment. If you’re running OpenClaw, you’re signing up to track upstream releases, apply patches promptly, and monitor advisories — indefinitely.
For many users, that’s a reasonable tradeoff. For others, it’s the argument for managed hosting. Either way, nine CVEs in four days is the kind of wake-up call that shouldn’t be ignored.
Sources: TryOpenClaw CVE Flood Analysis, NVD, TheHackerWire, Oasis Security, jgamblin/OpenClawCVEs