OpenClaw has an authentication bypass in sandbox browser bridge server

Summary

openclaw could start the sandbox browser bridge server without authentication.

When the sandboxed browser is enabled, openclaw runs a local (loopback) HTTP bridge that exposes browser control endpoints (for example /profiles, /tabs, /tabs/open, /agent/*). Due to missing auth wiring in the sandbox initialization path, that bridge server accepted requests without requiring gateway auth.

Impact

A local attacker (any process on the same machine) could access the bridge server port and:

• enumerate open tabs and retrieve CDP WebSocket URLs
• open/close/navigate tabs
• execute JavaScript in page contexts via CDP
• exfiltrate cookies/session data and page contents from authenticated sessions

This is a localhost-only exposure (CVSS AV:L), but provides full browser-session compromise for sandboxed browser usage.

Affected Versions

• Introduced in: 2026.1.29-beta.1 (first npm release that shipped the sandbox browser bridge)
• Affected range: >=2026.1.29-beta.1 <2026.2.14

Patched Versions

• 2026.2.14

Mitigation

• Upgrade to 2026.2.14 (recommended).
• Or disable the sandboxed browser (agents.defaults.sandbox.browser.enabled=false).

Fix Details

• The sandbox browser bridge server now always requires auth and enforces the same gateway browser control auth (token/password) that loopback browser clients already use.
• Additional hardening: bridge server refuses non-loopback binds; local helper servers are bound to loopback.
• Added regression tests (including unit coverage for per-port bridge auth fallback).

Fix commits:

• openclaw/openclaw@4711a943e30bc58016247152ba06472dab09d0b0
• openclaw/openclaw@6dd6bce997c48752134f2d6ed89b27de01ced7e3
• openclaw/openclaw@cd84885a4ac78eadb7bf321aae98db9519426d67

Credits

Thanks to Adnan Jakati (@jackhax) of Praetorian for reporting this issue.