TL;DR

We discovered a vulnerability (CVSS 4.8, Medium) in OpenClaw's device pairing system that allows legacy paired devices to retain their access roles even after administrators attempt to revoke them. The affected code path returns persistent role metadata for any device that predates OpenClaw's token tracking system, rendering standard revocation ineffective. The OpenClaw team confirmed the finding and shipped a patch within 24 hours of disclosure.

What is OpenClaw, exactly?

OpenClaw is a device pairing and authorization platform that lets operators control which devices can connect to their infrastructure and what those devices are allowed to do. Its trust model is built around a review-and-approve flow: an untrusted device requests pairing with specific scopes, an operator approves it, and the device receives a token encoding its permitted role. On every reconnect, the token is verified to ensure the device does not exceed its approved access level. It is a clean model in principle. The problem we found lies in what happens when a device has no token.

How device pairing works

OpenClaw's pairing architecture has two classes of paired devices. Newer devices operate under active token tracking. When they connect, the platform derives their effective roles from their token state. If a token is revoked, the device loses its roles on the next access check. Legacy devices, those paired before token tracking was introduced, have no token state. Their access roles are stored directly in the device record's persistent roles field. This distinction is the source of the vulnerability.

The vulnerability

The flaw lives in listEffectivePairedDeviceRoles() inside src/infra/device-pairing.ts, around line 182.

For devices with a token state, this works correctly. The function derives roles from the token, and revocation works as expected. For devices without a token state, the function falls back to returning paired roles directly from the device record. Now consider what happens when an administrator calls revokeDeviceToken() against a legacy device. There is no token to revoke. The revocation call completes without error. On the next access check, listEffectivePairedDeviceRoles() still returns the persistent roles from the device record. The device reconnects and retains full access as if nothing happened.

Root cause: The revocation mechanism targets the token state only. It has no visibility into the fallback path. Legacy devices without token state are invisible to it, and the fallback path returns their original access roles regardless of any administrative action taken against them.

Impact

Any paired device that predates OpenClaw's token tracking cannot be deactivated through standard revocation. Its roles persist indefinitely. The security implication is not just technical. Administrators who call revokeDeviceToken() believe they have removed a device's access. They have not. The device remains active and authorized. The gap between what the administrator believes to be true and what is actually true is the real risk here. The exposure increases in deployments where legacy devices were assigned elevated roles during initial pairing and have never been re-paired. Those devices carry those roles permanently, with no way to remove them through the platform's standard controls.

The medium score reflects the limited population of affected devices. The security implication, however, is significant regardless of score: an administrative control that appears to work does not.

The fix

The OpenClaw team reviewed the report, confirmed the finding, and shipped a patch on April 10, 2026, one day after disclosure. The fix removes the fallback path entirely. Legacy devices without token state now return no effective roles, failing closed rather than failing open with stored historical permissions.

"This was a useful hardening item," the OpenClaw team noted in their response. "Tokenless legacy paired records previously fell back to stored role metadata. We removed that fallback, so tokenless legacy records now fail closed with no effective roles."

What administrators should do

Update to the patched version immediately if your deployment includes paired devices that predate token tracking. After updating, legacy devices that were previously unrevocable will lose their persistent roles. If continued access is intended for any of those devices, they will need to be re-paired through the standard pairing flow. To check whether your deployment is affected, look for paired device records with a populated roles field alongside an empty or missing tokens array. Any such record is a legacy device subject to this issue.

Disclosure timeline

This vulnerability was discovered by the Unosecur security research team during a code review of OpenClaw's device pairing and authorization infrastructure.
PS: Proof of general responsible disclosure-