GHSA-hw9r-h9mr-4jff: OpenClaw: chat.send routing bypasses admin auth scopes

GHSA-hw9r-h9mr-4jff HIGH
Published July 2, 2026
CISO Take

OpenClaw's Gateway has a routing flaw where a scoped client holding only the lower-privilege operator.write scope can trigger admin-tier command handlers — approval resolution, plugin installation, config changes, MCP server registration, and ACP mutations — that should require operator.approvals or operator.admin, simply by delivering a chat.send request into a session with an inherited external route. For a CISO, this matters because it silently defeats the human-approval gates that agentic AI deployments rely on for safety: any integration or bot with write-level Gateway access effectively becomes an admin, with confidentiality, integrity, and availability all rated High (CVSS 8.8). There's no evidence of active exploitation (not in CISA KEV, no public PoC or Nuclei template, EPSS unavailable), and the package carries no OpenSSF Scorecard signal to gauge maintenance health independently, so treat this as a proactive patch rather than an active incident. Upgrade to openclaw 2026.5.18 or later immediately; until then, do not grant operator.write to any Gateway client capable of delivering into sessions with external routes, and audit logs for approval-resolution or plugin/config/MCP/allowlist/ACP commands executed by write-scoped clients.

Sources: GitHub Advisory CISA KEV ATLAS

What is the risk?

High severity (CVSS 8.8) but exploitation requires an attacker to already control or compromise a scoped Gateway client holding operator.write — this is not an unauthenticated remote exploit, so likelihood hinges on how broadly operator.write is delegated to integrations, bots, or external-facing channels. Given openclaw's role as an autonomous AI agent framework where admin-tier commands include plugin installation and MCP registration, a successful exploit converts a routine integration credential into full agent control, which is a severe blast-radius outcome even without active exploitation signals. Absence from CISA KEV, no public exploit code, and no EPSS score suggest this is not yet a hot target, but the flaw is easy to reason about once the advisory is public (routing/scope confusion), so time-to-weaponization could be short.

How does the attack unfold?

Scoped credential access
Attacker controls or compromises a scoped Gateway client already holding operator.write, such as a chat-bridge integration.
AML.T0012
Crafted chat.send delivery
Attacker sends a chat.send request into a session with an inherited external delivery route, causing it to be misevaluated as an external-channel command.
AML.T0053
Admin scope escalation
Command handlers requiring operator.approvals or operator.admin execute anyway, letting the attacker resolve approvals and mutate plugin, config, MCP, allowlist, or ACP settings.
AML.T0081
Persistent agent compromise
Attacker installs a malicious plugin or MCP server / alters the allowlist, establishing durable elevated control over the agent's tools and behavior.
AML.T0110

What systems are affected?

Package Ecosystem Vulnerable Range Patched
OpenClaw npm < 2026.5.18 2026.5.18
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
N/A
Exploitation Status
No known exploitation
Sophistication
Moderate

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR Low
UI None
S Unchanged
C High
I High
A High

What should I do?

1 step
  1. Upgrade to openclaw 2026.5.18 or later without delay. Until patched, do not issue operator.write tokens to any Gateway client that can deliver chat.send commands into sessions with an inherited external delivery route unless that client is already trusted with admin-like effects. Audit existing operator.write token holders and their session delivery configurations to identify any that meet this affected pattern. For detection, review Gateway/audit logs for approval-resolution actions or administrative commands (plugin, config, MCP, allowlist, ACP mutations) originating from clients whose token only carries operator.write scope — any such event pre-patch should be treated as a potential exploitation indicator. After upgrading, re-verify that scope enforcement correctly rejects these commands from write-only clients.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 14 - Human oversight
ISO 42001
A.6.2 - AI system operation and monitoring / access control
NIST AI RMF
GOVERN-1.5 - Mechanisms for human oversight and control of AI system risks
OWASP LLM Top 10
LLM08:2025 - Excessive Agency

Frequently Asked Questions

What is GHSA-hw9r-h9mr-4jff?

