CVE-2026-32922: Critical Privilege Escalation in OpenClaw – What Cloud Security Teams Need to Know

The adoption of personal AI assistants is on the rise. everywhere. Developers, power users, and in a few cases, entire teams self-host them to connect messaging apps, automate tasks, and interact with AI models across their infrastructure. But when these self-hosted gateways become compromised, the blast radius can extend far beyond a single user’s chat history.

On March 29, 2026, a critical privilege escalation vulnerability was published in OpenClaw, the massively popular open-source AI assistant platform with over 340,000 GitHub stars. CVE-2026-32922 scores 9.9 on CVSS 3.1 and 9.4 on CVSS 4.0, making it one of the most severe vulnerabilities disclosed in the cloud-native ecosystem this year.

The flaw sits in OpenClaw’s device.token.rotate function, which fails to constrain newly minted token scopes to the caller’s existing scope set. A caller holding only the limited operator.pairing scope can invoke this function and receive back a fully privileged operator.admin token. From there, remote code execution on all connected nodes is one API call away.

With over 135,000 internet-facing OpenClaw instances detected in February 2026, 63% of which run without authentication, the blast radius is substantial. The fix shipped in version 2026.3.11 on March 13, 2026, but exploitation intelligence is still developing.

Why This Matters Right Now

OpenClaw (formerly known as Moltbot and Clawdbot, created and maintained by Peter Steinberger) is a unified gateway that connects messaging platforms like WhatsApp, Telegram, Slack, Discord, and Signal to AI models like Claude, GPT, and Gemini. It runs as a single gateway process on the default port 18789 and serves as the control plane for all messaging channels, CLI tools, web interfaces, and mobile apps.

OpenClaw is a personal AI assistant, not a traditional infrastructure orchestration platform. But it includes a sophisticated device-pairing and token-management subsystem that handles role-based access control across connected clients. Devices connect via a challenge-response pairing protocol, and the gateway assigns scoped tokens with roles including operator.admin, operator.read, operator.write, operator.pairing, and operator.approvals.

The project has a small, but fast growing cloud-native footprint as well:

• Official Kubernetes documentation and Helm charts
• A community-built Kubernetes operator with CRDs
• Terraform deployment modules
• An NVIDIA sandbox wrapper (NemoClaw)
• A Cloudflare worker for edge deployments

Despite being a personal tool, OpenClaw instances often accumulate significant privileges:

• API keys and credentials for AI providers (OpenAI, Anthropic, Google) stored in environment variables
• Integration tokens for messaging platforms and SaaS systems
• Internal network reachability to downstream services when self-hosted on corporate infrastructure
• Persistent storage containing conversation histories, session data, and potentially sensitive business context

This is what makes OpenClaw a security concern for cloud security teams even though it is a personal tool. Developers and engineers self-host it on company networks, on cloud VMs, inside Kubernetes clusters, and on their own machines. It often flies under the radar of security teams entirely, making it a classic shadow IT risk with real infrastructure access.

Technical Breakdown: The Missing Scope Check

The root cause of CVE-2026-32922 is a missing scope validation check in the rotateDeviceToken function located in openclaw/src/infra/device-pairing.ts (lines 289-312).

The function accepts a scopes parameter from the caller and passes it directly to buildDeviceAuthToken without verifying that the requested scopes are a subset of the caller’s own scope set.

Importantly, a scopesAllow validation function exists in the codebase and is correctly used in verifyDeviceToken. This proves the developers understood the need for scope gating. But the validation was never wired into the rotation path.

The CWE classification is CWE-266 (Incorrect Privilege Assignment) per the CVE record and CWE-269 (Improper Privilege Management) per the GitHub Security Advisory.

The Attack Chain

The exploitation proceeds in four steps.

Step 1: Obtain a low-privilege token. The attacker acquires a token with operator.pairing scope. This can happen through legitimate device pairing or by compromising an existing paired device.

Step 2: Call device.token.rotate. The attacker targets a device already approved for operator.admin and specifies [“operator.admin”, “operator.read”, “operator.write”] in the scopes parameter.

Step 3: Receive an unrestricted admin token. Because no intersection check runs against the caller’s scope set, the gateway mints and returns a valid operator.admin token.

Step 4: Achieve remote code execution. The attacker uses the escalated token to invoke system.run for arbitrary command execution on connected node hosts. Alternatively, the attacker gains full gateway-admin access to reconfigure the entire deployment.

What an Attacker Can Do with operator.admin

Once an attacker holds an operator.admin token, the impact is severe:

• Execute arbitrary commands on every connected node via system.run
• Install malicious skills through ClawHub (OpenClaw’s extension marketplace)
• Exfiltrate all conversation data and API keys stored in the gateway configuration
• Reconfigure exec approval settings to disable safety guardrails
• Pivot laterally across any infrastructure the nodes touch

