Crawl4AI: SSRF filter bypass in Docker server via IPv6 transition forms (NAT64 / 6to4 / unspecified / v4-mapped)
- Product
- crawl4ai
- CVE
- CVE-2026-53754
- Affected
- pip/crawl4ai <= 0.8.7
- Fixed in
- 0.8.8
Last verified against sources: October 26, 2026
Am I affected?
crawl4ai: affected pip/crawl4ai <= 0.8.7. Fixed in 0.8.8.
- Check your version: run
pip show crawl4ai. Versions <= 0.8.7 of crawl4ai are affected. [1]
What to do now
- Upgrade to the fixed version: run
pip install --upgrade "crawl4ai>=0.8.8"(first patched version 0.8.8). [1] - Upgrade to the patched version. [1]
- Enable authentication (
CRAWL4AI_API_TOKEN). [1] - Restrict the container's outbound network access (egress firewall / no metadata route). [1]
General practice, not from the source: if the affected software could read tokens or credentials, rotate them after upgrading; pin versions and review changes before updating tools your agents run.
What happened
- The Docker API server's SSRF protection (
validate_webhook_url/validate_url_destinationindeploy/docker/utils.py) used an explicit IPv4/IPv6 CIDR blocklist that missed several address families. [1] - 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. [1] - Because the Docker API is unauthenticated by default (
jwt_enabled: false), no credentials are required. [1] - The blocklist was applied to crawl URLs (
POST /crawl,/md,/html,/screenshot,/pdf,/execute_js) and webhook URLs (/crawl/job,/llm/job). [1]
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. [1]
- The error message also echoed the resolved internal IP, acting as a minor DNS/oracle leak. [1]
What was done
- The blocklist is replaced by a single rule: reject any resolved IP where
not ip.is_global, evaluated on the address AND every embedded IPv4 transition form (v4-mapped, NAT6464:ff9b::/96, 6to42002::/16, v4-compat::/96). [1] - Error messages are now opaque and no longer echo the resolved IP. [1]
- Packages: pip/crawl4ai affected <= 0.8.7 patched 0.8.8 [1]
Sources
- GHSA-4qqr-vv2q-cmr5 — GitHub Advisory Database
Every statement above was checked against these sources before publishing. Spotted an error? Tell us and we will correct it with a dated note.
Share advisory brief with your team
Copy a plain-text summary for Slack, GitHub issues, or team security channels.
[CVE-2026-53754] Crawl4AI: SSRF filter bypass in Docker server via IPv6 transition forms (NAT64 / 6to4 / unspecified / v4-mapped)
Product: crawl4ai | Affected: pip/crawl4ai <= 0.8.7 | Fixed in: 0.8.8
Summary: The Docker API server's SSRF protection (`validate_webhook_url` / `validate_url_destination` in `deploy/docker/utils.py`) used an explicit IPv4/IPv6 CIDR blocklist that missed several address families.
Source & remediation on AgentArmorHQ: https://agentarmorhq.com/incidents/2026/06/cve-2026-53754-crawl4aiCorrections
Report an error or request a correction. We review requests within 5 business days and add a dated correction note.
Discussions for CVE-2026-53754
Ask questions or share configuration tips. Governed by our Community Rules & Terms.
No posts match this filter yet.
Be the first to ask a question or share a working tip.