Critical 2026-07-11

Browser-Automation Tool Launch-Args Field Carries a Chromium Command-Replacing Switch

Some AI agent tools let a caller pass custom Chromium launch arguments when they spin up a browser for crawling or automation. If that field isn't checked, an attacker can slip in Chromium switches that replace the command Chromium uses to start its own subprocesses, turning a browser launch into arbitrary command execution.

How the attack works

An agent tool exposes a browser-configuration parameter (named things like extra_args, browser_config, chrome_args, or launch_args) that gets passed straight to Chromium at launch time. The attacker sets this field to one of four command-replacing switches -- --utility-cmd-prefix, --renderer-cmd-prefix, --gpu-launcher, or --browser-subprocess-path -- optionally adding --no-zygote to force Chromium to fork/exec through the replaced command instead of its normal internal process spawner. When Chromium starts, it launches the attacker's command instead of (or alongside) its intended subprocess. This was found in crawl4ai (CVE-2026-57572), where an existing denylist blocked proxy/DNS-related flags but missed these four switches entirely, letting one unauthenticated API request run arbitrary commands as the container's runtime user.

Netzilo detection

Netzilo reports this behaviour when it is observed.

Signature ID: 6dca8ebc-e82c-4777-bc55-def3beaaef5d
Severity: Critical
CVEs: CVE-2026-57572

Classification

AML.T0053 · AI Agent Tool Invocation ASI02 · Tool Misuse and Exploitation ASI05 · Cascading Failures in Multi-Agent Systems LLM01 · Prompt Injection LLM06 · Excessive Agency

Why it matters

An attacker gets arbitrary command execution inside the container or host running the browser-automation service, with no need for authentication in the vulnerable case this was mined from. That gives full control of the runtime environment the browser process runs in.

What you can do

→Never pass caller- or LLM-supplied strings directly into Chromium/Chrome/Puppeteer/Playwright launch arguments; validate against a strict allowlist of safe flags instead of a denylist.
→Explicitly block --utility-cmd-prefix, --renderer-cmd-prefix, --gpu-launcher, --browser-subprocess-path, and treat --no-zygote as suspicious when paired with them.
→Run browser-automation containers with least-privilege runtime users and no unnecessary host access, so command execution inside the container has limited blast radius.
→Audit any browser-automation or crawler tool in your stack for a request-controlled launch-args, extra_args, or browser_config field and confirm it is sanitized server-side, not just client-side.

Known benign look-alikes

A launch-args field carrying ordinary Chromium flags with no command-replacing switch (e.g. extra_args=["--headless", "--disable-gpu"])
Chromium/Chrome-internals engineering documentation discussing these switch names without an actual tool-call argument being set to them
A --no-zygote flag used alone for container/sandboxing compatibility with no accompanying cmd-prefix/launcher/subprocess-path switch
A local developer wrapping the renderer/utility process with a well-known debugger or profiler for legitimate crash investigation (e.g. --renderer-cmd-prefix="gdb --args", --utility-cmd-prefix="valgrind", or lldb/strace/ltrace/perf) -- adversarially confirmed during review: caught by an earlier, broader version of condition 1 and fixed with a negative lookahead
Residual: a backslash-escaped quote before the debugger name (e.g. --renderer-cmd-prefix=\"gdb --args\" as a doubly-JSON-escaped literal) can still evade the lookahead, since the lookahead's optional ["']? does not account for a preceding backslash -- an accepted, narrow residual gap given this exact escaping shape is uncommon in the flat tool-call-argument text this rule targets