In Kubernetes deployments using the community operator, compromise of the gateway pod could expose cluster-level service account tokens, node resources, and adjacent workloads. This is especially concerning because OpenClaw’s operator provisions StatefulSets with persistent storage containing sensitive credentials.

Who Is Affected and How to Determine Exposure

Affected Versions

Anyone running OpenClaw versions prior to 2026.3.11 is affected, whether as a personal AI assistant, a shared instance within a team, or a self-hosted deployment on corporate infrastructure. The vulnerability has been present in the codebase since the device pairing subsystem was introduced.

Elevated Risk Environments

The risk is elevated when OpenClaw instances are connected to cloud infrastructure or Kubernetes nodes, but even a personal instance running on a developer’s laptop can become an entry point if it holds API keys or is reachable on the network. The exposure data from multiple security research firms paints a concerning picture:

• SecurityScorecard’s STRIKE team identified 135,000+ publicly exposed instances in February 2026
• Hunt.io verified 17,500 instances with detailed fingerprints
• Shodan found 21,000+ running with zero authentication
• Across all surveys, 63% of exposed instances had no authentication configured at all

How to Check Your Version

Possible methods:

• OpenClaw web UI settings panel
• openclaw –version at the command line
• Container image tag
• Helm chart values
• npm list openclaw for npm-based installations

Exposure Assessment Checklist

Security teams should work through the following assessment.

Discover all OpenClaw instances across your environment. OpenClaw is a personal AI assistant that individual developers and team members may have spun up on their own. Check Kubernetes namespaces, Docker hosts, VM inventories, and developer workstations for OpenClaw gateway processes. Any version below 2026.3.11 is vulnerable.

Review which workloads or nodes are reachable from OpenClaw-managed gateways. Map the network topology. Identify what system.run can reach if an attacker gains operator.admin access.

Check whether operator.pairing tokens are issued to external or third-party callers. Run openclaw devices list to enumerate all paired devices and their scope assignments. Any device with operator.pairing scope represents a potential entry point.

Audit token scope policies. Verify that token scopes follow the principle of least privilege. Look for devices that have been granted broader scopes than necessary for their function.

Check for evidence of prior exploitation. Review gateway logs for device.token.rotate calls where the requesting session had only operator.pairing scope but the request specified operator.admin in the scopes array. Watch for unexpected system.run invocations from device identities that should not have administrative access.

Remediation: Prioritized and Concrete

Immediate Action

Upgrade to OpenClaw v2026.3.11 or later. This is the definitive fix.

The current stable release is v2026.3.23-2, and the community security monitor project recommends a minimum of v2026.3.21 as the hardened baseline.

Upgrade via:

(npm install openclaw@latest)

Verify with:

(openclaw --version)

If Immediate Patching Is Not Possible

Apply layered mitigations.

Revoke all operator.pairing tokens and disable the pairing endpoint entirely. This eliminates the attack entry point at the cost of preventing new device pairing.

Bind the gateway to localhost only. Run openclaw config set gateway.bind localhost to prevent external access.

Apply firewall rules to block external access to port 18789. This is especially critical for instances that have been running without authentication.

Run a security audit. Execute openclaw security audit –deep to flag scope misconfigurations across all paired devices.

Detection Guidance

Detection should focus on several indicators.

Log-based detection. Monitor gateway logs for device.token.rotate calls originating from sessions with only operator.pairing scope. Alert on any request that specifies operator.admin in the scopes array. Watch for configuration changes via config.get, config.patch, or sessions.delete from non-admin devices.

Network-level detection. Scan for OpenClaw instances on port 18789 using HTML title fingerprints (“OpenClaw Control”, “Clawdbot Control”, “Moltbot Control”). Monitor mDNS broadcasts on _openclaw-gw._tcp.

Post-exploitation indicators. Look for unauthorized modifications to ~/.clawdbot/.env, unexpected skill installations in the extensions/ directory, and changes to exec approval settings.

Post-Patch Hygiene

After upgrading, assume potential exposure and conduct a review.

Recommended actions:

• Audit all paired device scopes
• Inspect execution logs for anomalous system.run calls
• Rotate all API keys and credentials accessible to the gateway
• Validate messaging platform tokens and integrations
• Review ClawHub skill installations for unauthorized additions

For Kubernetes deployments:

• Enforce network policies restricting gateway pod egress
• Minimize RBAC permissions on OpenClaw service accounts
• Audit persistent volume contents for credential exposure

Additional Fixes in v2026.3.11

Version 2026.3.11 also shipped several other security fixes worth noting:

Fix	Description
GHSA-5wcw-8jjv-m286	WebSocket browser origin validation
system.run hardening	Fail-closed enforcement for approval-backed interpreter commands
Plugin route scoping	Removal of synthetic admin scopes from unauthenticated plugin HTTP routes
Sandbox isolation	Session-tree visibility enforcement

