CVE-2026-53754: Crawl4AI: SSRF filter bypass in Docker server via IPv6 transition forms (NAT64 / 6to4 / unspecified / v4-mapped)
Summary
The Docker API server's SSRF protection (validatewebhookurl / validateurldestination in deploy/docker/utils.py) used an explicit IPv4/IPv6 CIDR blocklist that missed several address families. An attacker could reach internal services and cloud metadata endpoints (e.g. 169.254.169.254) despite the filter by encoding an internal IPv4 address inside an IPv6 transition form, or by using the IPv6 unspecified address.
Because the Docker API is unauthenticated by default (jwtenabled: false), no credentials are required.
Affected paths
The blocklist was applied to crawl URLs (POST /crawl, /md, /html, /screenshot, /pdf, /executejs) and webhook URLs (/crawl/job, /llm/job). All shared the same incomplete check.
Bypasses
The following all resolve to (or route to) blocked internal addresses but were NOT caught: - IPv6 unspecified :: - NAT64 64:ff9b::a9fe:a9fe (embeds 169.254.169.254) - 6to4 2002:a9fe:a9fe:: (embeds 169.254.169.254) - IPv4-mapped ::ffff:169.254.169.254 - IPv4-compatible ::a9fe:a9fe
The error message also echoed the resolved internal IP, acting as a minor DNS/oracle leak.
Impact
Server-Side Request Forgery: an unauthenticated attacker can make the server fetch internal-network URLs and cloud instance-metadata endpoints, potentially exposing internal services and cloud credentials.
Fix
The blocklist is replaced by a single rule: reject any resolved IP where not ip.isglobal, 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 and no longer echo the resolved IP.
Workarounds
- Upgrade to the patched version. - Enable authentication (CRAWL4AIAPITOKEN). - Restrict the container's outbound network access (egress firewall / no metadata route).
Credits
Internal security audit (Crawl4AI maintainers).
Other sources
Crawl4AI is an open-source LLM friendly web crawler & scraper. Prior to 0.8.8, the Docker API server's SSRF protection (validatewebhookurl / validateurldestination in deploy/docker/utils.py) used an explicit IPv4/IPv6 CIDR blocklist that missed several address families. An attacker could reach internal services and cloud metadata endpoints (e.g. 169.254.169.254) despite the filter by encoding an internal IPv4 address inside an IPv6 transition form, or by using the IPv6 unspecified address. Because the Docker API is unauthenticated by default (jwtenabled: false), no credentials are required. This vulnerability is fixed in 0.8.8.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/crawl4aito a version that resolves this vulnerability.Fixed in 0.8.8 - Upgrade
Upgrade
Crawl4AIto a version that resolves this vulnerability.Fixed in 0.8.8 - Configuration
Update Crawl4AI so validate_webhook_url / validate_url_destination use the new global-address check (not ip.is_global) across the address and embedded IPv4 transition forms; apply this protection to crawl URLs (POST /crawl, /md, /html, /screenshot, /pdf, /execute_js) and webhook URLs (/crawl/job, /llm/job).
Docker API server (Crawl4AI SSRF protection) validate_webhook_url / validate_url_destination = Replace explicit IPv4/IPv6 CIDR blocklist with single rule: reject resolved IPs 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`). - Configuration
Update Crawl4AI so error messages are opaque and no longer echo the resolved internal IP (to remove the minor oracle/DNS leak).
Docker API server (Crawl4AI error handling) error message behavior = opaque (no longer echo resolved internal IP) - Configuration
Enable authentication by setting CRAWL4AI_API_TOKEN, since the Docker API is unauthenticated by default (`jwt_enabled: false`) and no credentials are required otherwise.
Crawl4AI CRAWL4AI_API_TOKEN = enable authentication - Compensating control
Restrict the container's outbound network access using an egress firewall / ensure there is no metadata route, so the server cannot reach internal services or cloud instance-metadata endpoints (e.g., 169.254.169.254) even if SSRF is attempted.
Event History
Frequently Asked Questions
What is the severity of CVE-2026-53754?
The severity of CVE-2026-53754 is rated as high with a CVSS score of 7.5.
How do I fix CVE-2026-53754?
To fix CVE-2026-53754, ensure to update the affected software to a version that addresses the SSRF vulnerability.
What kind of attack does CVE-2026-53754 expose systems to?
CVE-2026-53754 exposes systems to Server-Side Request Forgery (SSRF) attacks, allowing unauthorized access to internal services.
Which software is affected by CVE-2026-53754?
The vulnerable software affected by CVE-2026-53754 is pip/crawl4ai.
When was CVE-2026-53754 published?
CVE-2026-53754 was published on June 16, 2026.