CVE-2026-32922: One API Call Hands Over Your Entire OpenClaw Gateway

Everyone running OpenClaw assumes their tokens are doing their job: limiting who can do what inside the system. The problem is that on affected versions, one of those low-privilege tokens could ask for a replacement and come back with full administrator power.

TL;DR: CVE-2026-32922 is a critical privilege-escalation vulnerability in OpenClaw's device.token.rotate function. A caller with only operator.pairing scope could rotate its token and receive a new operator.admin token instead. Patch to v2026.3.11 or later immediately.

What Happened

OpenClaw includes a function called device.token.rotate. The intended purpose is simple: replace an existing token with a fresh one.

The security failure was in how the new token's privileges were assigned.

On affected versions, OpenClaw did not properly preserve or enforce the original token scope during rotation. That meant a caller holding only limited operator.pairing scope could invoke the rotation function and receive back a fully privileged operator.admin token.

The easiest way to think about it is a building handing out replacement badges without checking what access level the original badge actually had. You turn in a visitor pass and receive the master key.

Once an attacker has an admin token, the rest of the gateway becomes reachable: device control, automation management, and remote actions across connected nodes.

Multiple reports tied the issue to a CVSS 9.9 severity rating under CVSS 3.1, with CVSS 4.0 scoring it at 9.4. Either way, this is in the highest-risk category.

Why This Matters

This is not just a bug in a secondary helper function. It breaks one of the most important assumptions in any permissioned system: that a restricted credential stays restricted.

If scoped tokens can promote themselves during a standard lifecycle operation, then the scope model is no longer a dependable boundary.

That matters even more in OpenClaw because admin scope can sit in front of:

• connected devices
• agents and automation flows
• tool execution surfaces
• sensitive local or business workflows

The issue also lines up with a broader pattern in recent OpenClaw disclosures: the platform is powerful because it centralizes control, and that same control becomes the blast radius when permission enforcement fails.

What To Do Right Now

1. Check your exact version

If you are running anything older than v2026.3.11, assume you are affected.

2. Patch immediately

Upgrade to v2026.3.11 or later. This same version also patches CVE-2026-22172, another critical OpenClaw privilege-escalation issue.

3. Review token exposure after patching

After updating, audit existing tokens and remove anything you do not actively need. If you rely on restricted-scope tokens, recreate them after the patch so your current inventory reflects the fixed permission model.

4. Enable authentication if you have not already

Published reporting around this disclosure noted a large population of internet-facing OpenClaw instances, including many running without authentication. Patching matters, but basic access control still matters too.

Key Takeaways

• CVE-2026-32922 is a critical OpenClaw privilege-escalation flaw in the device.token.rotate function.
• A low-privilege token could rotate into a full admin token on affected versions.
• The fix is in v2026.3.11 or later.
• The same update also patches CVE-2026-22172, another critical scope-boundary failure.
• Restricted tokens should be audited and recreated after patching so your live credentials reflect the corrected permission model.

OpenClaw's permission model only helps if the system enforces it during every lifecycle step, not just at token issuance. When rotation becomes an upgrade path, every supposedly limited credential becomes more dangerous than it looks.