OpenClaw EUVD-2026-87496

Requires a node that was previously and legitimately paired to the OpenClaw Gateway AND granted a Canvas capability, which the operator then revokes - the attacker must control that already-provisioned node. Exploitation is confined to the WebSocket close grace period after revocation (a transient race window, hence AT:P/AC:H), and to only the Canvas capability's already-configured routes; no privilege escalation beyond the node's prior grant occurs. Limiting factors: prior valid pairing/authorization (PR:L), narrow timing window, no user interaction on the victim side, and impact bounded to pre-existing Canvas routes. Restarting the Gateway immediately after revocation fully closes the window.

This is a genuinely low-priority issue, and the signals are consistent rather than conflicting. The vendor CVSS 4.0 base score of 2.3 (AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N) aligns with the described mechanics: exploitation requires an already-paired node (PR:L, prior legitimate credential/pairing), a race against a transient WebSocket close-grace window (AC:H/AT:P), and yields only limited confidentiality/integrity impact (VC:L/VI:L) bounded to the revoked node's already-configured Canvas routes - no privilege gain beyond what the node already had. There is no EPSS score, no CISA KEV listing, and no public exploit code, so exploitation status is 'no public exploit identified at time of analysis.' No SSVC record is provided. Nothing here elevates it above the low-CVSS/low-real-risk category: the flaw is a narrow window during which an operator-revoked node retains its existing (not escalated) capability. The one metadata caveat: the 'Information Disclosure' tag overstates and mislabels the root cause, which is insufficient/delayed session expiration (CWE-613) rather than a disclosure primitive - verify labeling before triaging by tag.

An operator revokes a previously paired OpenClaw node that had been granted a Canvas capability. Because Canvas HTTP authorization is not invalidated in lockstep with the WebSocket teardown, the revoked node's operator continues issuing HTTP requests against the capability's configured Canvas routes during the close grace period, and the Gateway keeps accepting and even renewing the capability until cleanup finishes. No public exploit code exists; the window is timing-bound and requires prior legitimate pairing.