OpenClaw's Gateway has a routing flaw where a scoped client holding only the lower-privilege operator.write scope can trigger admin-tier command handlers — approval resolution, plugin installation, config changes, MCP server registration, and ACP mutations — that should require operator.approvals or operator.admin, simply by delivering a chat.send request into a session with an inherited external route. For a CISO, this matters because it silently defeats the human-approval gates that agentic AI deployments rely on for safety: any integration or bot with write-level Gateway access effectively becomes an admin, with confidentiality, integrity, and availability all rated High (CVSS 8.8). There's no evidence of active exploitation (not in CISA KEV, no public PoC or Nuclei template, EPSS unavailable), and the package carries no OpenSSF Scorecard signal to gauge maintenance health independently, so treat this as a proactive patch rather than an active incident. Upgrade to openclaw 2026.5.18 or later immediately; until then, do not grant operator.write to any Gateway client capable of delivering into sessions with external routes, and audit logs for approval-resolution or plugin/config/MCP/allowlist/ACP commands executed by write-scoped clients.

Is GHSA-hw9r-h9mr-4jff actively exploited?

No confirmed active exploitation of GHSA-hw9r-h9mr-4jff has been reported, but organizations should still patch proactively.

How to fix GHSA-hw9r-h9mr-4jff?

Upgrade to openclaw 2026.5.18 or later without delay. Until patched, do not issue operator.write tokens to any Gateway client that can deliver chat.send commands into sessions with an inherited external delivery route unless that client is already trusted with admin-like effects. Audit existing operator.write token holders and their session delivery configurations to identify any that meet this affected pattern. For detection, review Gateway/audit logs for approval-resolution actions or administrative commands (plugin, config, MCP, allowlist, ACP mutations) originating from clients whose token only carries operator.write scope — any such event pre-patch should be treated as a potential exploitation indicator. After upgrading, re-verify that scope enforcement correctly rejects these commands from write-only clients.

What systems are affected by GHSA-hw9r-h9mr-4jff?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, multi-channel agent gateways, plugin/tool integration layers, MCP server integrations.

What is the CVSS score for GHSA-hw9r-h9mr-4jff?

GHSA-hw9r-h9mr-4jff has a CVSS v3.1 base score of 8.8 (HIGH).

What is the AI security impact?

Affected AI Architectures

agent frameworksmulti-channel agent gatewaysplugin/tool integration layersMCP server integrations

MITRE ATLAS Techniques

AML.T0012 Valid Accounts
AML.T0053 AI Agent Tool Invocation
AML.T0081 Modify AI Agent Configuration

Compliance Controls Affected

EU AI Act: Article 14
ISO 42001: A.6.2
NIST AI RMF: GOVERN-1.5
OWASP LLM Top 10: LLM08:2025

What are the technical details?

Original Advisory

### Summary Some internal command handlers require `operator.approvals` or `operator.admin` scopes. In affected releases, a scoped Gateway `chat.send` request delivered through an inherited external route could be evaluated as an external-channel command while still carrying the lower Gateway client scopes. This issue affects scoped Gateway clients. It does not apply to shared-secret bearer HTTP compatibility endpoints, which are documented as full operator surfaces under OpenClaw's trust model. ### Affected configurations This affects deployments where a scoped Gateway caller with `operator.write` can use `chat.send` with delivery into a session that has an inherited external delivery route. ### Impact Commands that should have required `operator.approvals` or `operator.admin` could run with only `operator.write` in this routed context. Affected command families included approval resolution and selected administrative commands such as plugin, config, MCP, allowlist, and ACP mutations. ### Patched Versions The first stable patched version is `2026.5.18`. ### Mitigations Upgrade to `openclaw@2026.5.18` or later. Before upgrading, avoid granting `operator.write` tokens to clients that can deliver commands into sessions with external routes unless those clients are trusted with admin-like command effects.

Exploitation Scenario

An attacker compromises or operates a legitimate-looking scoped Gateway integration (e.g., a chat bridge bot) that has been granted operator.write for normal message-relay duties. The attacker crafts a chat.send request and delivers it into a session that inherits an external delivery route — a routing pattern common to multi-channel agent deployments. Due to the flaw, the Gateway evaluates this as an external-channel command rather than enforcing the caller's actual operator.write scope, allowing the request to reach command handlers gated behind operator.approvals or operator.admin. The attacker uses this to resolve pending approval requests and issue administrative commands: installing a malicious plugin, registering a rogue MCP server, or modifying the command allowlist — establishing persistent, elevated control over the agent's tool access and behavior without ever holding genuine admin credentials.

Weaknesses (CWE)

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.

CVSS Vector

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

Timeline

Published
July 2, 2026
Last Modified
July 2, 2026
First Seen
July 2, 2026

Related Vulnerabilities