CVE-2026-22174: Openclaw Authentication Bypass Vulnerability

CVE-2026-22174 Overview

CVE-2026-22174 is an information disclosure vulnerability in OpenClaw, a Node.js browser automation tool. Versions prior to 2026.2.22 inject the x-OpenClaw-relay-token header into Chrome DevTools Protocol (CDP) probe traffic on loopback interfaces, allowing local processes to capture the Gateway authentication token. An attacker controlling a loopback port can intercept CDP reachability probes to the /json/version endpoint and reuse the leaked token as Gateway bearer authentication.

Critical Impact

Local attackers can capture Gateway authentication tokens from CDP probe traffic, enabling unauthorized access to OpenClaw Gateway services with the privileges of the compromised token.

Affected Products

• OpenClaw versions prior to 2026.2.22
• OpenClaw for Node.js (all affected versions)
• Systems running OpenClaw with Gateway authentication enabled

Discovery Timeline

• 2026-03-18 - CVE-2026-22174 published to NVD
• 2026-03-19 - Last updated in NVD database

Technical Details for CVE-2026-22174

Vulnerability Analysis

This vulnerability falls under CWE-306 (Missing Authentication for Critical Function). The core issue stems from OpenClaw's extension relay authentication mechanism, which improperly exposed Gateway authentication tokens through CDP probe requests sent to loopback interfaces. When OpenClaw probes browser instances to establish CDP connections, it includes the sensitive x-OpenClaw-relay-token header in HTTP requests to the /json/version endpoint. Any process listening on loopback ports could intercept these probes and extract the authentication token.

The leaked token provides full bearer authentication to the OpenClaw Gateway, meaning an attacker with local access could impersonate legitimate OpenClaw sessions, potentially accessing or manipulating automated browser workflows.

Root Cause

The vulnerability exists because the original implementation did not properly scope or derive authentication tokens for relay probes. The Gateway authentication token was directly included in CDP probe requests without consideration for the security implications of sending credentials to potentially untrusted local endpoints. The fix introduces a derived token mechanism using HMAC-SHA256, creating port-specific tokens that cannot be used to authenticate against the Gateway directly.

Attack Vector

Exploitation requires local access to the system running OpenClaw. An attacker must:

1. Establish a listener on a loopback interface port that OpenClaw may probe
2. Wait for OpenClaw to send CDP reachability probes to the /json/version endpoint
3. Capture the x-OpenClaw-relay-token header from the intercepted request
4. Reuse the captured token as bearer authentication against the OpenClaw Gateway

The security patch introduces a proper token derivation function that creates port-specific tokens, preventing captured tokens from being reused for Gateway authentication:

+import { createHmac } from "node:crypto";
+import { loadConfig } from "../config/config.js";
+
+const RELAY_TOKEN_CONTEXT = "openclaw-extension-relay-v1";
+const DEFAULT_RELAY_PROBE_TIMEOUT_MS = 500;
+const OPENCLAW_RELAY_BROWSER = "OpenClaw/extension-relay";
+
+function resolveGatewayAuthToken(): string | null {
+  const envToken =
+    process.env.OPENCLAW_GATEWAY_TOKEN?.trim() || process.env.CLAWDBOT_GATEWAY_TOKEN?.trim();
+  if (envToken) {
+    return envToken;
+  }
+  try {
+    const cfg = loadConfig();
+    const configToken = cfg.gateway?.auth?.token?.trim();
+    if (configToken) {
+      return configToken;
+    }
+  } catch {
+    // ignore config read failures; caller can fallback to per-process random token
+  }
+  return null;
+}
+
+function deriveRelayAuthToken(gatewayToken: string, port: number): string {
+  return createHmac("sha256", gatewayToken).update(`${RELAY_TOKEN_CONTEXT}:${port}`).digest("hex");
+}
+
+export function resolveRelayAuthTokenForPort(port: number): string {

Source: GitHub Commit Change

Detection Methods for CVE-2026-22174

Indicators of Compromise

• Unusual processes listening on loopback ports commonly used by browser debugging (e.g., ports 9222, 9229, or dynamic ports)
• Network traffic containing x-OpenClaw-relay-token headers captured by unauthorized processes
• Unexpected Gateway authentication attempts using tokens associated with local relay probes
• Logs showing CDP probe requests to unknown or suspicious local endpoints

Detection Strategies

• Monitor for processes binding to loopback ports that may intercept CDP traffic
• Implement logging for Gateway authentication events and correlate with expected OpenClaw session activity
• Audit local network listeners on development and automation systems running OpenClaw
• Review application logs for anomalous /json/version endpoint access patterns

Monitoring Recommendations

• Enable verbose logging for OpenClaw Gateway authentication events
• Deploy endpoint detection solutions to monitor for suspicious loopback port listeners
• Implement network monitoring on development systems to detect potential token interception attempts
• Regularly audit running processes and their network bindings on systems using OpenClaw

How to Mitigate CVE-2026-22174

Immediate Actions Required

• Upgrade OpenClaw to version 2026.2.22 or later immediately
• Rotate any Gateway authentication tokens that may have been exposed
• Audit systems for unauthorized processes that may have captured relay tokens
• Review Gateway access logs for suspicious authentication patterns

Patch Information

The vulnerability has been addressed in OpenClaw version 2026.2.22. The fix implements a hardened extension relay authentication token flow that derives port-specific tokens using HMAC-SHA256 with a context string, preventing captured relay tokens from being reused for Gateway authentication.

The patch is available via the GitHub Commit. Additional details can be found in the GitHub Security Advisory.

Workarounds

• Restrict which processes can bind to loopback interfaces on systems running OpenClaw
• Implement network isolation for development and automation environments
• Use firewall rules to limit loopback interface access to trusted processes only
• Consider running OpenClaw in containerized environments with restricted network namespaces

# Example: Restrict loopback port binding (Linux iptables)
# Allow only specific UIDs to bind to common CDP debugging ports
iptables -A OUTPUT -o lo -p tcp --dport 9222 -m owner ! --uid-owner openclaw -j DROP
iptables -A OUTPUT -o lo -p tcp --dport 9229 -m owner ! --uid-owner openclaw -j DROP