CVE-2026-62218: OpenClaw authorization bypass

CISO Take

OpenClaw's device.pair.approve feature fails to enforce its role-management checks, letting a caller with lower trust reach code paths that should require stronger authorization — a classic missing-authorization flaw (CWE-862) rated CVSS 8.8, network-exploitable with low complexity and no user interaction. Because OpenClaw is an AI agent framework, this isn't a cosmetic bug: device pairing and role approval are the control plane that decides which callers can grant elevated capabilities, so a successful bypass can let a low-privilege integration or compromised component approve itself (or another actor) into a higher-trust role. There's no EPSS score, no CISA KEV listing, and no public exploit or Nuclei template yet, so opportunistic mass exploitation looks unlikely today — but the vendor advisory and a VulnCheck writeup are both already public, which typically accelerates PoC development. Patch to OpenClaw 2026.5.27 or later immediately, and in the meantime audit any logs around device pairing/role approval for unexpected approvals from unexpected trust levels.

Sources: NVD GitHub Advisory vulncheck.com ATLAS

What is the risk?

High severity (CVSS 8.8, AV:N/AC:L/PR:L/UI:N/C:H/I:H/A:H) with full confidentiality, integrity, and availability impact once exploited, and low complexity means no special conditions are needed beyond low-level access. The absence of EPSS data, CISA KEV status, public exploit code, or a Nuclei template lowers near-term exploitation likelihood, but the vulnerability class (authorization/role-check bypass, CWE-862) is straightforward to weaponize once an attacker understands the input paths that reach device.pair.approve. Given OpenClaw's role as an agent framework where device/role trust decisions gate downstream capability, exploitation converts a low-privilege foothold into a governance-level compromise, which is disproportionately damaging relative to the technical effort required.

How does the attack unfold?

Initial Access

A low-trust caller (device, plugin, or subordinate agent) reaches the device.pair.approve feature via one of its configured network-accessible input paths.

AML.T0049

Authorization Bypass

The missing role-management check (CWE-862) lets the request proceed despite the caller lacking the required trust level.

AML.T0107

Privilege Escalation

The attacker approves a device pairing or role grant that assigns stronger authorization than their actual trust tier warrants.

AML.T0081

Impact

With elevated role capabilities, the attacker performs actions normally reserved for trusted operators, compromising confidentiality, integrity, and availability of the agent framework.

Initial Access

A low-trust caller (device, plugin, or subordinate agent) reaches the device.pair.approve feature via one of its configured network-accessible input paths.

AML.T0049

Authorization Bypass

The missing role-management check (CWE-862) lets the request proceed despite the caller lacking the required trust level.

AML.T0107

Privilege Escalation

The attacker approves a device pairing or role grant that assigns stronger authorization than their actual trust tier warrants.

AML.T0081

Impact

With elevated role capabilities, the attacker performs actions normally reserved for trusted operators, compromising confidentiality, integrity, and availability of the agent framework.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
OpenClaw	pip	—	No patch
3 dependents 37% patched ~3d to patch Full package profile →

Do you use OpenClaw? You're affected.

How severe is it?

CVSS 3.1

8.8 / 10

EPSS

0.5%

chance of exploitation in 30 days

Higher than 38% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Unchanged

C High

I High

A High

What should I do?

1 step

Upgrade OpenClaw to 2026.5.27 or later immediately — this is the primary and only complete fix. Until patched, restrict network/input-path reachability to the device.pair.approve feature (e.g., firewall rules, API gateway allowlists) so only fully-trusted callers can reach it. Audit existing role-management and device-pairing logs for approvals originating from unexpected trust levels or unusual source components, and rotate/re-validate any device pairings or role grants approved during the affected version window (2026.1.20–2026.5.27). Apply least-privilege defaults so lower-trust callers cannot reach approval endpoints even if the authorization check is bypassed again in the future, and monitor for anomalous role-elevation events going forward.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth Bypass Agent AML.T0049 - Exploit Public-Facing Application AML.T0081 - Modify AI Agent Configuration AML.T0107 - Exploitation for Defense Evasion

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 9 - Risk Management System

ISO 42001

Annex A - Access Control - Access control for AI system resources

NIST AI RMF

MANAGE-4.1 - Risk monitoring and response for deployed AI systems

OWASP LLM Top 10

LLM06 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-62218?

OpenClaw's device.pair.approve feature fails to enforce its role-management checks, letting a caller with lower trust reach code paths that should require stronger authorization — a classic missing-authorization flaw (CWE-862) rated CVSS 8.8, network-exploitable with low complexity and no user interaction. Because OpenClaw is an AI agent framework, this isn't a cosmetic bug: device pairing and role approval are the control plane that decides which callers can grant elevated capabilities, so a successful bypass can let a low-privilege integration or compromised component approve itself (or another actor) into a higher-trust role. There's no EPSS score, no CISA KEV listing, and no public exploit or Nuclei template yet, so opportunistic mass exploitation looks unlikely today — but the vendor advisory and a VulnCheck writeup are both already public, which typically accelerates PoC development. Patch to OpenClaw 2026.5.27 or later immediately, and in the meantime audit any logs around device pairing/role approval for unexpected approvals from unexpected trust levels.

Is CVE-2026-62218 actively exploited?

No confirmed active exploitation of CVE-2026-62218 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-62218?

Upgrade OpenClaw to 2026.5.27 or later immediately — this is the primary and only complete fix. Until patched, restrict network/input-path reachability to the device.pair.approve feature (e.g., firewall rules, API gateway allowlists) so only fully-trusted callers can reach it. Audit existing role-management and device-pairing logs for approvals originating from unexpected trust levels or unusual source components, and rotate/re-validate any device pairings or role grants approved during the affected version window (2026.1.20–2026.5.27). Apply least-privilege defaults so lower-trust callers cannot reach approval endpoints even if the authorization check is bypassed again in the future, and monitor for anomalous role-elevation events going forward.

What systems are affected by CVE-2026-62218?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, tool/device authorization, multi-agent orchestration.

What is the CVSS score for CVE-2026-62218?

CVE-2026-62218 has a CVSS v3.1 base score of 8.8 (HIGH). The EPSS exploitation probability is 0.45%.

What is the AI security impact?

Affected AI Architectures

agent frameworkstool/device authorizationmulti-agent orchestration

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application

AML.T0081 Modify AI Agent Configuration

AML.T0107 Exploitation for Defense Evasion

Compliance Controls Affected

EU AI Act: Article 9

ISO 42001: Annex A - Access Control

NIST AI RMF: MANAGE-4.1

OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

OpenClaw 2026.1.20 before 2026.5.27 contain an authorization bypass vulnerability in the device.pair.approve feature that allows lower-trust callers to bypass role-management checks. Attackers can perform actions requiring stronger authorization by reaching the affected feature through configured input paths.

Exploitation Scenario

An attacker who controls or compromises a low-trust component within an OpenClaw deployment — for example a newly-added device integration, a subordinate agent, or a plugin with limited default permissions — crafts a request that reaches the device.pair.approve feature through one of its configured input paths. Because the role-management check is not properly enforced, the request succeeds despite the caller lacking the required trust level, allowing the attacker to approve a device pairing or role grant that should have been denied. This grants the attacker capabilities normally reserved for higher-trust operators, which they can then use to perform further unauthorized actions within the agent framework, such as approving additional malicious integrations or accessing sensitive orchestration functions.

Weaknesses (CWE)

CWE-862 Missing Authorization Primary CWE-862 Missing Authorization

CWE-862 — Missing Authorization: The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

[Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
[Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Source: MITRE CWE corpus.