highJul 2, 2026

CVE-2026-53832: openclaw Trusted-Proxy Identity Header Forgery via Same-Host Loopback

Shubham Kandhare
Security Engagement Manager, SecureLayer7

When OpenClaw's trusted-proxy auth mode was active, any local process on the same host could send a forged identity header directly to the Gateway port and authenticate as an arbitrary operator, bypas

Packageopenclaw
Ecosystemnpm
Affected< 2026.5.18
Fixed in2026.5.18

The problem

OpenClaw's `trusted-proxy` auth mode trusts identity headers (such as `X-Forwarded-User`) only from IPs listed in `gateway.trustedProxies`. The intended model is that a real network proxy is the only path to the Gateway.

Before 2026.5.18, there was no rejection of loopback-sourced requests. A local process on the same host could reach the Gateway's port directly and supply the configured identity header. Because `127.0.0.1` could appear in `trustedProxies` (required for same-host proxy setups like cloudflared), the Gateway accepted the forged header and granted operator identity to the caller.

Impact is scoped to deployments running `gateway.auth.mode: "trusted-proxy"` where the Gateway port is reachable from the same host without going through the actual proxy.

Proof of concept

A working proof-of-concept for this issue in openclaw, with the exact payload below.

http
# Attacker is a local process on the same host as the Gateway.
# Gateway is configured with auth.mode=trusted-proxy, trustedProxies=["127.0.0.1"],
# and userHeader="x-forwarded-user".
# Before 2026.5.18, this request authenticates as admin@example.com with no proxy involvement.

GET /api/v1/config HTTP/1.1
Host: 127.0.0.1:18789
X-Forwarded-User: admin@example.com
X-Forwarded-Proto: https

# Equivalent curl:
# curl -H 'X-Forwarded-User: admin@example.com' \
#      -H 'X-Forwarded-Proto: https' \
#      http://127.0.0.1:18789/api/v1/config

The root cause is missing source validation at the loopback boundary. The Gateway checked that the source IP was in `trustedProxies`, but did not distinguish between a request that arrived through the actual proxy and one that came directly from another local process.

Because same-host proxy deployments (cloudflared, Caddy on localhost) require `127.0.0.1` in `trustedProxies`, that IP check passed for any local caller.

The patch introduced `gateway.auth.trustedProxy.allowLoopback`, which defaults to `false`. Without it, any request arriving from a loopback address carrying forwarded-header evidence is now rejected with `trusted_proxy_loopback_source` rather than being trusted.

Operators who legitimately run the proxy on the same host must now explicitly opt in with `allowLoopback: true` and are advised to also configure `requiredHeaders` to demand a proxy-owned header (such as a signed assertion) that an arbitrary local process cannot easily forge.

This maps to CWE-290 (Authentication Bypass by Spoofing) and CWE-863 (Incorrect Authorization).

The fix

Upgrade to `openclaw@2026.5.18` or later. The patched version rejects loopback-sourced trusted-proxy requests by default.

If your proxy legitimately runs on the same host (cloudflared, local Caddy), add `gateway.auth.trustedProxy.allowLoopback: true` explicitly, then harden further with `requiredHeaders` pointing at a header your proxy always sets and a local attacker cannot easily replicate.

Keep the Gateway port inaccessible to other local processes where possible (e.g., bind to a Unix socket or a dedicated loopback address your proxy owns).

Reporter not attributed.

References: [1][2]

Related research