Crawl4AI: SSRF filter bypass in Docker server via IPv6 transition forms (NAT64 / 6to4 / unspecified / v4-mapped)

Vulnerability

The SSRF protection in validate_webhook_url/validate_url_destination in deploy/docker/utils.py used an explicit CIDR blocklist that missed several address families. An attacker can bypass the filter by encoding internal IPv4 addresses inside IPv6 transition forms (e.g., NAT64 64:ff9b::a9fe:a9fe, 6to4 2002:a9fe:a9fe::, IPv4-mapped ::ffff:169.254.169.254, IPv4-compatible ::a9fe:a9fe, or the IPv6 unspecified address ::). The blocklist is applied to crawl endpoints (POST /crawl, /md, /html, /screenshot, /pdf, /execute_js) and webhook URLs (/crawl/job, /llm/job). All affected versions prior to the fix are vulnerable [1][2].

Exploitation

The Docker API is unauthenticated by default (jwt_enabled: false), so no credentials are required. An attacker sends a crafted request to any of the affected endpoints with a URL containing an IPv6 transition form that resolves to an internal address (e.g., 169.254.169.254). The server's blocklist does not catch these forms, allowing the request to proceed. The error message also echoed the resolved internal IP, providing an oracle for DNS/internal network enumeration [1][2].

Impact

Successful exploitation enables Server-Side Request Forgery (SSRF). An unauthenticated attacker can make the server fetch internal-network URLs and cloud instance-metadata endpoints (e.g., http://169.254.169.254/), potentially exposing internal services and cloud credentials [1][2].

Mitigation

The fix replaces the blocklist with a single rule: reject any resolved IP where not ip.is_global, evaluated on the address and every embedded IPv4 transition form (v4-mapped, NAT64 64:ff9b::/96, 6to4 2002::/16, v4-compat ::/96). Error messages are now opaque. Users should upgrade to the patched version. Workarounds include enabling authentication (CRAWL4AI_API_TOKEN) and restricting container outbound network access via egress firewall or no metadata route [1][2].