Canvas auth bypass exposes OpenClaw gateway endpoints
TL;DR — A High-severity auth bypass in openclaw’s canvas endpoints can grant unauthenticated access when clients share an IP (NAT/VPN/Kubernetes), breaking token-based protections for the UI/canvas surface.
What happened
OpenClaw is an npm-distributed gateway/client system that exposes HTTP and WebSocket endpoints (including a “canvas” / UI surface) for interacting with the service.
CVE-2026-3690 is a High severity authentication-bypass issue (CVSS v3 base score 7.4) affecting OpenClaw’s canvas endpoints. The vulnerable behavior (per the linked GitHub advisory referenced by Tenable) is an IP-based authentication fallback in the gateway’s authorizeCanvasRequest() logic: once any WebSocket client from a given private/loopback IP authenticates, subsequent HTTP requests from that same IP may be treated as authorized for canvas access without requiring their own token.
This becomes exploitable in any environment where multiple clients can share a single apparent source IP (corporate NAT, VPN concentrators, Kubernetes pod/cluster networking, Docker host-mode/shared networks), enabling an unauthenticated attacker on the same network/IP to reach sensitive canvas endpoints.
| Item | Source value |
|---|---|
| Affected package | npm openclaw |
| Impact | Authentication bypass on canvas endpoints |
| CVSS v3 | 7.4 (High) |
| Affected versions | <= 2026.2.17 |
| Patched versions | >= 2026.2.19 |
AuthZ/AuthN decisions based on IP “trust” are a recurring failure mode in modern shared-network deployments—especially when WebSockets and HTTP endpoints don’t enforce the same per-request identity checks.
Who is impacted
- Deployments using npm
openclawversions<= 2026.2.17. - Environments where the OpenClaw gateway is reachable by multiple clients that can share a source IP as seen by the gateway (NAT, VPN, Kubernetes, Docker shared networking).
- Installations that expose the canvas endpoints noted in the advisory (e.g.,
/__openclaw__/a2ui/,/__openclaw__/canvas/,/__openclaw__/ws), since these routes follow the weaker canvas authorization path. - Teams relying on gateway tokens/headers as the primary access control boundary for the UI/canvas surface (because the bypass can remove the need for those credentials in shared-IP scenarios).
What to do now
- Follow vendor remediation guidance and apply a patched release.
- The referenced GitHub advisory lists patched versions
>= 2026.2.19foropenclaw.
- The referenced GitHub advisory lists patched versions
- Treat “shared IP” as a first-class threat model:
- Avoid exposing the OpenClaw gateway to networks where untrusted clients can share an IP with trusted clients (common with corporate NAT/VPN and some container networking setups).
- Where feasible, constrain access at the network layer (allowlists, segmentation, and restricting which subnets can reach the gateway).
- Validate auth-policy parity across protocols:
- Ensure HTTP endpoints enforce per-request auth even if a WebSocket from the same environment is authenticated (the core bug class here is protocol/path-specific auth drift).
- If you suspect exposure, review gateway access logs for unauthenticated requests reaching canvas endpoints and rotate any secrets/tokens accessible through the affected UI surface.
Additional Information
- Tenable’s CVE entry references both the Zero Day Initiative advisory and the upstream GitHub Security Advisory for technical details and affected/patched ranges:
https://www.zerodayinitiative.com/advisories/ZDI-26-228/https://github.com/openclaw/openclaw/security/advisories/GHSA-vvjh-f6p9-5vcf
Content is AI-assisted and reviewed by our team, but issues may be missed and best practices evolve rapidly, send corrections to [email protected]. Always consult official documentation and validate key implementation decisions before making design or security choices.