GHSA-CJV3-M589-V3RX: Authorization Bypass in OpenClaw Gateway via Shared-IP Fallback

The OpenClaw Gateway functions as the central orchestration point for AI agents, managing WebSocket connections from nodes and serving HTTP interfaces for user interaction. Specifically, the Gateway exposes 'Canvas' (/__openclaw__/canvas/*) and 'A2UI' (Agent-to-User Interface, /__openclaw__/a2ui/*) routes, which provide visual interfaces for monitoring and interacting with AI workflows.

In affected versions, the Gateway implemented a permissive authorization strategy designed to facilitate ease of use for Node WebViews. This strategy included a "shared-IP fallback" mechanism: if an incoming HTTP request originated from an IP address currently associated with an active, authenticated Node WebSocket session, the request was automatically authorized. This design assumed that IP addresses were unique identifiers of trust, an assumption that fails in modern network environments involving NAT, CGNAT, VPNs, and shared proxies.

Consequently, the authentication boundary was effectively lowered to network positioning. Any actor capable of presenting the same source IP as a trusted node—whether by sharing a local network or spoofing X-Forwarded-For headers behind a misconfigured proxy—could bypass all application-level authentication checks.

The technical root cause resides in the authorizeCanvasRequest function within src/gateway/server-http.ts. The logic prioritized convenience over security by checking if the request's resolved IP address matched the IP of any currently connected Node. This implementation failed to verify the role of the connected client or require a cryptographic token for the HTTP session.

Furthermore, the IP resolution logic, handled by resolveGatewayClientIp, was susceptible to manipulation. It blindly trusted headers such as X-Forwarded-For and X-Real-IP without strictly validating against a list of trusted proxies. If the Gateway was deployed behind a proxy that did not strip these headers, or if the application was directly exposed but configured to process proxy headers, an attacker could inject a loopback address (e.g., 127.0.0.1) into the X-Forwarded-For header. If a legitimate node was connected from localhost, the attacker's request would be authorized.

The flaw represents a classic CWE-290: Authentication Bypass by Spoofing and CWE-863: Incorrect Authorization, where the system relies on an identifier (IP address) that is not a definitive proof of identity.

The remediation strategy involved removing the IP-based trust model entirely and replacing it with a capability-token system. The following analysis highlights the transition from the vulnerable logic to the hardened implementation.

Vulnerable Logic (Conceptual):

The original code checked if the request IP matched a known node IP, bypassing token verification:

// src/gateway/server-http.ts (Vulnerable)
function authorizeCanvasRequest(req) {
  const clientIp = resolveGatewayClientIp(req);
  const activeNode = findNodeByIp(clientIp);
  
  // VULNERABILITY: Implicit trust based solely on IP match
  if (activeNode) {
    return true; // Access granted without token
  }
  
  return verifyToken(req);
}

Patched Logic (Commit c45f3c5b):

The fix introduces mintCanvasCapabilityToken to generate high-entropy tokens and enforces their presence in the URL path. The IP fallback is removed, and the IP resolver is hardened to fail closed.

// src/gateway/server-http.ts (Fixed)
function authorizeCanvasRequest(req) {
  // 1. IP Fallback REMOVED. Strict token verification is now mandatory.
  const token = extractTokenFromPath(req.path);
  
  if (!token || !verifyCapabilityToken(token)) {
    throw new UnauthorizedError("Invalid or missing capability token");
  }
  
  // 2. Token is validated against active sessions with TTL
  return true;
}

Additionally, commit 08a79679 hardened resolveGatewayClientIp to return undefined (fail closed) if proxy headers are present but the upstream proxy is not in the trustedProxies configuration. This prevents IP spoofing via header injection.

Attackers can exploit this vulnerability through two primary vectors, neither of which requires prior credentials.

1. Shared Network Environment (NAT/VPN): In corporate environments using NAT or VPN solutions like Tailscale, multiple users often appear to the Gateway as originating from a single IP address. If a legitimate administrator (the "Node") connects to the OpenClaw Gateway, their IP is cached as trusted. An attacker on the same VPN simply navigates to https://<gateway>/__openclaw__/canvas/. The Gateway observes the matching source IP and serves the interface, allowing the attacker to view the admin's active session.

2. Proxy Header Spoofing: If the Gateway is accessible via the public internet and processes X-Forwarded-For headers without strict trustedProxies enforcement, an attacker can forge requests. By sending X-Forwarded-For: <Target-Node-IP>, the attacker tricks the Gateway into resolving their request as coming from the trusted node. This is particularly effective if the attacker targets the loopback address (127.0.0.1) used by local agents.

The impact of this vulnerability is rated High (CVSS 8.1) due to the complete bypass of authentication for critical interfaces. Successful exploitation yields the following consequences:

• Confidentiality Loss: Attackers gain access to the 'A2UI' (Agent-to-User Interface), exposing private conversations between the user and AI agents, as well as operational logs and workflow states.
• Integrity Violation: Attackers can interact with the AI agents. If the agents are configured with tool-use capabilities (e.g., file system access, shell execution, or API interaction), the attacker can indirectly trigger these tools, potentially leading to Remote Code Execution (RCE) or data modification on the host system.
• Scope: The vulnerability affects the confidentiality and integrity of the managed nodes but does not directly crash the Gateway (Availability is unaffected).

The primary remediation is to upgrade to OpenClaw version 2026.2.22 or later. This version introduces the "Capability Token" system, which generates cryptographically secure, time-limited tokens for accessing Canvas routes, effectively decoupling authorization from network identity.

Immediate Workarounds: If an upgrade is not immediately feasible, administrators should:

1. Restrict Network Access: Ensure the Gateway is not exposed to untrusted networks. Use firewall rules to limit access to known, static IP addresses.
2. Harden Proxy Configuration: If running behind a reverse proxy (Nginx, Caddy), explicitly set the trustedProxies configuration in OpenClaw to only accept headers from the specific proxy IP. Ensure the reverse proxy strips incoming X-Forwarded-For headers from external clients.
3. Network Segmentation: Avoid running OpenClaw Gateways on shared subnets (e.g., guest Wi-Fi or flat corporate LANs) where untrusted users coexist with privileged nodes.