Notifications
Clear all
Topic starter
24/06/2026 8:02 pm
TL;DR: OpenClaw’s device pairing flaw let legacy devices keep persistent roles after token revocation, because the fallback path ignored tokenless records and returned stored permissions instead, according to Unosecur. The case shows how revocation controls can appear effective while leaving untracked device identities active.
NHIMG editorial — based on content published by Unosecur: OpenClaw Device Pairing Flaw Let Legacy Devices Bypass Token Revocation
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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
👉 Read Unosecur's analysis of the OpenClaw device pairing revocation flaw →
OpenClaw device pairing flaw: what revocation gaps teams are missing?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 4:42 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: OpenClaw device pairing flaw exposes persistent role revocation gaps
