Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐍
🐍 PyPI
Not in CISA KEV
HIGH severity

Crawl4AI: Unauthenticated SSRF on the Docker server streaming crawl path (/crawl/stream)GHSA-wm69-2pc3-rmmf

HIGH

GHSA-wm69-2pc3-rmmf is a high-severity (CVSS 8.6) Server-Side Request Forgery (SSRF) vulnerability in crawl4ai. A fix is available for crawl4ai — see the affected versions and patch details below.

Also known asCVE-2026-57573PYSEC-2026-2140
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 26, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-wm69-2pc3-rmmf.

EPSS Exploitation Probability

via FIRST.org ↗
0.4%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs38th percentile — riskier than 38% of all scored CVEsHighest risk
0.00%0.32%0.63%0.95%0.3%0.4%0.4%0.4%Aug 26Oct 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

GHSA-wm69-2pc3-rmmf by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 397,508 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected
🐍crawl4ai

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

Description

Summary

The Docker API server applied its SSRF destination check (validate_url_destination) on the non-streaming /crawl path but not on the streaming path. handle_stream_crawl_request passed seed URLs straight to the crawler with no destination validation. A remote, unauthenticated client could call POST /crawl/stream (or POST /crawl with crawler_config.stream=true, which short-circuits to the same handler) with a URL pointing at an internal, private, or link-local address; the server fetched it and streamed the response body back. The Docker API is unauthenticated by default.

Affected paths

POST /crawl/stream, and POST /crawl with crawler_config.stream=true (both route to handle_stream_crawl_request, deploy/docker/api.py).

Impact

Unauthenticated read server-side request forgery: an attacker reads internal-only services and cloud-metadata endpoints (e.g. http://169.254.169.254/ for IAM credentials), with the response body streamed back. This is the same class and severity as the project's prior "SSRF via Direct Crawl Endpoints" advisory; /crawl/stream is part of that endpoint family and was never covered by the destination check.

Fix

handle_stream_crawl_request now validates every seed URL's destination with the same global-routability check as handle_crawl_request, before any fetch. The SSRF regression test was hardened to assert per-handler coverage (including the streaming handler) rather than a bare occurrence count, which previously let this gap pass.

Workarounds

  • Upgrade to the patched version (0.9.0).
  • Enable authentication and restrict who can reach the API (note: this does not constrain which URL the API fetches).
  • Restrict the container's outbound network access (egress firewall / no metadata route).

Credits

KOH Jun Sheng - reported the streaming-path SSRF with a runnable PoC and noted the count-based regression test that masked it, plus the shared root cause with redirect/deep-crawl link following.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPIcrawl4aiall versions0.9.0pip install --upgrade 'crawl4ai==0.9.0'

Affected Products

1 product · 1 configurations
Application
crawl4aikidocode
< 0.9.0
range

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for crawl4ai, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update crawl4ai to 0.9.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-wm69-2pc3-rmmf is resolved across your whole dependency graph.

  3. Workarounds

    Restrict outbound requests from the affected component to an allowlist of hosts, block access to link-local and internal address ranges at the network layer, and require authentication on internal services so a forged request cannot reach them unauthenticated.

Frequently Asked Questions

### Summary The Docker API server applied its SSRF destination check (`validate_url_destination`) on the non-streaming `/crawl` path but not on the streaming path. `handle_stream_crawl_request` passed seed URLs straight to the crawler with no destination validation. A remote, unauthenticated client could call `POST /crawl/stream` (or `POST /crawl` with `crawler_config.stream=true`, which short-circuits to the same handler) with a URL pointing at an internal, private, or link-local address; the server fetched it and streamed the response body back. The Docker API is unauthenticated by default.
O3 Security · Impact-Aware SCA

Is GHSA-wm69-2pc3-rmmf in your dependencies?

Find it across PyPI, including transitive dependencies.

Scan my dependencies How O3 SCA works
Crawl4AI: Unauthenticated SSRF on the Docker server…