GPU VulnDB

Database/AI/ML frameworks & serving

Crawl4AI: unvalidated webhook URLs let callers make the server request internal addresses

CVSS 9.2CVE-2026-56261AI/ML frameworks & servingcurated

Impact

Crawl4AI's Docker API server accepts a caller-supplied webhook URL on /crawl/job and /llm/job and does not validate the destination. Anyone who can submit a job makes the container issue HTTP requests to anything it can reach: other services on the Docker network, internal cluster endpoints, and the cloud instance metadata endpoint at 169.254.169.254. On a GPU fleet this matters because crawl/LLM workers are usually scheduled onto the same nodes as inference work and run with an instance role or node identity attached, so metadata exposure hands over credentials for the node rather than just for the crawler. The advisory describes disclosure only, not request-body control, so the practical loss is internal reconnaissance plus whatever the metadata service returns.

Who can reach it

Anyone who can reach the Crawl4AI Docker API server and submit a job. The record describes the endpoints as part of the API server with no authentication requirement stated; treat any pod or user with network access to the service port as sufficient.

What to do

Upgrade Crawl4AI to 0.8.7 or later and restart the container - no node drain or host change needed. Until then, keep the API server off shared pod networks, and where the platform supports it require a token for the metadata endpoint (IMDSv2 or equivalent) so a blind SSRF cannot read credentials.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-56261https://github.com/unclecode/crawl4ai/security/advisories/GHSA-365w-hqf6-vxfghttps://www.vulncheck.com/advisories/crawl4ai-server-side-request-forgery-via-webhook-urls

Related entries

All AI/ML frameworks & serving entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.