Disclosure Timeline

Milestone	Date
GitHub Issue #20702 filed (by @coygeek)	February 19, 2026
Fix PR #20703 merged (commit fc2d29e)	March 13, 2026
GitHub Advisory GHSA-4jpw-hj22-2xmc published	March 13, 2026
Fix released (v2026.3.11)	March 13, 2026
CVE reserved by VulnCheck (CNA)	March 16, 2026
Sangfor FarSight Labs vendor alert	March 17, 2026
CVE published on cve.org	March 29, 2026
NVD entry created (awaiting analysis)	March 29, 2026

The vulnerability was reported by security researcher tdjackey. GitHub Issue #20702 contains a detailed exploitability proof with step-by-step reproduction and the exact vulnerable code path. The fix introduced a scopeIntersection function in src/routes/device-pair.js that enforces caller-scope subsetting.

The CVE is not yet listed in CISA’s Known Exploited Vulnerabilities catalog. However, no public proof-of-concept exploit exists specifically for CVE-2026-32922, but GitHub Issue #20702 contains reproduction steps detailed enough to function as one. The low exploitation complexity (a single authenticated API call) means weaponization is trivial.

The Broader Threat Context: OpenClaw Under Active Attack

CVE-2026-32922 does not exist in a vacuum. The OpenClaw ecosystem has been under sustained attack in 2026.

The ClawHavoc campaign distributed 341+ malicious skills via ClawHub that deployed the Atomic Stealer (AMOS) infostealer. Hudson Rock separately discovered Vidar infostealer variants targeting OpenClaw agent identities. The earlier CVE-2026-25253 (“ClawBleed”), a CVSS 8.8 one-click RCE via cross-site WebSocket hijacking, saw confirmed active exploitation.

This fits a clear 2025-2026 pattern of critical privilege escalation through token scope validation failures across the cloud-native ecosystem:

• CVE-2025-55241 in Microsoft Entra ID (CVSS 10.0) allowed cross-tenant token forgery through undocumented “Actor tokens,” enabling impersonation of any user including Global Administrators
• CVE-2025-5999 in HashiCorp Vault (CVSS 7.2) let privileged operators escalate to root policy by exploiting a normalization gap between validation and enforcement layers
• CVE-2026-23552 in Apache Camel’s Keycloak component (CVSS 9.1) silently accepted tokens from any Keycloak realm regardless of configuration due to missing issuer claim validation

The unifying theme is that logic bugs in token lifecycle management are now a dominant attack surface in cloud-native systems. Authentication, policy enforcement, and plugin execution can all be subverted through logic bugs without touching memory, triggering crashes, or breaking cryptography.

The Kubernetes Security Posture Connection

This vulnerability illustrates a broader issue in Kubernetes security.

Security teams often focus on exposed services, container image vulnerabilities, and admission policies. But internal platforms like AI agent gateways, workflow engines, and developer tools can become high-privilege entry points.

If compromised, these systems may perform actions that appear legitimate from a network perspective. An OpenClaw gateway making API calls, executing commands on nodes, and accessing secrets looks normal. An attacker abusing those same capabilities through a stolen operator.admin token looks identical.

Runtime detection becomes critical.

Tools such as ARMO’s eBPF-based runtime detection can help identify suspicious behavior originating from compromised workloads, including:

• Unexpected process execution (such as shells spawned by system.run on nodes that should not run arbitrary commands)
• Abnormal network connections from gateway pods to previously uncontacted endpoints
• Unauthorized file access, particularly to credential stores and configuration files
• Privilege escalation attempts through Kubernetes API interactions

These signals can reveal compromised AI agent gateways even when the attack originates from an authenticated user with a legitimately minted (but improperly scoped) token.

Final Thoughts

CVE-2026-32922 represents the most severe vulnerability in OpenClaw’s history. A single API call converts a pairing token into full administrative control with RCE capability. Three factors make this especially urgent: the project’s enormous scale (340k+ GitHub stars, 135k+ exposed instances), the minimal attacker prerequisites (any paired device with operator.pairing scope), and the maximum blast radius (complete compromise of the gateway and all connected nodes).

Security teams should act quickly:

1. Upgrade to OpenClaw v2026.3.11 or later immediately
2. Audit all paired device scopes for evidence of prior exploitation
3. Restrict gateway network exposure to localhost-only unless explicitly required
4. Implement runtime detection for anomalous command execution from gateway workloads

The broader lesson applies well beyond OpenClaw: token rotation endpoints are a critical and frequently under-validated attack surface across every cloud-native system managing scoped credentials. If your infrastructure includes any component that can mint, rotate, or refresh tokens, now is a good time to verify that scope constraints are enforced at every step of that lifecycle.

AI agent platforms are part of your production attack surface. Make sure they are defended accordingly.