CVE-2026-55524: PraisonAI: SSRF in web_crawl tool via redirect-following and DNS rebinding (validate-then-fetch gap)
PraisonAI is a multi-agent teams system. In versions prior to 1.6.58, the webcrawl tool performs its SSRF check only on the initially supplied URL, allowing the protection to be bypassed so the tool connects to attacker-chosen internal destinations. The check resolves the hostname once with socket.gethostbyname and rejects private/loopback/link-local results, but then passes the URL to a fetcher using httpx.Client(followredirects=True) (or urllib.request.urlopen when httpx is absent, which also follows redirects) that re-resolves the hostname at connect time with no further validation. This validate-here/fetch-there gap is exploitable through both HTTP redirects and DNS rebinding. If an attacker can influence URLs passed to webcrawl(), directly or through an agent/tool workflow, they can cause the PraisonAI host to fetch loopback, private-network, or cloud metadata endpoints reachable from that host, with the response body returned in the webcrawl() result. This issue has been fixed in version 1.6.58.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
PraisonAI (web_crawl tool)to a version that resolves this vulnerability.Fixed in 1.6.58 - Compensating control
Because the SSRF issue is exploitable via HTTP redirects and DNS rebinding in versions prior to 1.6.58, restrict network egress from the PraisonAI host so it cannot reach loopback/private-network or cloud metadata endpoints (e.g., block RFC1918/loopback/link-local and metadata IPs from the host/container).
- Compensating control
If web_crawl inputs are user-influenced (directly or via an agent/tool workflow), enforce allow-list validation at the workflow layer so only approved external domains/URLs can be crawled (prevent fetching attacker-chosen redirect or rebound destinations).