CVE-2026-112308 in crewai-tools
Summary
by MITRE • 10/19/2026
crewai-tools through 1.15.28 contains a server-side request forgery vulnerability in SeleniumScrapingTool that allows attackers to fetch internal resources because it never applies the validate_url private-address check. Attackers influencing agent tool input through prompt injection can direct headless Chrome to loopback, RFC1918, or cloud metadata addresses to disclose internal data and cloud credentials.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability identified in crewai-tools versions up to 1.15.28 represents a critical server-side request forgery flaw within the SeleniumScrapingTool component. This security defect stems from an incomplete implementation of input validation, specifically the absence of checks for private or reserved IP address ranges when processing URLs provided by users. In secure application design, any tool that performs network requests must rigorously validate destination addresses to prevent access to internal infrastructure resources. The failure to implement this check allows malicious actors to bypass standard security boundaries and interact with services that are typically inaccessible from external networks.
The technical mechanism of exploitation relies on the ability of an attacker to influence the input data processed by the agent tool, often through prompt injection techniques. By crafting specific inputs, an adversary can direct the underlying headless Chrome browser instance to initiate HTTP requests toward loopback addresses such as 127.0.0.1, RFC1918 private network ranges like 10.0.0.0/8 or 192.168.0.0/16, and cloud metadata endpoints such as those found at 169.254.169.254. Because the SeleniumScrapingTool does not filter these destination addresses, it acts as a proxy for unauthorized network access, effectively turning the application into an open relay for internal reconnaissance and data exfiltration.
The operational impact of this vulnerability is severe, particularly in cloud-native or containerized environments where sensitive credentials are often stored in metadata services. Attackers can leverage this flaw to retrieve instance identity documents, API keys, and other secrets from cloud provider metadata endpoints without authentication. Additionally, the ability to access internal resources allows for further lateral movement within a network topology, potentially exposing internal APIs, databases, or management consoles that were intended to remain isolated from public-facing applications. This leads directly to unauthorized data disclosure and potential compromise of broader system integrity.
This vulnerability aligns with CWE-918 Server-Side Request Forgery (SSRF), which describes flaws where a web application fetches a remote resource without validating the user-supplied URL. Furthermore, it maps to MITRE ATT&CK technique T1557 Adversary-in-the-Middle, as the attacker uses the compromised service to intercept or redirect traffic for unauthorized access. It also relates to CWE-20 Improper Input Validation, highlighting the root cause of the failure to sanitize network destinations.
To mitigate this risk, developers must implement strict URL validation logic that explicitly blocks requests to private IP ranges, loopback addresses, and cloud metadata endpoints before any network request is initiated. This can be achieved by parsing the target URL, resolving its hostname or IP address, and verifying it against a deny list of reserved prefixes defined in RFC1918 and other relevant standards. Additionally, employing egress filtering at the network level to restrict outbound connections from application servers to only known external domains provides an essential defense-in-depth layer. Updating crewai-tools to a patched version that includes these validation checks is critical for restoring security posture.