GHSA-r6xh-pqhr-v4xh: OpenClaw MCP owner-context

Q: Is GHSA-r6xh-pqhr-v4xh actively exploited?

No confirmed active exploitation of GHSA-r6xh-pqhr-v4xh has been reported, but organizations should still patch proactively.

Q: How to fix GHSA-r6xh-pqhr-v4xh?

1. Upgrade to openclaw 2026.4.22 immediately — the fix eliminates the spoofable sender-owner header and derives ownership exclusively from bearer token authentication. 2. Audit MCP loopback logs for owner-context operations originating from non-owner clients prior to the patch window. 3. Until patched, restrict loopback interface access to trusted processes only using OS-level controls. 4. Review all owner-gated operations exposed via MCP loopback for potential unauthorized invocations. 5. Given openclaw's history of 135 CVEs, formally assess whether this package meets your organization's security bar for AI agent infrastructure.

Q: What systems are affected by GHSA-r6xh-pqhr-v4xh?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, MCP runtimes, multi-agent systems, AI orchestration platforms.

Q: What is the CVSS score for GHSA-r6xh-pqhr-v4xh?

No CVSS score has been assigned yet.

CISO Take

openclaw's MCP loopback runtime accepted owner identity from a spoofable HTTP header rather than deriving it from authenticated bearer tokens, allowing any loopback client to claim owner-level privileges and execute owner-gated operations without authorization. With 135 prior CVEs in the same package and 4 downstream dependents, this is a recurring pattern of security debt in a component deeply embedded in AI agent workflows. No public exploit or KEV listing exists at this time and EPSS data is unavailable, but the exploit pattern — header injection to bypass auth — is conceptually trivial for any actor with loopback network access. Upgrade to openclaw 2026.4.22 immediately and audit owner-gated operations that may have been invoked by non-owner clients prior to patching.

Sources: GitHub Advisory ATLAS OWASP LLM Top 10

What is the risk?

HIGH. The vulnerability enables privilege escalation within MCP agent runtimes with minimal technical barrier — any process with loopback access can spoof owner identity by setting a single HTTP header. The lack of EPSS data and KEV listing limits urgency scoring, but the exploit pattern is trivially reproducible. The 135 historical CVEs in openclaw signal systemic security immaturity in this package. AI agent deployments trusting owner-gated MCP operations for sensitive tool invocations, data access, or configuration changes face the highest risk.

How does the attack unfold?

Loopback Access

Attacker gains access to the loopback interface via a compromised co-resident process, malicious MCP plugin, or local access from an unrelated vulnerability.

AML.T0049

Owner-Context Spoofing

Attacker crafts an MCP request to the loopback endpoint with a forged sender-owner header, asserting owner identity without possessing a valid owner bearer token.

AML.T0091.000

Privilege Escalation

The openclaw runtime trusts the spoofed header, granting the attacker owner-level access and bypassing all owner-gated operation authorization checks.

AML.T0053

Owner-Gated Operations Abuse

Attacker executes privileged agent operations — invoking restricted tools, reading sensitive agent state, or modifying agent configuration — with full owner authority.

AML.T0081

Loopback Access

Attacker gains access to the loopback interface via a compromised co-resident process, malicious MCP plugin, or local access from an unrelated vulnerability.

AML.T0049

Owner-Context Spoofing

Attacker crafts an MCP request to the loopback endpoint with a forged sender-owner header, asserting owner identity without possessing a valid owner bearer token.

AML.T0091.000

Privilege Escalation

The openclaw runtime trusts the spoofed header, granting the attacker owner-level access and bypassing all owner-gated operation authorization checks.

AML.T0053

Owner-Gated Operations Abuse

Attacker executes privileged agent operations — invoking restricted tools, reading sensitive agent state, or modifying agent configuration — with full owner authority.

AML.T0081

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
OpenClaw	npm	<= 2026.4.21	`2026.4.22`
4 dependents 36% patched ~3d to patch Full package profile →

Do you use OpenClaw? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Trivial

What should I do?

5 steps

Upgrade to openclaw 2026.4.22 immediately — the fix eliminates the spoofable sender-owner header and derives ownership exclusively from bearer token authentication.
Audit MCP loopback logs for owner-context operations originating from non-owner clients prior to the patch window.
Until patched, restrict loopback interface access to trusted processes only using OS-level controls.
Review all owner-gated operations exposed via MCP loopback for potential unauthorized invocations.
Given openclaw's history of 135 CVEs, formally assess whether this package meets your organization's security bar for AI agent infrastructure.

