Crawl4AI CVE-2026-26217

Requires only network reachability to a Crawl4AI instance deployed via its Docker API with the /execute_js, /screenshot, /pdf, or /html endpoints exposed; no authentication, user interaction, or special client privilege is needed (CVSS PR:N/UI:N/AC:L). The concrete prerequisite is that the Docker API deployment mode is enabled and the endpoints are network-accessible to the attacker - a library-only or non-Docker usage without these HTTP endpoints exposed is not affected. Exploitation is limited to reading files the container process can access (confidentiality only; no write or code execution), and is constrained by whatever network segmentation or authentication proxy sits in front of the API; an internet-exposed, unauthenticated Docker API is the worst case.

Signals are largely consistent for a serious but scope-limited (confidentiality-only) flaw. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N, VC:H, SC:H, VI/VA:N) and score 9.2 correctly reflect trivial unauthenticated network exploitation with high confidentiality impact and no integrity/availability impact - this is information disclosure, not code execution. EPSS is low (0.06%, 19th percentile) and the CVE is NOT in CISA KEV, so there is no evidence of widespread or automated exploitation; the low EPSS is plausibly driven by the product's niche footprint rather than by difficulty, since the technique itself is trivial and a copy-paste request is published in the advisory. Net: for any environment actually running the Crawl4AI Docker API exposed to untrusted networks this is a high, real priority (instant credential/secret theft), but the population of exposed instances is small, so it is not a mass-exploitation candidate. No SSVC decision record was provided in the input.

An attacker who can reach the exposed Crawl4AI Docker API sends POST /execute_js with {"url":"file:///etc/passwd"} (or file:///proc/self/environ), and the server returns the file contents in the rendered response. Repeating this against application config files and /proc/self/environ yields database credentials and API keys, which are then reused to pivot into backend systems. A working request is published in the GHSA advisory, so no exploit development is needed.