CVE-2026-62240: 
NixOS Analyse et atténuation des vulnérabilités

CVE-2026-62240 is a Server-Side Request Forgery (SSRF) vulnerability in CrewAI's validate_url function affecting all versions before 1.15.1. The flaw allows attackers to bypass the SSRF security filter by supplying URLs that redirect to internal addresses or by using DNS rebinding techniques, enabling unauthorized access to internal services and cloud metadata endpoints. The vulnerability was reported via Bugcrowd on June 12, 2026, fixed via PR #6331 merged on June 26, 2026, and publicly disclosed on July 13, 2026. It carries a CVSS v4 base score of 8.3 (High) and a CVSS v3.1 base score of 7.4 (High) (Github Advisory, Feedly).

The root cause (CWE-918) lies in the one-shot validation design of validate_url in crewai_tools/security/safe_path.py. The function performs a single socket.getaddrinfo() DNS resolution and IP blocklist check, then returns the original URL string unchanged. The scrape tools (ScrapeWebsiteTool, ScrapeElementFromWebsiteTool) and URL-backed RAG loaders subsequently call requests.get() on the returned URL with default redirect-following enabled (allow_redirects is not set to False anywhere in the library). An attacker can supply a URL pointing to a public host that issues an HTTP 302 redirect to a blocked internal address (e.g., 127.0.0.1 or 169.254.169.254); the validation passes on the public host, but requests follows the redirect to the internal target without re-validation. The same one-shot design is also susceptible to DNS rebinding, where the first DNS resolution returns a public IP (passing the check) and a subsequent resolution returns a private IP for the actual connection (GitHub Issue, GitHub PR).

Successful exploitation allows an unauthenticated attacker (with passive user interaction, e.g., via indirect prompt injection into an LLM-controlled tool argument) to reach internal-only services and cloud instance-metadata endpoints such as 169.254.169.254/latest/meta-data/, potentially exfiltrating cloud credentials (e.g., AWS IAM keys), secrets, and other sensitive internal data. Because CrewAI tool arguments (website_url) are LLM-controlled at runtime and agents routinely process untrusted web content, the attack surface is broadened by indirect prompt injection scenarios. The scope is changed — the attacker crosses from the external network into the internal network of the host running the CrewAI agent, with high confidentiality impact on both the vulnerable and subsequent systems (Github Advisory, GitHub Issue).

1. Reconnaissance: Identify a target running CrewAI before version 1.15.1 that uses ScrapeWebsiteTool, ScrapeElementFromWebsiteTool, or URL-backed RAG loaders. Confirm the version via package metadata or behavior.
2. Set up attacker infrastructure: Deploy a public-facing HTTP server (e.g., on a non-RFC1918 IP or CGNAT address like 100.64.x.x) that responds to GET requests with an HTTP 302 redirect to the internal target (e.g., Location: http://169.254.169.254/latest/meta-data/iam/security-credentials/ or Location: http://127.0.0.1:8080/secret).
3. Craft the malicious URL: Prepare a URL pointing to the attacker-controlled public server (e.g., http://100.100.65.36:8771/). This URL will pass validate_url's blocklist check because the resolved IP is not in a private/reserved range.
4. Inject the URL into the agent: Supply the crafted URL as the website_url argument to a CrewAI scrape tool — either directly (if the attacker controls tool input) or via indirect prompt injection by embedding the URL in web content that the LLM agent retrieves and processes.
5. Trigger the SSRF: The scrape tool calls validate_url(website_url) (which passes), then calls requests.get(url) with default redirect-following. The HTTP client follows the 302 redirect to the internal address without re-validation.
6. Exfiltrate internal data: The response from the internal service (e.g., cloud metadata credentials) is returned to the agent and potentially surfaced to the attacker via the agent's output or logs (GitHub Issue).

• Network: Outbound HTTP requests from the CrewAI host to cloud metadata endpoints (169.254.169.254) or loopback/internal addresses (127.0.0.1, RFC1918 ranges) originating from the Python requests library user-agent; unexpected HTTP responses containing credential-like strings (e.g., AKIA, credentials=) in agent logs.
• Logs: CrewAI agent output or tool result logs containing cloud metadata content, IAM credential strings, or internal service responses; HTTP access logs on internal services showing requests from the CrewAI host with no corresponding legitimate user action.
• Process: Python process (crewai or related) making unexpected outbound connections to internal network addresses or metadata endpoints, observable via network monitoring tools (e.g., netstat, ss, or EDR telemetry).
• File System: Unexpected credential files or tokens written to disk if the agent is configured to persist tool outputs; audit logs showing access to internal APIs or secrets managers from the CrewAI service account (GitHub Issue).

Upgrade CrewAI to version 1.15.1 or later, which replaces the vulnerable validate_url() + requests.get() pattern with a new safe_get() helper (crewai_tools.security.safe_requests) that validates the initial URL and every redirect target before following redirects, and strips sensitive headers on cross-origin redirects (CrewAI Release, GitHub PR). As a network-level workaround, implement egress filtering on the host running CrewAI to block outbound connections to 169.254.169.254, loopback, and RFC1918 addresses. Additionally, consider restricting the URLs that can be passed to scrape tools via input validation at the application layer, and monitor agent outputs for unexpected credential-like content.

The vulnerability was originally reported through Bugcrowd on June 12, 2026, and the fix was merged on June 26, 2026, before public disclosure on July 13, 2026, demonstrating a responsible disclosure process. VulnCheck assigned the CVE and published an advisory noting the SSRF filter bypass via HTTP redirect in scrape tools (Github Advisory). The issue attracted attention in the security community given the growing use of AI agent frameworks and the risk of indirect prompt injection amplifying SSRF impact in LLM-driven workflows.