March 2026 may go down as the month that broke OpenClaw’s security reputation. Not because any single vulnerability was unprecedented — but because they kept coming, week after week, targeting the same trust boundaries.

The Late-March Wave

In the final days of March, a cluster of critical vulnerabilities emerged in OpenClaw’s device pairing and authorization subsystems:

CVE-2026-32922 (CVSS 9.9) — The most severe. OpenClaw’s device.token.rotate function fails to constrain new token scopes to the caller’s existing scope set. A caller with only operator.pairing scope can request and receive a fully privileged operator.admin token. One API call later: remote code execution on all connected nodes. Detailed by ARMO.

CVE-2026-33579 (CVSS 9.8) — The /pair approve command path doesn’t validate whether the approving user’s privilege level actually permits the requested scopes. An authenticated attacker with existing pairing privileges can approve admin-level device pairing requests, bypassing scope validation entirely. Fixed in 2026.3.28.

CVE-2026-32916 (CVSS 9.4) — Plugin subagent routes execute gateway methods through a synthetic operator client that runs with broad administrative scopes. Remote unauthenticated attackers can invoke privileged actions including session deletion and agent execution. Published March 31, fixed in 2026.3.11.

CVE-2026-32042 — Unpaired devices can bypass the pairing approval workflow entirely and self-assign operator.admin scope by presenting a self-signed device identity through the shared gateway authentication mechanism.

CVE-2026-32049 — Denial of service via oversized media payloads that bypass configured size limits during remote media fetch operations across multiple channel ingestion paths.

CVE-2026-32979 — Approval integrity bypass allowing execution of rewritten local code by modifying scripts between approval and execution phases.

The Pattern Is the Problem

These aren’t random bugs. They share a structural theme: OpenClaw’s authorization layer trusts what it shouldn’t.

  • Token rotation doesn’t validate scope subsets
  • Pairing approval doesn’t check approver authority
  • Plugin routes inherit admin-level synthetic clients
  • Unpaired devices can self-assign admin scope
  • Approval and execution phases aren’t atomically bound

A scopesAllow validation function exists in the codebase and is correctly used in verifyDeviceToken. The developers understood scope gating — they just didn’t wire it into every path that needed it. This is the classic security pattern: authorization logic that’s correct in one place and missing in another.

The Exposure Numbers

Multiple security research firms have surveyed the landscape:

  • 135,000+ publicly exposed OpenClaw instances (SecurityScorecard STRIKE team, February 2026)
  • 63% running without any authentication
  • 21,000+ confirmed on Shodan with zero auth
  • 17,500 verified with detailed fingerprints (Hunt.io)

These aren’t development instances. As ARMO’s analysis points out, OpenClaw instances “often accumulate significant privileges” — API keys for AI providers, integration tokens for messaging platforms, and persistent storage containing conversation histories and sensitive business context. In Kubernetes deployments, compromise of the gateway pod can expose cluster-level service account tokens.

The Full March Count

Adding the late-March wave to the mid-March “CVE flood” we covered earlier, the monthly total is staggering:

Mid-March (18-21):

  • CVE-2026-22172 (CVSS 9.9 critical)
  • CVE-2026-32025 (browser hijack)
  • CVE-2026-32048 (sandbox escape)
  • CVE-2026-29607/28460 (approval bypass pair)
  • Plus 4 additional CVEs

Late March (27-31):

  • CVE-2026-27183 (authentication bypass via boundary drift)
  • CVE-2026-32922 (CVSS 9.9 privilege escalation)
  • CVE-2026-33579 (CVSS 9.8 pair approve escalation)
  • CVE-2026-32916 (CVSS 9.4 auth bypass)
  • CVE-2026-32042 (unpaired device admin)
  • CVE-2026-32049 (DoS via media)
  • CVE-2026-32979 (approval integrity bypass)

That’s 15+ CVEs in a single month, with at least three scoring CVSS 9.4 or higher. For context, OpenClaw hit 340,000+ GitHub stars during this same period.

What OpenClaw Users Should Do Now

Immediate:

  1. Update to 2026.3.28 or later (covers all known fixes)
  2. Verify your instance requires authentication (openclaw status)
  3. Review paired devices and their scopes
  4. Check if your instance is publicly exposed

Ongoing: 5. Don’t expose OpenClaw’s gateway port (18789) to the internet without a VPN or reverse proxy 6. Enable exec approvals — don’t set them to “off” 7. Monitor for unexpected device pairing requests 8. Consider DefenseClaw for sandboxing if you’re running in production

The Bigger Picture

OpenClaw’s feature velocity is extraordinary — it’s the most-starred software repo on GitHub, with a new release nearly every week. But security hardening isn’t keeping pace with feature development. The device pairing system alone has produced four critical CVEs in March, each exploiting a different gap in the same trust model.

This isn’t unique to OpenClaw. It’s the structural tension of every fast-growing open-source project: the faster you ship, the more attack surface you create. The difference is that OpenClaw runs with system-level access on users’ machines, making every authorization bypass a potential RCE.

The community and OpenClaw’s maintainers have been responsive — fixes ship quickly, advisories are published transparently, and the project’s security culture is improving. But the March CVE count is a signal: the attack surface has outgrown the current security architecture, and incremental patches may not be enough.

If you run OpenClaw, update today. If you expose it to the internet, reconsider that decision.