What happened
Crawl4AI's SSRF destination validation, present on the standard /crawl endpoint, was not applied to the streaming crawl code path, letting attacker-controlled seed URLs bypass the check entirely.
Why it matters
SSRF against an AI crawling service can be used to reach cloud metadata endpoints and internal management interfaces, leaking cloud credentials that can then be used to pivot into broader AI infrastructure — an inconsistently-applied security control (present on one code path, absent on another) is a common real-world root cause.
Attack vector
The Docker API server applies its SSRF destination check on the non-streaming /crawl path but not on the streaming path; handle_stream_crawl_request passes seed URLs straight to the crawler with no destination validation, letting an attacker direct requests at internal services or cloud metadata endpoints.
Affected systems
Crawl4AI (unclecode/crawl4ai) Docker API server, versions prior to 0.9.0
Mitigation
Upgrade to Crawl4AI >= 0.9.0; apply network-layer egress restrictions on crawler workers regardless of application-layer fixes.