CVE-2026-3690

OpenClaw Canvas Authentication Bypass Vulnerability. This vulnerability allows remote attackers to bypass authentication on affected installations of OpenClaw. Authentication is not required to exploit this vulnerability.

The specific flaw exists within the implementation of the the authentication function for canvas endpoints. The issue results from improper implementation of authentication. An attacker can leverage this vulnerability to bypass authentication on the system. Was ZDI-CAN-29311.

OpenClaw Canvas Authentication Bypass Vulnerability. This vulnerability allows remote attackers to bypass authentication on affected installations of OpenClaw. Authentication is not required to exploit this vulnerability.

The specific flaw exists within the implementation of the the authentication function for canvas endpoints. The issue results from improper implementation of authentication. An attacker can leverage this vulnerability to bypass authentication on the system. Was ZDI-CAN-29311.

OpenClaw Canvas Authentication Bypass Vulnerability. This vulnerability allows remote attackers to bypass authentication on affected installations of OpenClaw. Authentication is not required to exploit this vulnerability.

The specific flaw exists within the implementation of the the authentication function for canvas endpoints. The issue results from improper implementation of authentication. An attacker can leverage this vulnerability to bypass authentication on the system. Was ZDI-CAN-29311.

ZDI-CAN-29311: OpenClaw Canvas Authentication Bypass Vulnerability

-- ABSTRACT -------------------------------------

Trend Micro's Zero Day Initiative has identified a vulnerability affecting the following products: OpenClaw - OpenClaw

-- VULNERABILITY DETAILS ------------------------

• Version tested: openclaw 2026.2.17
• Platform tested: macOS 26.3

Analysis

Description

The OpenClaw gateway's authorizeCanvasRequest() function implements an IP-based authentication fallback for canvas endpoints (/__openclaw__/a2ui/, /__openclaw__/canvas/, /__openclaw__/ws). When a WebSocket client authenticates from a private IP address, ALL subsequent HTTP requests from that same IP are granted canvas access without requiring their own authentication token.

In environments where multiple clients share a single IP address ��� corporate NAT, VPN concentrators, Kubernetes clusters, Docker host-mode networking ��� an unauthenticated attacker on the same network is granted full canvas access by virtue of sharing an IP with a legitimate authenticated client.

Root Cause

Three functions in src/gateway/server-http.ts create this vulnerability:

1. IP-matching function (line ~100)

function hasAuthorizedWsClientForIp(clients: Set<GatewayWsClient>, clientIp: string): boolean {
  for (const client of clients) {
    if (client.clientIp && client.clientIp === clientIp) {
      return true;
    }
  }
  return false;
}

This function checks if ANY connected WebSocket client shares the same IP. It does not verify that the HTTP request belongs to the same user, session, or browser as the WS client.

2. IP-based fallback in authorizeCanvasRequest (line ~109)

async function authorizeCanvasRequest(params: { ... }): Promise<GatewayAuthResult> {
  // ... token check first ...

  const clientIp = resolveGatewayClientIp({ ... });

  // Only allow fallback for private/loopback addresses
  if (!isPrivateOrLoopbackAddress(clientIp)) {
    return lastAuthFailure ?? { ok: false, reason: "unauthorized" };
  }

  // THE VULNERABILITY: grants access based on IP alone
  if (hasAuthorizedWsClientForIp(clients, clientIp)) {
    return { ok: true };
  }

  return lastAuthFailure ?? { ok: false, reason: "unauthorized" };
}

If the HTTP request comes from a private IP that matches any authenticated WS client, access is granted without verifying the request's own credentials.

3. Canvas path routing

function isCanvasPath(pathname: string): boolean {
  return (
    pathname === A2UI_PATH ||              // /__openclaw__/a2ui
    pathname.startsWith(`${A2UI_PATH}/`) ||
    pathname === CANVAS_HOST_PATH ||        // /__openclaw__/canvas
    pathname.startsWith(`${CANVAS_HOST_PATH}/`) ||
    pathname === CANVAS_WS_PATH            // /__openclaw__/ws
  );
}

All canvas endpoints use this weaker authentication path instead of the standard authorizeGatewayConnect() which requires a valid token.

Attack Scenario

Corporate NAT Environment

1. A company runs an OpenClaw gateway on an internal server with --bind lan and a token for authentication.
2. Developer Alice connects her OpenClaw desktop app via WebSocket using her valid token. The gateway records her IP as the corporate NAT address (e.g., 10.0.0.1).
3. Attacker Bob, on the same corporate network, also appears as 10.0.0.1 to the gateway (NAT).
4. Bob sends an HTTP request to http://gateway:18789/__openclaw__/a2ui/ with NO authentication header.
5. authorizeCanvasRequest() checks: Is 10.0.0.1 a private IP? Yes. Is there a WS client from 10.0.0.1? Yes (Alice). Access granted.
6. Bob now has full access to all canvas endpoints ��� the A2UI interface, canvas content, and the canvas WebSocket ��� without ever authenticating.

