OpenClaw device pairing flaw exposes persistent role revocation gaps

At a glance

What this is: This is a vulnerability analysis showing that OpenClaw’s legacy device records could bypass revocation and retain persistent access roles.

Why it matters: It matters because device identity governance fails when administrators believe access has been removed but legacy non-human identities still carry standing privilege.

👉 Read Unosecur's analysis of the OpenClaw device pairing revocation flaw

Context

Legacy device identities become a governance problem when revocation only applies to one state of the record and not to every place access is stored. In this case, OpenClaw’s device pairing model treated newer devices and older tokenless devices differently, which meant the control plane could report success while the device still retained access.

That is a familiar NHI failure mode: lifecycle intent and effective authorization drift apart. Once persistent roles live in a fallback record, revocation becomes a partial operation instead of a definitive one, and administrators lose reliable assurance about what is actually still active.

Key questions

Q: What breaks when revocation only applies to token state and not to legacy device records?

A: Revocation becomes incomplete, because the platform can report success while persistent roles still grant access from a fallback record. That leaves administrators with a false assurance that the device is disabled. The practical failure is not the revoke action itself, but the existence of another authorisation source that remains in effect after the control has run.

Q: Why do legacy device identities increase the risk of access persistence in NHI environments?

A: Legacy device identities often predate current lifecycle controls, so their permissions may be stored in formats that modern revocation logic no longer governs. When a platform has multiple entitlement sources, older records can remain active even after the current token is removed. That creates lingering access that is hard to detect through ordinary administration.

Q: How do security teams know whether device revocation is actually working?

A: They should test the full authorisation path, not just the revoke request. A working control must remove effective access from the next access check, including legacy records and fallback branches. If a token can be revoked but the device still returns roles, revocation is only partial and the lifecycle model is broken.

Q: Who is accountable when a device still has access after administrators believe it has been revoked?

A: Accountability sits with the owner of the authorisation model, because the control failed to define one authoritative source of effective access. In practice, that means IAM, platform, and engineering teams all need to verify which system is allowed to decide entitlement. If more than one state can grant access, ownership is already blurred.

Technical breakdown

Token-based device tracking versus legacy role persistence

OpenClaw’s design split paired devices into two classes. Newer devices derived effective access from token state, so revocation could remove access on the next check. Legacy devices predated token tracking and stored roles directly in the device record. That created two authorization sources, only one of which was visible to revocation. When a platform preserves historical permissions outside the token lifecycle, effective access becomes a property of storage history rather than current authorisation state.

Practical implication: inventory every identity path that can still grant access outside the current token lifecycle.

Why token revocation failed closed in name but open in practice

The vulnerable function, listEffectivePairedDeviceRoles(), used the token path when state existed, but fell back to persistent roles when it did not. revokeDeviceToken() therefore completed successfully even though nothing changed for tokenless legacy devices. The problem was not a missing revoke button. It was a fallback that treated absence of token state as permission to keep old access alive. In identity systems, fallback logic often becomes the real policy engine.

Practical implication: remove fallback paths that can reconstitute privileges from historical device metadata.

Failing open on tokenless legacy records

The patch removed the fallback path entirely, so tokenless legacy records now return no effective roles. That is a fail-closed model, which is the correct stance when the platform cannot verify current entitlement state. The deeper lesson is that legacy non-human identities are not just old objects. They are unmanaged authorization exceptions unless their lifecycle is explicitly re-bound to current control logic.

Practical implication: treat legacy device records as untrusted until they are re-paired under a single authoritative access source.

Threat narrative

Attacker objective: The objective is to preserve device access after revocation so an unauthorized or no-longer-trusted device remains active in the environment.

1. Entry occurs through a legacy paired device that predates token tracking and therefore has permissions stored in the device record itself.
2. Escalation happens when revocation is issued against the token state only, leaving the fallback roles untouched and still effective.
3. Impact is persistent device access that survives administrative revocation and can continue to interact with connected infrastructure.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Persistent device roles are not a revocation problem, they are a lifecycle integrity problem. This flaw worked because access was stored in more than one place, and revocation only touched one of them. The result was a false completion state in which administrators believed access had been removed while the device still retained effective roles. Practitioners should read this as a warning that NHI lifecycle governance fails when effective privilege can survive outside the authoritative token state.

