Affected: Homebrew: openclaw-cli

## 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 re…

Affected: OpenClaw

OpenClaw versions 2026.1.29-beta.1 prior to 2026.2.14 contain a vulnerability in the sandbox browser bridge server in which it accepts requests without requiring gateway authentication, allowing local attackers to access browser control endpoints. A local attacker can enumerate tabs, retrieve WebSocket URLs, execute JavaScript, and exfiltrate cookies and session data from authenticated browser contexts.