Kubernetes / Docker Environments

In containerized deployments using shared networking (host mode, pod networking), multiple containers share the same IP. One…

OpenClaw Canvas Authentication Bypass Vulnerability. This vulnerability allows remote attackers to bypass authentication on affected installations of OpenClaw. Authentication is not required to exploit this vulnerability.

The specific flaw exists within the implementation of the the authentication function for canvas endpoints. The issue results from improper implementation of authentication. An attacker can leverage this vulnerability to bypass authentication on the system. Was ZDI-CAN-29311.

OpenClaw Canvas Authentication Bypass Vulnerability. This vulnerability allows remote attackers to bypass authentication on affected installations of OpenClaw. Authentication is not required to exploit this vulnerability.

The specific flaw exists within the implementation of the the authentication function for canvas endpoints. The issue results from improper implementation of authentication. An attacker can leverage this vulnerability to bypass authentication on the system. Was ZDI-CAN-29311.

ZDI-CAN-29311: OpenClaw Canvas Authentication Bypass Vulnerability

-- ABSTRACT -------------------------------------

Trend Micro's Zero Day Initiative has identified a vulnerability affecting the following products: OpenClaw - OpenClaw

-- VULNERABILITY DETAILS ------------------------

• Version tested: openclaw 2026.2.17
• Platform tested: macOS 26.3

Analysis

Description

The OpenClaw gateway's authorizeCanvasRequest() function implements an IP-based authentication fallback for canvas endpoints (/__openclaw__/a2ui/, /__openclaw__/canvas/, /__openclaw__/ws). When a WebSocket client authenticates from a private IP address, ALL subsequent HTTP requests from that same IP are granted canvas access without requiring their own authentication token.

In environments where multiple clients share a single IP address ��� corporate NAT, VPN concentrators, Kubernetes clusters, Docker host-mode networking ��� an unauthenticated attacker on the same network is granted full canvas access by virtue of sharing an IP with a legitimate authenticated client.

Root Cause

Three functions in src/gateway/server-http.ts create this vulnerability:

1. IP-matching function (line ~100)

function hasAuthorizedWsClientForIp(clients: Set<GatewayWsClient>, clientIp: string): boolean {
  for (const client of clients) {
    if (client.clientIp && client.clientIp === clientIp) {
      return true;
    }
  }
  return false;
}

This function checks if ANY connected WebSocket client shares the same IP. It does not verify that the HTTP request belongs to the same user, session, or browser as the WS client.

2. IP-based fallback in authorizeCanvasRequest (line ~109)

async function authorizeCanvasRequest(params: { ... }): Promise<GatewayAuthResult> {
  // ... token check first ...

  const clientIp = resolveGatewayClientIp({ ... });

  // Only allow fallback for private/loopback addresses
  if (!isPrivateOrLoopbackAddress(clientIp)) {
    return lastAuthFailure ?? { ok: false, reason: "unauthorized" };
  }

  // THE VULNERABILITY: grants access based on IP alone
  if (hasAuthorizedWsClientForIp(clients, clientIp)) {
    return { ok: true };
  }

  return lastAuthFailure ?? { ok: false, reason: "unauthorized" };
}

If the HTTP request comes from a private IP that matches any authenticated WS client, access is granted without verifying the request's own credentials.

3. Canvas path routing

function isCanvasPath(pathname: string): boolean {
  return (
    pathname === A2UI_PATH ||              // /__openclaw__/a2ui
    pathname.startsWith(`${A2UI_PATH}/`) ||
    pathname === CANVAS_HOST_PATH ||        // /__openclaw__/canvas
    pathname.startsWith(`${CANVAS_HOST_PATH}/`) ||
    pathname === CANVAS_WS_PATH            // /__openclaw__/ws
  );
}

All canvas endpoints use this weaker authentication path instead of the standard authorizeGatewayConnect() which requires a valid token.

Attack Scenario

Corporate NAT Environment

1. A company runs an OpenClaw gateway on an internal server with --bind lan and a token for authentication.
2. Developer Alice connects her OpenClaw desktop app via WebSocket using her valid token. The gateway records her IP as the corporate NAT address (e.g., 10.0.0.1).
3. Attacker Bob, on the same corporate network, also appears as 10.0.0.1 to the gateway (NAT).
4. Bob sends an HTTP request to http://gateway:18789/__openclaw__/a2ui/ with NO authentication header.
5. authorizeCanvasRequest() checks: Is 10.0.0.1 a private IP? Yes. Is there a WS client from 10.0.0.1? Yes (Alice). Access granted.
6. Bob now has full access to all canvas endpoints ��� the A2UI interface, canvas content, and the canvas WebSocket ��� without ever authenticating.

Kubernetes / Docker Environments

In containerized deployments using shared networking (host mode, pod networking), multiple containers share the same IP. One…