GHSA-qjpc-qf9m-xwmr: OpenClaw WebSocket scope bypass

Q: Is GHSA-qjpc-qf9m-xwmr actively exploited?

No confirmed active exploitation of GHSA-qjpc-qf9m-xwmr has been reported, but organizations should still patch proactively.

Q: How to fix GHSA-qjpc-qf9m-xwmr?

Upgrade to `openclaw@2026.5.18` or later, which binds requested operator scopes to a server-approved pairing or trusted-proxy authorization baseline before granting them. As an interim mitigation, restrict trusted-proxy Control UI access to only those users who should legitimately hold the scopes they can request, and restart the gateway after any change to trusted-proxy authorization policy since policy changes are not hot-reloaded. For detection, audit Gateway RPC logs for admin-gated calls originating from trusted-proxy sessions whose device identity was never paired/approved, and review recent operator.admin RPC activity for anomalies predating the patch.

Q: What systems are affected by GHSA-qjpc-qf9m-xwmr?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, AI agent gateways/control planes.

Q: What is the CVSS score for GHSA-qjpc-qf9m-xwmr?

GHSA-qjpc-qf9m-xwmr has a CVSS v3.1 base score of 8.8 (HIGH).

CISO Take

OpenClaw's trusted-proxy Control UI let a WebSocket client declare its own operator scopes before those scopes were validated against the server's approved pairing or trusted-proxy authorization baseline, meaning a restricted proxy user could open a fresh, unpaired connection and walk away with cached operator.admin authority — full admin-gated Gateway RPC access — for the life of that session. This is a CVSS 8.8 authorization flaw (CWE-862/863) in an AI agent gateway that only 4 known packages currently depend on, and it hasn't been added to CISA's KEV catalog, has no published EPSS score, and no public exploit or scanner template exists yet, so treat it as high-severity-but-not-yet-weaponized rather than an active-exploitation emergency. The exposure is real wherever `gateway.auth.mode: "trusted-proxy"` is in use, because the attack requires only a low-privilege authenticated session (PR:L) and no user interaction (UI:N) to reach full admin control over the gateway's RPC surface — effectively agent takeover. Upgrade to `openclaw@2026.5.18` immediately, and until then restrict which trusted-proxy users can reach the Control UI to those who should legitimately hold elevated scopes, then restart the gateway after any authorization policy change since it isn't hot-reloaded. Shared-secret Control UI sessions are unaffected, so this is scoped strictly to trusted-proxy deployments — confirm your `gateway.auth.mode` setting before deciding this doesn't apply to you.

Sources: NVD GitHub Advisory CISA KEV ATLAS

What is the risk?

High severity (CVSS 8.8) authorization bypass with low attack complexity and no user interaction required, but currently limited real-world exposure: no CISA KEV listing, no EPSS score published, no public exploit code or Nuclei template, and only 4 downstream dependents tracked. The main risk driver isn't mass exploitation potential — it's the blast radius of a successful exploit: an attacker with only restricted trusted-proxy access can escalate to full operator.admin authority over an AI agent's Gateway RPC surface, which is effectively an agent takeover primitive (confidentiality, integrity, and availability all rated High in the CVSS vector). Organizations running `gateway.auth.mode: "trusted-proxy"` Control UI deployments should treat this as urgent-but-manageable: patch promptly, but there is no evidence of in-the-wild abuse today.

How does the attack unfold?

Unpaired WebSocket connection

A restricted trusted-proxy Control UI user opens a fresh WebSocket connection and presents a new, unpaired device identity while requesting elevated operator scopes.

Scope binding bypass

The gateway accepts the client's self-declared scopes before validating them against a server-approved pairing or the trusted-proxy authorization baseline (CWE-862/863).

Admin authority caching

The live WebSocket connection is granted cached operator.admin authority it was never entitled to hold.

AML.T0053

Admin RPC abuse

The attacker uses the cached operator.admin authority to invoke admin-gated Gateway RPCs — reconfiguring the agent, its tools, or other sessions — until the connection is closed or revalidated.

AML.T0108

Unpaired WebSocket connection

A restricted trusted-proxy Control UI user opens a fresh WebSocket connection and presents a new, unpaired device identity while requesting elevated operator scopes.

Scope binding bypass

The gateway accepts the client's self-declared scopes before validating them against a server-approved pairing or the trusted-proxy authorization baseline (CWE-862/863).

Admin authority caching

The live WebSocket connection is granted cached operator.admin authority it was never entitled to hold.

AML.T0053

Admin RPC abuse

The attacker uses the cached operator.admin authority to invoke admin-gated Gateway RPCs — reconfiguring the agent, its tools, or other sessions — until the connection is closed or revalidated.

AML.T0108

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
OpenClaw	npm	< 2026.5.18	`2026.5.18`
4 dependents 41% 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

N/A

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 to openclaw@2026.5.18 or later, which binds requested operator scopes to a server-approved pairing or trusted-proxy authorization baseline before granting them. As an interim mitigation, restrict trusted-proxy Control UI access to only those users who should legitimately hold the scopes they can request, and restart the gateway after any change to trusted-proxy authorization policy since policy changes are not hot-reloaded. For detection, audit Gateway RPC logs for admin-gated calls originating from trusted-proxy sessions whose device identity was never paired/approved, and review recent operator.admin RPC activity for anomalies predating the patch.

