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…

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