How is it classified?

Auth Bypass Code Execution Agent Framework AML.T0049 - Exploit Public-Facing Application AML.T0053 - AI Agent Tool Invocation AML.T0081 - Modify AI Agent Configuration AML.T0091.000 - Application Access Token

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.3 - Access control to AI systems

NIST AI RMF

MANAGE 2.4 - Residual risks are managed

OWASP LLM Top 10

LLM06:2025 - Excessive Agency

Frequently Asked Questions

What is GHSA-r6xh-pqhr-v4xh?

openclaw's MCP loopback runtime accepted owner identity from a spoofable HTTP header rather than deriving it from authenticated bearer tokens, allowing any loopback client to claim owner-level privileges and execute owner-gated operations without authorization. With 135 prior CVEs in the same package and 4 downstream dependents, this is a recurring pattern of security debt in a component deeply embedded in AI agent workflows. No public exploit or KEV listing exists at this time and EPSS data is unavailable, but the exploit pattern — header injection to bypass auth — is conceptually trivial for any actor with loopback network access. Upgrade to openclaw 2026.4.22 immediately and audit owner-gated operations that may have been invoked by non-owner clients prior to patching.

Is GHSA-r6xh-pqhr-v4xh actively exploited?

No confirmed active exploitation of GHSA-r6xh-pqhr-v4xh has been reported, but organizations should still patch proactively.

How to fix GHSA-r6xh-pqhr-v4xh?

1. Upgrade to openclaw 2026.4.22 immediately — the fix eliminates the spoofable sender-owner header and derives ownership exclusively from bearer token authentication. 2. Audit MCP loopback logs for owner-context operations originating from non-owner clients prior to the patch window. 3. Until patched, restrict loopback interface access to trusted processes only using OS-level controls. 4. Review all owner-gated operations exposed via MCP loopback for potential unauthorized invocations. 5. Given openclaw's history of 135 CVEs, formally assess whether this package meets your organization's security bar for AI agent infrastructure.

What systems are affected by GHSA-r6xh-pqhr-v4xh?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, MCP runtimes, multi-agent systems, AI orchestration platforms.

What is the CVSS score for GHSA-r6xh-pqhr-v4xh?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksMCP runtimesmulti-agent systemsAI orchestration platforms

MITRE ATLAS Techniques

AML.T0049 Exploit Public-Facing Application

AML.T0053 AI Agent Tool Invocation

AML.T0081 Modify AI Agent Configuration

AML.T0091.000 Application Access Token

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.6.2.3

NIST AI RMF: MANAGE 2.4

OWASP LLM Top 10: LLM06:2025

What are the technical details?

Original Advisory

## Summary MCP loopback owner context is derived from server-issued bearer tokens. ## Affected Packages / Versions - Package: openclaw (npm) - Affected versions: <= 2026.4.21 - Fixed version: 2026.4.22 ## Impact The loopback MCP path accepted spoofable owner-context metadata from request headers, which could allow a non-owner loopback client to present itself as owner for owner-gated operations. ## Fix The MCP loopback runtime now issues separate owner and non-owner bearer tokens and derives senderIsOwner exclusively from which token authenticated the request. The spoofable sender-owner header is no longer emitted or trusted. ## Fix Commit(s) - 3cb1a56bfc9579a0f2336f9cfa12a8a744332a19 ## Verification - The fix commit is contained in the public v2026.4.22 tag. - openclaw@2026.4.22 is published on npm and the compiled package contains the fix. - Focused regression coverage for this path passed before publication. OpenClaw thanks @VladimirEliTokarev for reporting.

Exploitation Scenario

An attacker with access to the loopback interface — a compromised co-resident process, a malicious MCP plugin, or local access via an unrelated vulnerability — sends a crafted HTTP request to the openclaw loopback MCP endpoint. By setting the spoofable sender-owner header to claim owner status, the request is processed as if originating from the legitimate owner, bypassing all owner-gated checks. The attacker can now invoke restricted tools, read sensitive agent state, or modify agent configuration with full owner authority — all without possessing a valid owner bearer token and leaving no cryptographic evidence of the impersonation.

Weaknesses (CWE)

CWE-284 Improper Access Control Primary

CWE-284 — Improper Access Control: The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.

[Architecture and Design, Operation] Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
[Architecture and Design] Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

Source: MITRE CWE corpus.