How should we interpret CVSS severity scores?

CVSS estimates technical severity, but it does not automatically equal business risk. Prioritize using context like internet exposure, asset criticality, known exploitation, and whether compensating controls exist. A Medium CVSS on an exposed production system can be more urgent than a Critical on an isolated non-production host.

Vulnerability Database

Q: What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

Q: What's the difference between a vulnerability, an exploit, and a zero-day?

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. Risk increases sharply when exploitation becomes reliable or widespread.

Q: Why do vulnerabilities keep reappearing in our environment?

Recurring findings usually come from incomplete asset discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host.

Q: How do we prioritize remediation without burning out the team?

Use a repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress so remediation is steady, not reactive.

Q: How can SynScan help reduce vulnerability risk over time?

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.

328,409

Total vulnerabilities in the database

OpenClaw Canvas Authentication Bypass Vulnerability

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&lt;GatewayWsClient&gt;, clientIp: string): boolean {
  for (const client of clients) {
    if (client.clientIp &amp;&amp; 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&lt;GatewayAuthResult&gt; {
  // ... token check first ...

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

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

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

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

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

A company runs an OpenClaw gateway on an internal server with --bind lan and a token for authentication.
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).
Attacker Bob, on the same corporate network, also appears as 10.0.0.1 to the gateway (NAT).
Bob sends an HTTP request to http://gateway:18789/__openclaw__/a2ui/ with NO authentication header.
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.
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 container's authentication enables canvas access for all containers on that IP.

Reproduction Steps

Prerequisites

Docker installed
Python 3
OpenClaw Docker image built as openclaw:local

Steps

Navigate to the PoC directory and start the environment:
cd vulnerabilities/04-canvas-ip-auth-bypass docker compose up -d --wait
This starts two containers on a shared Docker network:
- Gateway (172.28.0.10): Token-protected OpenClaw gateway
- Legitimate client (172.28.0.20): Connects via WebSocket with valid token, establishing IP trust
Wait a few seconds for the legitimate client to authenticate, then run the PoC:
python3 poc.py
The PoC runs three tests:

| Test | Source | Source IP | Token | Result | |------|--------|-----------|-------|--------| | 1 �� Host (different IP) | Host machine | Host bridge IP | None | 401 Unauthorized | | 2 �� Host with token (control) | Host machine | Host bridge IP | Valid | 200 OK | | 3 �� Same IP (exploit) | docker exec into legit container | 172.28.0.20 | None | 200 OK |
Test 3 is the exploit: poc.py uses docker exec to run an HTTP request from inside the legitimate client's container (IP 172.28.0.20) with no Authorization header. The gateway's authorizeCanvasRequest() matches the source IP against the authenticated WebSocket client and returns 200 OK �� granting full canvas access without credentials.
Cleanup:
docker compose down -v

Impact

Authentication Bypass: Any unauthenticated client sharing an IP with a legitimate WS-authenticated client gains full canvas endpoint access.
Information Disclosure: Canvas endpoints serve:
- The A2UI (Agent-to-User Interface) rendered content, which may contain sensitive data the AI agent is presenting to the user
- The canvas HTML/JS application
- The canvas WebSocket upgrade endpoint
Scope: Affects all deployments where the gateway is network-exposed (--bind lan) and clients share IP addresses (NAT, VPN, K8s, corporate networks).
No auth required: The attacker needs only network adjacency; no credentials, tokens, or user interaction.

-- CREDIT --------------------------------------- This vulnerability was discovered by: Peter Girnus (@gothburz) and Project AESIR of TrendAI Zero Day Initiative

-- FURTHER DETAILS ------------------------------

Supporting files: ZDI-CAN-29311.zip

If supporting files were contained with this report they are provided within a password protected ZIP file. The password is the ZDI candidate number in the form: ZDI-CAN-XXXX where XXXX is the ID number.

Zero Day Initiative zdi-disclosures@trendmicro.com

The PGP key used for all ZDI vendor communications is available from:

http://www.zerodayinitiative.com/documents/disclosures-pgp-key.asc

-- INFORMATION ABOUT THE ZDI -------------------- Established by TippingPoint and acquired by Trend Micro, the Zero Day Initiative (ZDI) neither re-sells vulnerability details nor exploit code. Instead, upon notifying the affected product vendor, the ZDI provides its Trend Micro TippingPoint customers with zero day protection through its intrusion prevention technology. Explicit details regarding the specifics of the vulnerability are not exposed to any parties until an official vendor patch is publicly available.

Please contactZero Day Initiative for further details or refer to:

http://www.zerodayinitiative.com

-- DISCLOSURE POLICY ----------------------------

Zero Day Initiative's vulnerability disclosure policy is available online at:

http://www.zerodayinitiative.com/advisories/disclosure_policy/

Fix Commit(s)

c45f3c5b004c8d63dc0e282e2176f8c9355d24f1

Published: Mar 4, 2026
Updated: Mar 5, 2026
GHSA: GHSA-vvjh-f6p9-5vcf
Severity: High
Exploit:

CVSS v3:

Severity: Unknown
Score:
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

CWEs:

CWE-291

Affected Software
References

Software	From	Fixed in
openclaw	-	2026.2.19

Deep Security Visibility Without the Complexity

SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.

No setup fees
5-min deployment
Cancel anytime

Book a Demo

Frequently Asked Questions

What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.