CVE-2026-35639: 
OpenClaw (formerly Moltbot or Clawdbot) vulnerability analysis and mitigation

CVE-2026-35639 is a privilege escalation vulnerability in OpenClaw (npm package) affecting all versions before 2026.3.22. The flaw resides in the device.pair.approve gateway method, which fails to validate that an approver's operator scopes are sufficient to authorize the scopes requested by a pending device pairing. An authenticated attacker holding only the operator.pairing scope can escalate to operator.admin and achieve remote code execution on the Node infrastructure. It carries a CVSS v3.1 base score of 8.8 (High) and a CVSS v4.0 base score of 8.7 (High) (Github Advisory, Feedly). The vulnerability was disclosed on March 24, 2026, and patched in version 2026.3.22.

The root cause is classified as CWE-648 (Incorrect Use of Privileged APIs) and CWE-269 (Improper Privilege Management): the device.pair.approve handler in src/gateway/server-methods/devices.ts did not thread the caller's session scopes into the approveDevicePairing() function, meaning no check was performed to ensure the approver held every scope being granted to the new device (GitHub Commit). An attacker with a low-privilege operator.pairing token can submit a device.pair.approve RPC request over WebSocket, specifying a pending device request that includes the operator.admin scope; because the server never compared the requested scopes against the caller's scopes, the approval succeeds and the new device receives admin-level access. The fix adds a resolveMissingRequestedScope() check in src/infra/device-pairing.ts that rejects any approval where the requested scopes exceed the approver's held scopes, returning a forbidden status with the specific missing scope (GitHub Commit, Github Advisory).

Successful exploitation allows an authenticated low-privilege operator to escalate to operator.admin, granting full administrative control over the OpenClaw gateway and its Node infrastructure. This results in high impact to confidentiality, integrity, and availability — an attacker can read sensitive configuration and credentials, modify system state, execute arbitrary code on the Node host, and disrupt service availability (Feedly, Github Advisory). The scope of impact is limited to the vulnerable system itself (no lateral movement to subsequent systems is indicated by the CVSS scoring), but RCE on the gateway node could expose all connected channels, agent configurations, secrets, and plugin data.

The vulnerability requires low-level authenticated access (operator.pairing scope) and no user interaction, making it straightforward to exploit for any operator-level account holder. No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time (Feedly). The EPSS score is approximately 0.268%, indicating a low but non-negligible probability of exploitation in the near term. The vulnerability is not listed in the CISA KEV catalog. No threat actor attribution has been reported.

1. Obtain low-privilege credentials: Acquire or register an account with operator.pairing scope on a target OpenClaw gateway running a version before 2026.3.22.
2. Initiate a device pairing request: Using a controlled device identity, call requestDevicePairing (or submit a pairing request via the gateway API) specifying role: "operator" and scopes: ["operator.admin"] — scopes that exceed what the attacker's session holds.
3. Connect to the gateway WebSocket: Establish a WebSocket connection to the gateway (e.g., ws://<target>:<port>) and authenticate using the operator.pairing-scoped device token via the connect handshake.
4. Send the device.pair.approve RPC: Transmit a JSON-RPC request for device.pair.approve with the requestId of the pending device request created in step 2. Because the vulnerable server does not validate that the caller's scopes cover the requested operator.admin scope, the approval succeeds.
5. Authenticate as the newly approved admin device: Use the newly paired device's credentials (which now carry operator.admin scope) to reconnect to the gateway with full administrative privileges.
6. Achieve RCE: Leverage operator.admin access to execute commands on the Node infrastructure through available administrative gateway methods or plugin/agent execution surfaces (Github Advisory, GitHub Commit).

• Network: Unexpected WebSocket connections to the OpenClaw gateway from IP addresses not associated with known operator devices; device.pair.approve RPC calls originating from sessions authenticated with only operator.pairing scope.
• Logs: Gateway logs showing a device pairing approved entry where the approved device role is operator with operator.admin scope, but the approving session held only operator.pairing; absence of a missing scope error in the approval flow on unpatched versions.
• Application State: Newly paired devices appearing in the paired device list with operator.admin scope that were not explicitly authorized by a legitimate admin; unexpected new device IDs in the gateway's device pairing state file.
• Process: Unusual child processes or outbound network connections spawned from the OpenClaw Node process following a device pairing event, potentially indicating post-exploitation RCE activity (Github Advisory).

Upgrade OpenClaw (npm) to version 2026.3.22 or later (the fix is also present in v2026.3.23 and v2026.3.23-2). The patch tightens the device.pair.approve handler to pass caller scopes into approveDevicePairing() and rejects any approval where the requested scopes exceed the approver's held scopes (GitHub Commit, Github Advisory). As an interim measure, audit all existing paired devices and revoke any with operator.admin scope that were not explicitly approved by a legitimate admin. Restrict the operator.pairing role to the minimum set of trusted users and monitor gateway logs for anomalous device approval activity.

The vulnerability was reported by researcher @zpbrent and the advisory was published by steipete on the OpenClaw GitHub repository (Github Advisory). A duplicate advisory (GHSA-r3v5-2grc-429h) was published and subsequently withdrawn on April 10, 2026, with a pointer to the canonical advisory GHSA-hf68-49fm-59cq (Feedly). VulnCheck independently catalogued the issue. No significant broader media coverage or notable community debate has been identified beyond standard CVE tracking sites.