English | Português Brasileiro

• 0.2.x is the current supported line

• Do not open a public GitHub issue for security-sensitive problems
• Email the maintainer at daniloaguiarbr@proton.me
• Include a clear description and attack scenario
• Include steps to reproduce and the affected version
• Include expected versus actual behaviour
• Include known mitigations when available

• Critical (CVSS 9.0-10.0): acknowledge within 24 hours
• High (CVSS 7.0-8.9): acknowledge within 48 hours
• Medium (CVSS 4.0-6.9): acknowledge within 72 hours
• Low (CVSS 0.1-3.9): acknowledge within 5 business days

• Critical: target fix or mitigation within 7 days after confirmation
• High: target fix within 14 days after confirmation
• Medium: target fix within 30 days after confirmation
• Low: target fix in the next scheduled release window

• Coordinate disclosure timing with the reporter
• Prefer private fixes before public advisory text
• Credit reporters who want recognition after the fix ships

• Security fixes ship in patch releases when possible
• CHANGELOG entries mark security fixes under Security
• Users should upgrade to the latest supported patch promptly

• No public security reports have been credited yet
• Legitimate reporters may be listed here after coordinated disclosure

• A self-spawned Chrome no longer opens a DevTools TCP port and runs with --remote-debugging-pipe
• On POSIX hosts Chrome reads DevTools commands from descriptor 3 and writes replies to descriptor 4
• A WebSocket bridge on 127.0.0.1 relays exactly one valid client between that pipe and chromiumoxide
• The bridge path holds the 122 random bits of a v4 UUID
• The bridge answers every other path with 403 and exposes no /json/version endpoint
• The bridge closes its listener once that client completes the handshake
• The bridge caps each DevTools message at 256 MiB and waits at most 2 seconds for its pipe threads at teardown
• The private Xvfb of a headed Linux launch requires a MIT-MAGIC-COOKIE-1
• The cookie lives in a mode 0600 file passed to Xvfb with -auth and to Chrome through XAUTHORITY
• That file is removed at teardown, and the next launch removes a file whose creator pid no longer exists
• Unchanged in 0.2.0: the Lightpanda engine and the legacy launch path enabled by config set chrome_legacy_oxide_launch true still use a DevTools TCP port on loopback
• Not validated in 0.2.0: the Windows pipe path through --remote-debugging-io-pipes was neither compiled nor tested
• Not validated in 0.2.0: macOS was not tested live for the pipe transport
• A Chrome descendant that calls setsid leaves the process group and is out of reach of the group kill of a failed launch

• Keep Chrome or Chromium updated on the host
• Never pass secrets on argv when stdin alternatives exist
• Treat --ignore-robots as an explicit high-risk choice
• Store encryption material with browser-automation-cli config set encryption_key <secret> (XDG config only)
• Keep encryption keys and cookie values out of shell history and durable logs
• Prefer --json pipelines that discard stderr secrets from durable logs
• Do not point the CLI at untrusted pages without isolation expectations
• Never use rediss:// for cache (plain TCP only; rediss:// is fail-closed)
• Store Redis URL only with config set cache_redis_url under XDG (never product env vars)
• Store LLM keys only with config set openrouter_api_key under XDG
• Store egress proxy credentials only with config set proxy_username and config set proxy_password under XDG, and never pass them on argv, because the process table exposes argv to any user on the machine
• proxy_password is included in the zeroize sweeps of src/xdg/secrets.rs, so it is wiped on drop alongside encryption_key, openrouter_api_key, and cache_redis_url
• Do not confuse the egress proxy (--proxy, XDG proxy_url) with the local MITM interception proxy below: the first routes your traffic out through a third party, the second decrypts your own traffic on 127.0.0.1
• Residual hygiene: doctor residual_disk reports local orphan temp dirs; BORN/FINALIZE scavenge only owned CLI markers and stale Singleton-only Chromium dirs (never kill host Flatpak Chrome)

• Bind and use MITM only on 127.0.0.1 (one-shot local proxy; do not expose it on LAN or public interfaces)
• Keep the local CA under XDG data (mitm/ca) and protect host trust-store installs
• Prefer mitm init-ca and leave CA material under the XDG data path reported by config path
• Prefer short one-shots: mitm start --seconds N or mitm capture-url <url> --seconds N [--har path]
• Export HAR with mitm har --out <path> (required) or global --mitm-har on FINALIZE when --mitm is active
• Redact secrets on export: mitm redact --secrets and/or global --mitm-redact-secrets (Authorization/Cookie redaction)
• Do not expose the MITM proxy beyond the operator machine
• Treat captures, HAR exports, and CA private material as sensitive
• Clean up capture artifacts under XDG state (mitm/) after analysis
• Related MITM surface: status|list|get|har|export|domains|apis|init-ca|start|capture-url|graphql|ws|block|allow|redact