GHSA-rggc-m335-3wvj: OpenClaw forged identity headers

CISO Take

OpenClaw's Gateway can be tricked into trusting forged identity headers from any process running on the same host as the proxy-facing port, letting a local attacker impersonate a legitimate operator without credentials. This is a same-host, not remote, attack vector — it's not in CISA KEV, there's no EPSS score or public exploit yet, and the affected package shows only 4 known downstream dependents, so mass exploitation is unlikely today. The real risk shows up in shared or multi-tenant hosts, containers, or environments where lower-trust code (installed plugins, skills, other co-located tenants) can reach the Gateway port directly: once impersonated, the attacker inherits the victim operator's authorization to invoke agent tools and actions. Patch to 2026.5.18, and until then bind the Gateway strictly behind the real trusted proxy with host firewall rules blocking direct same-host access, disabling the feature if it isn't in active use. Audit logs for identity headers arriving from unexpected local sources as a compensating detection control while patching rolls out.

Sources: GitHub Advisory ATLAS

What is the risk?

Rated high by the vendor but exploitability is gated by network positioning: the attacker must already have code execution or network reach on the same host as the Gateway port, which rules out opportunistic internet-wide exploitation. No CVSS vector, EPSS score, public exploit, or Nuclei template exists, and it's absent from CISA KEV — all consistent with a vulnerability that requires a specific deployment misconfiguration (proxy-facing Gateway reachable from untrusted local processes) rather than a universally exposed flaw. Where that precondition is met, impact is significant: the flaw is a full authentication bypass by spoofing (CWE-290/287/863), letting an unauthenticated local caller assume a trusted operator's identity and downstream authorization. Organizations running multi-tenant Gateways, sandboxed plugins/skills, or shared hosts should treat this as urgent; single-tenant, properly network-isolated deployments face materially lower real-world risk.

How does the attack unfold?

Local Positioning

Attacker obtains code execution or network reach on the same host as the OpenClaw Gateway, e.g. via a malicious plugin/skill or a co-located tenant workload.

AML.T0112.000

Header Forgery

Attacker crafts a direct request to the Gateway's proxy-facing port, including identity headers normally reserved for the trusted reverse proxy.

AML.T0091.000

Identity Impersonation

The Gateway accepts the forged headers without verifying they transited the real proxy, granting the request the legitimate operator's identity.

Unauthorized Tool/Action Execution

Impersonating the operator, the attacker invokes agent tools and actions scoped to that operator's authorization without ever authenticating.

AML.T0053

Local Positioning

Attacker obtains code execution or network reach on the same host as the OpenClaw Gateway, e.g. via a malicious plugin/skill or a co-located tenant workload.

AML.T0112.000

Header Forgery

Attacker crafts a direct request to the Gateway's proxy-facing port, including identity headers normally reserved for the trusted reverse proxy.

AML.T0091.000

Identity Impersonation

The Gateway accepts the forged headers without verifying they transited the real proxy, granting the request the legitimate operator's identity.

Unauthorized Tool/Action Execution

Impersonating the operator, the attacker invokes agent tools and actions scoped to that operator's authorization without ever authenticating.

AML.T0053

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

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

Patch to OpenClaw >= 2026.5.18 as the primary fix. Until patched, bind trusted-proxy ingress so only the actual proxy can reach it, and use host firewall rules to block any other local process from hitting the Gateway port directly. Disable the affected trusted-proxy identity feature entirely if it isn't needed. As general hardening: keep channel and tool allowlists narrow, and never share a single Gateway between mutually untrusted users or tenants. For detection, review Gateway network bindings (confirm it isn't listening on a non-loopback interface reachable by untrusted local workloads) and audit logs for identity headers or operator actions originating from unexpected local sources or sockets inconsistent with the real proxy's traffic pattern.

How is it classified?

Auth Bypass Agent API AML.T0053 - AI Agent Tool Invocation AML.T0091.000 - Application Access Token AML.T0112.000 - Local AI Agent

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

Annex A.6 (AI system security) - Security controls for AI system operation

NIST AI RMF

MEASURE 2.7 - AI system security and resilience is evaluated

