What is the CVSS score of CVE-2026-53754?

CVE-2026-53754 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. EPSS exploitation probability: 0.3%.

Which versions of Crawl4AI are affected by CVE-2026-53754?

Crawl4AI Docker API server (version 0.8.7 and earlier) has a critical flaw that allows unauthorized attackers to extract cloud authentication credentials without any validation, potentially…. A patch is available.

How to fix or mitigate CVE-2026-53754?

Within 24 hours: Identify all systems running Crawl4AI versions <= 0.8.7; confirm network connectivity from these systems to cloud metadata endpoints (169.254.169.254 for AWS, etc.). Within 7 days: Enable jwt_enabled:true for all Docker API instances to require authentication; implement firewall egress rules blocking outbound access to 169.254.169.254/32 and cloud provider metadata endpoints. Within 30 days: Monitor vendor advisory (GHSA-4qqr-vv2q-cmr5) for patch release and schedule upgrade; if no patch released, evaluate risk-based alternatives including tool replacement or enhanced compensating controls.

Crawl4AI CVE-2026-53754

EUVD-2026-38568 HIGH

Server-Side Request Forgery (SSRF) (CWE-918)

2026-06-16 https://github.com/unclecode/crawl4ai

GHSA-4qqr-vv2q-cmr5

Docker SSRF Oracle

7.5

CVSS 3.1 · Vendor: https://github.com/unclecode/crawl4ai

Severity by source

Vendor (https://github.com/unclecode/crawl4ai) PRIMARY

7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

vuln.today AI

7.5 HIGH

Network-reachable unauthenticated Docker API (PR:N, AV:N, AC:L); SSRF to IMDS yields high confidentiality via credential theft, but no direct write or DoS, so I:N and A:N.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (https://github.com/unclecode/crawl4ai).

CVSS VectorVendor: https://github.com/unclecode/crawl4ai

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

None

Availability

None

Lifecycle Timeline

Source Code Evidence Fetched

Jun 16, 2026 - 21:43 vuln.today

Analysis Generated

Jun 16, 2026 - 21:43 vuln.today

CVE Published

Jun 16, 2026 - 21:00 github-advisory

HIGH 7.5

DescriptionCVE.org

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. 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 (jwt_enabled: false), no credentials are required.

Affected paths

The blocklist was applied to crawl URLs (POST /crawl, /md, /html, /screenshot, /pdf, /execute_js) 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.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 and no longer echo the resolved IP.

Workarounds

Upgrade to the patched version.
Enable authentication (CRAWL4AI_API_TOKEN).
Restrict the container's outbound network access (egress firewall / no metadata route).

Credits

Internal security audit (Crawl4AI maintainers).

Articles & Coverage 1

News 5 New Docker Vulnerabilities - 1 Critical, 4 High Severity Jun 17, 2026

AnalysisAI

Server-Side Request Forgery in Crawl4AI's Docker API server (versions <= 0.8.7) allows unauthenticated remote attackers to bypass the IPv4/IPv6 CIDR blocklist in validate_webhook_url/validate_url_destination by using IPv6 transition forms (NAT64, 6to4, IPv4-mapped, IPv4-compatible) or the unspecified address. Since the Docker API ships with jwt_enabled:false by default, attackers can pivot the server into fetching cloud metadata endpoints like 169.254.169.254, potentially exposing IAM credentials. No public exploit identified at time of analysis, but the upstream advisory (GHSA-4qqr-vv2q-cmr5) details the exact bypass payloads.

Technical ContextAI

Crawl4AI is an open-source Python web-crawling framework (pkg:pip/crawl4ai) commonly deployed via its Docker API service for LLM/agent pipelines. The vulnerable logic in deploy/docker/utils.py applied an explicit deny-list of internal CIDR ranges, but the SSRF defense (CWE-918) failed to account for IPv6 address family semantics where an IPv4 address can be embedded inside an IPv6 representation (::ffff:169.254.169.254, 64:ff9b::a9fe:a9fe, 2002:a9fe:a9fe::, ::a9fe:a9fe) and still route to the original IPv4 destination. The unspecified IPv6 address :: also bypassed checks. The endpoints affected are the crawl actions (/crawl, /md, /html, /screenshot, /pdf, /execute_js) and webhook URL inputs on /crawl/job and /llm/job. The fix replaces the blocklist with Python's stdlib ipaddress is_global check, evaluated against the resolved address and every embedded transition form.

RemediationAI

Vendor-released patch: upgrade pip/crawl4ai to 0.8.8 or later, which replaces the explicit CIDR blocklist with an ipaddress.is_global check evaluated across all IPv6 transition encodings (v4-mapped, NAT64 64:ff9b::/96, 6to4 2002::/16, v4-compat ::/96) and also makes error messages opaque to remove the DNS/oracle leak; see https://github.com/unclecode/crawl4ai/security/advisories/GHSA-4qqr-vv2q-cmr5. If immediate upgrade is not feasible, enable authentication by setting CRAWL4AI_API_TOKEN and switching jwt_enabled to true (this blocks unauthenticated callers but breaks any clients that do not pass the token). As a network-level compensating control, restrict the container's outbound traffic with an egress firewall that drops 169.254.169.254 and RFC1918/internal ranges, or run the container in a network namespace without a route to the cloud IMDS - be aware this can break legitimate webhook destinations that legitimately live on internal networks.