Is there a patch available for EUVD-2026-37164?

Yes, a patch is available for EUVD-2026-37164. Update the affected software to the latest version immediately.

OpenClaw EUVD-2026-37164

Q: What is the CVSS score of EUVD-2026-37164?

EUVD-2026-37164 has a CVSS 4.0 base score of 2.3 (Low). CVSS vector: CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.1%.

| CVE-2026-53862 LOW

Incorrect Privilege Assignment (CWE-266)

2026-06-16 VulnCheck

GHSA-9v8j-9c9g-w66c

GHSA-h9h6-pwqv-j9hv

Privilege Escalation Openclaw

2.3

CVSS 4.0 · Vendor: VulnCheck

Severity by source

Vendor (VulnCheck) PRIMARY

2.3 LOW

CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

3.7 LOW

PR:L reflects that exploitation requires a pre-existing pending bootstrap token, implying a prior low-privilege relationship; AC:H captures the narrow approval-window timing dependency.

3.1 AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:L/A:N

4.0 AV:N/AC:H/AT:P/PR:L/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (VulnCheck).

CVSS VectorVendor: VulnCheck

CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

Scope

Lifecycle Timeline

Patch available

Jun 16, 2026 - 20:02 EUVD

Analysis Generated

Jun 16, 2026 - 19:00 vuln.today

DescriptionCVE.org

OpenClaw before 2026.5.12 contains a bootstrap token replay vulnerability allowing callers with pending token access to reuse tokens with broader requested scopes. Attackers can replay bootstrap tokens before approval to escalate pairing authority beyond intended scope limits.

AnalysisAI

Bootstrap token replay in OpenClaw before version 2026.5.12 permits callers holding a pending bootstrap token to resubmit that token with a broader scope than originally requested, bypassing intended pairing authority limits. The flaw, rooted in incorrect privilege assignment (CWE-266), exploits the gap between token issuance and administrative approval to escalate pairing access. No public exploit code has been identified and the vulnerability carries a CVSS 4.0 score of 2.3, reflecting significant mitigating factors including high attack complexity, a required target precondition, and passive user interaction - making this a low real-world priority outside environments with high-value pairing workflows.

Technical ContextAI

OpenClaw (CPE: cpe:2.3:a:openclaw:openclaw:*:*:*:*:*:*:*:*) implements a bootstrap token pairing mechanism in which tokens are issued in a pending state and must await administrator approval before granting full pairing authority. The root cause is CWE-266 (Incorrect Privilege Assignment): the token validation logic does not enforce scope boundaries on pending tokens during the replay window, allowing a caller to resubmit the same token with an expanded scope claim before the original approval decision is finalized. This is a logical authorization design flaw - not a memory corruption or injection class issue - where the system fails to bind a pending token irrevocably to its originally requested scope at issuance time, leaving the scope negotiable until approval.

RemediationAI

The primary fix is to upgrade OpenClaw to version 2026.5.12 or later, per the vendor GitHub Security Advisory GHSA-9v8j-9c9g-w66c (https://github.com/openclaw/openclaw/security/advisories/GHSA-9v8j-9c9g-w66c). If immediate patching is not feasible, restrict issuance of pending bootstrap tokens to the smallest possible set of trusted callers, thereby reducing the population that can attempt a replay. Shortening the administrative approval window - approving or rejecting pending tokens as quickly as possible - narrows the race condition window; this is operationally simple but introduces approval latency trade-offs. Implementing per-token scope pinning at issuance (rejecting any replay that differs from the originally requested scope) would serve as a compensating control if code changes are possible without a full upgrade. VulnCheck's advisory at https://www.vulncheck.com/advisories/openclaw-bootstrap-token-replay-via-pending-pairing-scope-widening provides additional context for scoping the fix.