🔒 Aisle Security Analysis

We found 1 potential security issue(s) in this PR:

1. 🟡 Default profile now uses unauthenticated Chrome DevTools Protocol (CDP) endpoint (local privilege boundary bypass)

Description

The default browser profile selection was changed to prefer the openclaw managed profile. That profile launches a local Chrome instance exposing a raw CDP TCP port (Chrome DevTools Protocol), which provides full browser control.

While the control server itself binds to loopback and has auth middleware, the Chrome CDP endpoint is not authenticated (Chrome’s remote debugging port has no built-in auth). With openclaw now being the default, deployments that previously used the token-gated chrome extension relay by default will now commonly have an unauthenticated CDP port available on localhost, allowing any local process/user with network access to 127.0.0.1:<cdpPort> to:

• Control the browser (navigate, read DOM, take screenshots, etc.)
• Potentially exfiltrate sensitive data from active sessions
• Bypass OpenClaw’s higher-level auth controls by talking directly to CDP

Changed default selection (now prefers openclaw):

const defaultProfile = defaultProfileFromConfig ??
  (profiles[DEFAULT_BROWSER_DEFAULT_PROFILE_NAME]
    ? DEFAULT_BROWSER_DEFAULT_PROFILE_NAME
    : profiles[DEFAULT_OPENCLAW_BROWSER_PROFILE_NAME]
      ? DEFAULT_OPENCLAW_BROWSER_PROFILE_NAME
      : "chrome");

CDP is exposed via a listening port when launching Chrome:

const args: string[] = [
  `--remote-debugging-port=${profile.cdpPort}`,
  ​// ...
];

Notes on exposure:

• By default, the code constructs local CDP URLs using 127.0.0.1 and refuses to launch Chrome for non-loopback profiles, so this is not a remote bind-by-default issue.
• The risk is still meaningful in multi-tenant/shared-host environments or anywhere loopback is reachable by less-trusted local processes (including other containers sharing the network namespace).

Recommendation

Mitigate by ensuring the default path does not expose an unauthenticated CDP port, or by hardening how CDP is exposed:

1. Safer defaults / explicit opt-in

• Consider keeping chrome (extension relay with token gating) as default, or require browser.defaultProfile: "openclaw" explicit opt-in in server/multi-tenant modes.

2. Bind defensively (explicit loopback)

• When launching Chrome, explicitly bind remote debugging to loopback (defense-in-depth):

const args = [
  `--remote-debugging-port=${profile.cdpPort}`,
  "--remote-debugging-address=127.0.0.1",
  ​// ...
];

3. Avoid a TCP listener altogether (best)

• Prefer --remote-debugging-pipe (where feasible) and route CDP through the authenticated control server instead of a raw port.

4. Warn/fail on non-loopback CDP endpoints unless explicitly allowed

• If browser.cdpUrl / profile cdpUrl is set to a non-loopback host, require an explicit dangerouslyAllowRemoteCdp: true and log a prominent warning.

Analyzed PR: #32031 at commit 4536357

_{Last updated on: 2026-03-02T19:10:17Z}

Greptile Summary

This PR successfully changes the default browser profile from chrome (extension relay) to openclaw (managed standalone CDP) to improve out-of-the-box experience for users without the Chrome extension. The implementation is correct:

• Updated constant DEFAULT_BROWSER_DEFAULT_PROFILE_NAME from "chrome" to "openclaw" in constants.ts
• Simplified profile resolution logic in config.ts by removing the headless/noSandbox conditional preference
• Comprehensive test updates verify the new default behavior while ensuring explicit defaultProfile: "chrome" configs still work
• CHANGELOG entry accurately documents the behavior change

Documentation gap: Multiple documentation files (docs/tools/browser.md lines 52 and 100, docs/tools/index.md line 319, and Chinese translations) still state that chrome is the default profile. These should be updated to reflect that openclaw is now the default, and users who want the extension relay should explicitly set defaultProfile: "chrome".

Minor code quality note: The default profile resolution logic (lines 269-273 in config.ts) now checks for the same profile name twice since both constants point to "openclaw", though this doesn't affect functionality.

Confidence Score: 4/5

• This PR is safe to merge with one documentation update needed
• The code changes are straightforward and well-tested. The logic correctly implements the intended behavior of defaulting to openclaw profile. Tests comprehensively cover the default behavior and explicit overrides. The only concern is outdated documentation that should be updated in a follow-up to prevent user confusion.
• Documentation files not included in this PR (docs/tools/browser.md, docs/tools/index.md, and translations) should be updated to reflect the new default profile behavior

_{Last reviewed commit: a9a44ab}

Landed via temp rebase onto main.

• Gate: bunx vitest run src/browser/config.test.ts src/browser/profiles-service.test.ts
• Land commit: 4536357
• Merge commit: 1727279

Thanks @liuxiaopai-ai!