Summary
A server-side request forgery vulnerability in PraisonAI's web_crawl tool allows attacker-influenced URLs to reach internal destinations after passing an initial hostname check. When redirects or DNS rebinding are possible, the tool may fetch loopback services, private-network hosts, or cloud metadata endpoints and return their response bodies.
Affected context
The issue occurs in PraisonAI versions before 1.6.58 when web_crawl() receives URLs that an attacker can influence directly or through an agent and tool workflow. The initial validation resolves the hostname only once, while the subsequent HTTP client may follow redirects or resolve the hostname again at connection time without repeating the same network-boundary checks.
Exploit preconditions
- Attack surface: The web_crawl() tool and workflows that pass user- or
agent-influenced URLs to it
- Required access: The ability to influence a URL supplied to the tool, either
directly or indirectly through an agent workflow
- Trigger point: URL fetching after the initial SSRF validation - Why exploitation is possible: Validation and connection use separate
resolution steps, and redirected or rebinding destinations are not
revalidated before the request is sent
Why this happens
The underlying bug is a validate-here/fetch-there design flaw. The application checks one hostname resolution result, but delegates the later request to a fetcher that follows redirects and may resolve the hostname again. This creates a time-of-check/time-of-use condition, mapped to CWE-367, and enables server-side request forgery under CWE-918 because attacker-controlled URLs can cause requests to originate from the PraisonAI host.
Potential impact
- The application may access loopback-only services
- Internal administrative interfaces may be exposed to the requester
- Cloud instance metadata or other sensitive endpoint responses could be returned
- Internal network topology or service information may be disclosed
- Requests could reach systems that trust the PraisonAI host
General mitigation guidance
Mitigation generally focuses on enforcing destination policy at the point of connection rather than relying on a one-time hostname check. Common defensive patterns include disabling automatic redirects or validating every redirect destination, resolving and validating addresses immediately before connecting, rejecting private, loopback, link-local, multicast, and reserved ranges for the deployment environment, and using an outbound proxy or egress firewall with an explicit allowlist. URL schemes, ports, and response handling can also be restricted, while the application should run with minimal network privileges and avoid returning unnecessary fetched content. These controls reduce trust in attacker-supplied URLs and limit impact if validation fails.
How teams detect issues like this
Detection approaches include static analysis for hostname validation that is separated from the eventual network connection, HTTP clients configured to follow redirects without destination checks, and DNS resolution performed outside the connection policy. Code review should examine all URL-fetching paths, fallback HTTP libraries, redirect handling, and agent-to-tool data flows. Runtime monitoring can alert on requests to private, loopback, link-local, reserved, or metadata address ranges, while egress policies can record and block unexpected destinations. Automated security review tools may help flag common SSRF and time-of-check/time-of-use patterns.
