Crawl4AI: SSRF via proxy settings in the Docker server bypasses the crawl-URL SSRF check

Vulnerability

The Crawl4AI Docker API server (versions prior to 0.8.9) applies its SSRF destination check only to the crawl target URL, not to proxy addresses. The endpoints /crawl, /crawl/stream, and /crawl/job accept browser_config and crawler_config parameters that control Chromium's egress. The following fields were unchecked: browser_config.proxy_config.server, browser_config.proxy (deprecated), crawler_config.proxy_config.server, and the --proxy-server, --proxy-pac-url, --proxy-bypass-list, and --host-resolver-rules flags in browser_config.extra_args [1][2].

Exploitation

An unauthenticated attacker sends a request to /crawl with a benign, validation-passing crawl URL but sets a proxy_config.server pointing at an internal IP (e.g., 169.254.169.254 for AWS IMDSv1). Chromium routes all requests through that proxy. For plain-HTTP targets, the proxy receives the full request and can return arbitrary content, which is then returned verbatim in the crawl result (results[0].html, cleaned_html, or markdown) [1][2].

Impact

Successful exploitation results in unauthenticated server-side request forgery (SSRF) to internal services and cloud-metadata endpoints. The attacker can retrieve IAM credential tokens or other sensitive data from internal services, with the response returned directly to the attacker [1][2].

Mitigation

The fix is included in version 0.8.9, released on the same date as the advisory. Every proxy destination is now validated with the same global-routability check used for crawl URLs (reject any resolved address that is not is_global, including IPv6 transition forms) before the browser is constructed; proxy/DNS-redirecting flags are stripped from extra_args. The fix honors the CRAWL4AI_ALLOW_INTERNAL_URLS environment variable. Workarounds include enabling authentication via CRAWL4AI_API_TOKEN or restricting the container's outbound network access with an egress firewall [1][2].