Vulnerability Database

351,760

Total vulnerabilities in the database

Crawl4AI: Unauthenticated RCE via Chromium launch-argument injection in browser_config.extra_args — Crawl4AI

Improper Neutralization of Argument Delimiters in a Command ('Argument Injection')

Summary

The Docker API server accepted a request-supplied browser_config.extra_args, which flowed into Chromium's launch arguments. An attacker could inject Chromium switches that replace a child-process launch command (--utility-cmd-prefix, --renderer-cmd-prefix, --gpu-launcher, --browser-subprocess-path) together with --no-zygote, causing Chromium to fork/exec an attacker-controlled command as the container's runtime user. The Docker API is unauthenticated by default, so a single request yields arbitrary command execution.

The earlier extra_args SSRF patch (0.8.9) used a denylist scoped to proxy/DNS flags; a denylist of launch switches is inherently incomplete, and these command-execution switches were not covered.

Affected paths

/crawl, /crawl/stream, /crawl/job accepting a request browser_config.extra_args.

Impact

Unauthenticated remote code execution as the container runtime user; full read/write of application data, mounted secrets, environment, and tokens, and out-of-band exfiltration independent of the HTTP response.

Fix

0.9.0 establishes a trust boundary for request-supplied configuration: extra_args (along with other power fields such as proxy, user_data_dir, cdp_url, init_scripts) is a forbidden field for untrusted request bodies. Any request that sets extra_args is rejected with HTTP 400 rather than scrubbed against an always-incomplete denylist. In-process SDK callers (trusted) are unaffected.

Workarounds

  • Upgrade to the patched version (0.9.0).
  • Enable authentication (CRAWL4AI_API_TOKEN) and restrict who can reach the API.
  • Run the container with a restrictive seccomp profile and no ability to exec helper binaries.

Credits

Y4tacker - reported the --no-zygote + --utility-cmd-prefix command-injection chain with a confirmed in-container PoC and an allowlist/reject recommendation. UDU_RisePho (hoanggxyuuki) - independently reported the request-supplied Chromium launch-flag RCE class (--renderer-cmd-prefix), confirmed still reproducing on 0.8.9.

  • Published: Jun 18, 2026
  • Updated: Jun 19, 2026
  • GHSA: GHSA-r253-r9jw-qg44
  • Severity: Critical
  • Exploit:
  • CISA KEV:

CVSS v3:

  • Severity: Critical
  • Score: 10
  • AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Frequently Asked Questions

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.