OWASP LLM Top 10

LLM08 - Excessive Agency

Frequently Asked Questions

What is GHSA-rggc-m335-3wvj?

OpenClaw's Gateway can be tricked into trusting forged identity headers from any process running on the same host as the proxy-facing port, letting a local attacker impersonate a legitimate operator without credentials. This is a same-host, not remote, attack vector — it's not in CISA KEV, there's no EPSS score or public exploit yet, and the affected package shows only 4 known downstream dependents, so mass exploitation is unlikely today. The real risk shows up in shared or multi-tenant hosts, containers, or environments where lower-trust code (installed plugins, skills, other co-located tenants) can reach the Gateway port directly: once impersonated, the attacker inherits the victim operator's authorization to invoke agent tools and actions. Patch to 2026.5.18, and until then bind the Gateway strictly behind the real trusted proxy with host firewall rules blocking direct same-host access, disabling the feature if it isn't in active use. Audit logs for identity headers arriving from unexpected local sources as a compensating detection control while patching rolls out.

Is GHSA-rggc-m335-3wvj actively exploited?

No confirmed active exploitation of GHSA-rggc-m335-3wvj has been reported, but organizations should still patch proactively.

How to fix GHSA-rggc-m335-3wvj?

Patch to OpenClaw >= 2026.5.18 as the primary fix. Until patched, bind trusted-proxy ingress so only the actual proxy can reach it, and use host firewall rules to block any other local process from hitting the Gateway port directly. Disable the affected trusted-proxy identity feature entirely if it isn't needed. As general hardening: keep channel and tool allowlists narrow, and never share a single Gateway between mutually untrusted users or tenants. For detection, review Gateway network bindings (confirm it isn't listening on a non-loopback interface reachable by untrusted local workloads) and audit logs for identity headers or operator actions originating from unexpected local sources or sockets inconsistent with the real proxy's traffic pattern.

What systems are affected by GHSA-rggc-m335-3wvj?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, AI agent gateways / orchestration layers, multi-tenant agent deployments.

What is the CVSS score for GHSA-rggc-m335-3wvj?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksAI agent gateways / orchestration layersmulti-tenant agent deployments

MITRE ATLAS Techniques

AML.T0053 AI Agent Tool Invocation

AML.T0091.000 Application Access Token

AML.T0112.000 Local AI Agent

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: Annex A.6 (AI system security)

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM08

What are the technical details?

Original Advisory

### Summary Same-host trusted-proxy deployments could accept local forged identity headers. In affected versions, a local same-host caller that can reach the proxy-facing Gateway port could supply identity headers normally reserved for the trusted proxy. This advisory is scoped to the named feature and configuration. It does not change OpenClaw's trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed. ### Impact When the affected feature is enabled and reachable, this could receive operator identity associated with the forged headers. Practical impact depends on the operator's configuration and whether lower-trust input can reach that path. ### Patched Versions The first stable patched version is `2026.5.18`. ### Mitigations bind trusted-proxy ingress behind the actual proxy and firewall direct same-host access. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.

Exploitation Scenario

An attacker first obtains low-privilege code execution on the same host as the OpenClaw Gateway — for example via a malicious third-party skill/plugin, a compromised container, or another tenant's workload sharing the host. Instead of going through the legitimate reverse proxy, the attacker sends a request directly to the Gateway's proxy-facing port, including the identity headers the Gateway normally only accepts from its trusted proxy (e.g., an operator-identity header). Because the Gateway doesn't verify the request actually transited the real proxy, it accepts the forged headers and treats the attacker as the legitimate operator associated with that identity. The attacker now inherits that operator's authorization, letting them invoke the agent's tools or actions and access data/capabilities scoped to a user they never authenticated as.

Weaknesses (CWE)

CWE-269 Improper Privilege Management Primary CWE-284 Improper Access Control Primary CWE-287 Improper Authentication Primary CWE-290 Authentication Bypass by Spoofing Primary CWE-863 Incorrect Authorization Primary

CWE-269 — Improper Privilege Management: The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that 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] Follow the principle of least privilege when assigning access rights to entities in a software system.

Source: MITRE CWE corpus.