PR #60833: fix(browser): SSRF policy blocks loopback CDP control-plane connections

• Repository: openclaw/openclaw
• Author: GodsBoy
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/60833

Description (problem / solution / changelog)

Summary

• Problem: browser.ssrfPolicy.dangerouslyAllowPrivateNetwork: false blocks CDP control-plane reachability checks to 127.0.0.1, making local browser profiles report running: false and PortInUseError despite a healthy browser.
• Why it matters: Users who set SSRF policy to protect against malicious navigation targets unintentionally break OpenClaw's own CDP management channel, making all browser commands fail.
• What changed: Removed ssrfPolicy argument from isChromeReachable/isChromeCdpReady calls in CDP control-plane context (server-context.availability.ts, server-context.ts). Updated matching test assertions.
• What did NOT change (scope boundary): Navigation-time SSRF enforcement in navigation-guard.ts is completely untouched. The SSRF policy still applies to browser navigation targets.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #60804
• Related #45153, #57055, #49815, #49786
• This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

• Root cause: resolveBrowserSsrFPolicy() with dangerouslyAllowPrivateNetwork: false produces {} (empty truthy object). This policy is passed to CDP control-plane checks (isChromeReachable, isChromeCdpReady), which call assertCdpEndpointAllowed → shouldSkipPrivateNetworkChecks → returns false → assertAllowedHostOrIpOrThrow("127.0.0.1") → loopback is in BLOCKED_IPV4_SPECIAL_USE_RANGES → throws SsrFBlockedError, silently caught → returns false.
• Missing detection / guardrail: No test covered the combination of dangerouslyAllowPrivateNetwork: false + loopback CDP endpoint.
• Prior context: SSRF policy was added broadly to all CDP calls without distinguishing control-plane from navigation-plane.
• Why this regressed now: Reported when a user configured dangerouslyAllowPrivateNetwork: false on a Debian VPS with local Brave CDP.
• If unknown, what was ruled out: N/A — root cause is confirmed.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: server-context.ensure-browser-available.waits-for-cdp-ready.test.ts
• Scenario the test should lock in: isChromeReachable and isChromeCdpReady are called without ssrfPolicy for control-plane checks.
• Why this is the smallest reliable guardrail: Verifies the call-site contract without needing real network or browser.
• Existing test that already covers this (if any): Updated the existing reuses a pre-existing loopback browser test to assert no ssrfPolicy arg.
• If no new test is added, why not: The existing test was updated to enforce the new contract.

User-visible / Behavior Changes

• browser status will correctly show running: true for healthy local CDP browsers when dangerouslyAllowPrivateNetwork: false is set.
• browser tabs will work correctly instead of showing "No tabs".
• browser open will attach to existing browser instead of throwing PortInUseError.

Diagram (if applicable)

Before:
[isChromeReachable(cdpUrl, timeout, ssrfPolicy:{})] -> assertCdpEndpointAllowed -> SsrFBlockedError -> false

After:
[isChromeReachable(cdpUrl, timeout)] -> assertCdpEndpointAllowed(no policy) -> skips SSRF check -> HTTP probe -> true/false

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No — same CDP HTTP/WS probes, just without SSRF gating on the control plane
• Command/tool execution surface changed? No
• Data access scope changed? No
• Note: The CDP endpoint is an explicitly configured, trusted control channel. SSRF protection for browser navigation targets remains fully intact via navigation-guard.ts.

Repro + Verification

Environment

• OS: Debian 13 VPS (reported); any OS with local CDP browser
• Runtime/container: Node 22+
• Model/provider: N/A
• Integration/channel (if any): Browser tool
• Relevant config (redacted): browser.ssrfPolicy.dangerouslyAllowPrivateNetwork: false

Steps

1. Configure browser.ssrfPolicy.dangerouslyAllowPrivateNetwork: false
2. Start a local Brave/Chrome with CDP on 127.0.0.1:18800
3. Run openclaw browser status

Expected

• running: true, tabs listed

Actual (before fix)

• running: false, tabCount: 0, PortInUseError on attach

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Test reuses a pre-existing loopback browser after an initial short probe miss failed before the fix (expected ssrfPolicy arg) and passes after (no ssrfPolicy arg in control-plane calls).

Human Verification (required)

• Verified scenarios: All browser extension tests pass (pnpm test -- extensions/browser); navigation-guard tests pass independently; pnpm check clean.
• Edge cases checked: Confirmed navigation-guard.ts SSRF enforcement is untouched via its own passing test suite (17 tests).
• What you did not verify: Live end-to-end test with a real Brave CDP endpoint on Debian VPS (requires specific hardware setup from issue reporter).

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No

Risks and Mitigations

• Risk: Reduced SSRF coverage for CDP control-plane connections.
  • Mitigation: CDP endpoints are explicitly configured trusted channels. Navigation-time SSRF enforcement (the actual protection surface) remains intact. The CDP endpoint address comes from user config, not from untrusted input.

Changed files

• extensions/browser/src/browser/server-context.availability.ts (modified, +11/-2)
• extensions/browser/src/browser/server-context.ensure-browser-available.waits-for-cdp-ready.test.ts (modified, +8/-7)
• extensions/browser/src/browser/server-context.ts (modified, +1/-1)