Crawl4AI CVE-2026-119118

Exploitation requires the attacker to control the network path (man-in-the-middle) or DNS resolution for a host the crawler is directed to fetch, and to induce or wait for the server to crawl that attacker-influenced HTTPS host. All Docker deployments are affected in their default setup even though the API server reports TLS verification as enabled (when CRAWL4AI_ALLOW_INSECURE_TLS is not set), because the hard-coded --ignore-certificate-errors launch flag overrides the ignore_https_errors=False context option; library users who explicitly set ignore_https_errors=False are likewise unprotected. The /crawl and /crawl/stream endpoints build the browser from the request body, so config.yml-based flag stripping never reaches them. A separate consequence: operators who set CRAWL4AI_CHROMIUM_SANDBOX=true still run Chromium with --no-sandbox (renderer sandbox disabled), though no code execution or container escape is demonstrated. Limiting factors: the required MITM/DNS position (CVSS AC:H/AT:P), affected versions <= 0.9.4 (fixed in 0.9.5), and the fact that the Docker /crawl endpoint itself requires a valid API bearer token. The only stated workaround is incomplete - keep the crawler on a trusted network path and DNS resolver; updating to 0.9.5 is the complete fix.

This is a genuine but conditional risk rather than a mass-exploitable critical flaw. The CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:N) scores 8.3 High, but the AC:H and AT:P metrics reflect the key gating condition: the attacker must hold a privileged position - on the network path (man-in-the-middle) or in control of DNS for a host the crawler is directed to visit. Without that position the flaw cannot be triggered, so this is not a remote spray-and-pray vulnerability despite PR:N. Impact is skewed toward integrity (VC:L/VI:H): the attacker mainly injects forged content that then feeds downstream LLM/RAG pipelines, with lesser confidentiality exposure of cookies and headers the crawl sends. Signals are consistent but modest: not listed in CISA KEV, no EPSS score provided in the input, and the vuln.today decision label is 'this_week' (not act_now/emergency). A proof-of-concept walkthrough exists in the GHSA advisory. The notable dissonance is operator expectation versus reality - the Docker API server reports TLS verification as ON while every launched Chromium silently runs with --ignore-certificate-errors - which raises practical risk because defenders may wrongly believe they are protected. Net: a real priority to patch this week for anyone crawling over untrusted network paths, but not an emergency given the required attacker positioning and absence of KEV/active-exploitation signals.

An attacker who sits on the network path or controls DNS for a host the Crawl4AI server is asked to crawl presents a forged or self-signed TLS certificate; because Chromium is always launched with --ignore-certificate-errors, the crawler accepts it, returns attacker-controlled content that flows into LLM/RAG pipelines, and exposes the cookies and headers the crawl sends. A proof-of-concept exists in the GHSA advisory, crawling a self-signed HTTPS origin that a normal client rejects. The CVSS AC:H/AT:P reflects that the attacker must first achieve this man-in-the-middle or DNS-control position, which bounds realistic exploitation.