How is it classified?

Auth Bypass Agent API AML.T0053 - AI Agent Tool Invocation AML.T0108 - AI Agent

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

NIST AI RMF

MANAGE-4.1 - Mechanisms are in place to monitor and manage AI system risk, including security

OWASP LLM Top 10

LLM06 - Excessive Agency

Frequently Asked Questions

What is GHSA-qjpc-qf9m-xwmr?

OpenClaw's trusted-proxy Control UI let a WebSocket client declare its own operator scopes before those scopes were validated against the server's approved pairing or trusted-proxy authorization baseline, meaning a restricted proxy user could open a fresh, unpaired connection and walk away with cached operator.admin authority — full admin-gated Gateway RPC access — for the life of that session. This is a CVSS 8.8 authorization flaw (CWE-862/863) in an AI agent gateway that only 4 known packages currently depend on, and it hasn't been added to CISA's KEV catalog, has no published EPSS score, and no public exploit or scanner template exists yet, so treat it as high-severity-but-not-yet-weaponized rather than an active-exploitation emergency. The exposure is real wherever `gateway.auth.mode: "trusted-proxy"` is in use, because the attack requires only a low-privilege authenticated session (PR:L) and no user interaction (UI:N) to reach full admin control over the gateway's RPC surface — effectively agent takeover. Upgrade to `openclaw@2026.5.18` immediately, and until then restrict which trusted-proxy users can reach the Control UI to those who should legitimately hold elevated scopes, then restart the gateway after any authorization policy change since it isn't hot-reloaded. Shared-secret Control UI sessions are unaffected, so this is scoped strictly to trusted-proxy deployments — confirm your `gateway.auth.mode` setting before deciding this doesn't apply to you.

Is GHSA-qjpc-qf9m-xwmr actively exploited?

No confirmed active exploitation of GHSA-qjpc-qf9m-xwmr has been reported, but organizations should still patch proactively.

How to fix GHSA-qjpc-qf9m-xwmr?

Upgrade to `openclaw@2026.5.18` or later, which binds requested operator scopes to a server-approved pairing or trusted-proxy authorization baseline before granting them. As an interim mitigation, restrict trusted-proxy Control UI access to only those users who should legitimately hold the scopes they can request, and restart the gateway after any change to trusted-proxy authorization policy since policy changes are not hot-reloaded. For detection, audit Gateway RPC logs for admin-gated calls originating from trusted-proxy sessions whose device identity was never paired/approved, and review recent operator.admin RPC activity for anomalies predating the patch.

What systems are affected by GHSA-qjpc-qf9m-xwmr?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, AI agent gateways/control planes.

What is the CVSS score for GHSA-qjpc-qf9m-xwmr?

GHSA-qjpc-qf9m-xwmr has a CVSS v3.1 base score of 8.8 (HIGH).

What is the AI security impact?

Affected AI Architectures

agent frameworksAI agent gateways/control planes

MITRE ATLAS Techniques

AML.T0053 AI Agent Tool Invocation

AML.T0108 AI Agent

Compliance Controls Affected

EU AI Act: Article 15

NIST AI RMF: MANAGE-4.1

OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

### Summary In trusted-proxy Control UI mode, OpenClaw accepted a WebSocket client's declared operator scopes before those scopes were bound to a server-approved pairing or trusted-proxy authorization baseline. This issue affects trusted-proxy Control UI deployments. It does not apply to shared-secret Control UI sessions, which are treated as trusted operator sessions by design. ### Affected configurations This affects deployments using `gateway.auth.mode: "trusted-proxy"` for Control UI access where a restricted trusted-proxy user could open a Control UI WebSocket and present a fresh, unpaired device identity with elevated requested scopes. ### Impact An unpaired or restricted trusted-proxy Control UI client could obtain cached `operator.admin` authority on its live WebSocket connection. That authority could then be used for admin-gated Gateway RPCs until the connection was closed or revalidated. ### Patched Versions The first stable patched version is `2026.5.18`. ### Mitigations Upgrade to `openclaw@2026.5.18` or later. Before upgrading, restrict trusted-proxy Control UI access to users who should have the scopes they can request, and restart the gateway after changing trusted-proxy authorization policy.

Exploitation Scenario

An attacker who holds only a restricted, low-privilege account behind the trusted-proxy layer (e.g., a contractor or junior operator account meant to have limited Control UI access) opens a fresh WebSocket connection to the Control UI and presents a brand-new, unpaired device identity while requesting elevated operator scopes. Because OpenClaw accepted the client's self-declared scopes before checking them against a server-approved pairing or the trusted-proxy authorization baseline, the gateway grants cached operator.admin authority on that live connection. The attacker then uses that admin authority to invoke admin-gated Gateway RPCs — for example reconfiguring the AI agent, modifying tools/skills, or reaching other operators' sessions — until the connection is closed or revalidated, giving them a window of full administrative control over the agent gateway starting from minimal privilege.

Weaknesses (CWE)

CWE-862 Missing Authorization Primary CWE-863 Incorrect Authorization Primary

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.