Legacy non-human identities become governance exceptions the moment they outlive the control model that created them. OpenClaw’s tokenless devices were not just old records, they were identities whose permissions no longer matched the current authorisation system. That is a classic NHI drift pattern under OWASP NHI and NIST CSF access governance. The practitioner takeaway is that aged device identities must be reconciled against current entitlement logic, not treated as inactive by default.

Standing privilege hidden in fallback metadata is a named failure mode: persistent role inheritance. The platform inherited access from historical device records when current token state was unavailable, which meant privilege could survive without a live proof of entitlement. That is more dangerous than a simple missing revoke because it creates an illusion of control. Security teams should recognise this as a structural authorization drift issue, not merely a patchable bug.

Fail-closed behaviour is the only defensible outcome when device identity state is ambiguous. The patch removed the fallback and forced tokenless legacy records to return no roles at all. That change matters because ambiguous identity state should never be resolved in favour of access. For practitioners, the lesson is to re-evaluate any device, service account, or workload path that can infer privilege from historical data instead of current attestation.

From our research:

• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to The State of Secrets Sprawl 2026.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, which shows why detection without lifecycle closure leaves active exposure in place.
• For adjacent guidance, see NHI Lifecycle Management Guide for how provisioning, rotation, and offboarding need one authoritative state.

What this signals

Persistent role fallback is the broader pattern teams should watch. Once an identity system can derive access from historical metadata, revocation becomes a reconciliation problem instead of an enforcement control. For programmes using device pairing, service accounts, or workload identities, the question is whether current entitlement state is authoritative everywhere it matters.

The practical signal is simple: any environment that still has mixed token and non-token identity records should be treated as already carrying access drift. Teams should use the NHI Lifecycle Management Guide to reset the lifecycle model, and map the control design to OWASP Non-Human Identity Top 10 where persistent privilege and weak offboarding are already recognised failure modes.

Identity blast radius: the smaller the set of records that can still authorize access after revocation, the more defensible the programme becomes. That means device, secret, and workload identity governance need a single revocation state, not separate inherited paths that can silently preserve privilege.

For practitioners

• Find every legacy device record with mixed state Search for paired device entries that have stored roles but no active token state, and treat them as untrusted until revalidated or re-paired.
• Eliminate privilege fallback logic Review pairing and authorisation code paths for any branch that reconstructs access from historical metadata when the authoritative token state is missing.
• Re-pair devices under a single authority source Move every legacy paired device through the current pairing flow so the platform has one current source of truth for effective roles.
• Test revocation against missing-state records Validate that a revoke operation produces no effective roles when token state is absent, and confirm the control fails closed rather than silently preserving access.

Key takeaways

• The breach revealed a structural authorization drift problem, because legacy device records could keep effective roles after token revocation.
• Unosecur’s finding showed that a medium-severity issue can still leave persistent non-human access in place when fallback logic survives the current control model.
• The control that would have prevented the issue is fail-closed revocation tied to one authoritative access source, with legacy records re-paired or removed.

Key terms

• Device Pairing: Device pairing is the process of establishing a trusted relationship between a device and a control platform so the device can connect with defined scopes. In NHI governance, pairing should bind access to current entitlement state, not to historical metadata that can outlive revocation.
• Token Revocation: Token revocation is the act of invalidating an issued credential so it can no longer authorize access. For non-human identities, revocation only works if the platform removes every effective path to privilege, including fallback records and legacy state.
• Fail Closed: Fail closed means a system denies access when it cannot verify a valid entitlement state. In identity systems, this is the safer outcome for ambiguous or legacy records because it prevents historical permissions from being treated as current authorization.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• The exact code path in listEffectivePairedDeviceRoles() and how the fallback branch exposed legacy records
• The patch behaviour after 24-hour disclosure, including how tokenless devices now fail closed
• The specific record query administrators can use to find devices with stored roles and missing token state
• The disclosure timeline and confirmatory response from the OpenClaw team

👉 The full Unosecur post covers the fallback logic, patch behaviour, and affected legacy records.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or lifecycle governance in your organisation, it is worth exploring.