Summary
A server-side request forgery vulnerability in crewai-tools' SeleniumScrapingTool allows attacker-controlled destinations to be requested by a headless browser. If prompt injection or another influence over agent tool input is possible, an attacker may access loopback services, private network resources, or cloud metadata endpoints and disclose sensitive data.
A server-side request forgery vulnerability in crewai-tools' SeleniumScrapingTool allows attacker-controlled destinations to be requested by a headless browser. If prompt injection or another influence over agent tool input is possible, an attacker may access loopback services, private network resources, or cloud metadata endpoints and disclose sensitive data.
Affected context
The issue affects deployments using SeleniumScrapingTool where agent-controlled or otherwise untrusted input can determine the URL visited by the headless browser. The vulnerable behavior occurs when private-address validation is not applied before navigation, allowing requests to loopback addresses, RFC1918 networks, or cloud metadata services.
The issue affects deployments using SeleniumScrapingTool where agent-controlled or otherwise untrusted input can determine the URL visited by the headless browser. The vulnerable behavior occurs when private-address validation is not applied before navigation, allowing requests to loopback addresses, RFC1918 networks, or cloud metadata services.
Exploit preconditions
- Attack surface: Agent-accessible web scraping functionality using SeleniumScrapingTool
- Required access: The ability to influence tool input, potentially through prompt injection or manipulated agent content
- Trigger point: Headless Chrome navigation to an attacker-selected URL
- Why exploitation is possible: Private-address and loopback destinations are not consistently rejected before the request is issued
- Attack surface: Agent-accessible web scraping functionality using SeleniumScrapingTool
- Required access: The ability to influence tool input, potentially through prompt injection or manipulated agent content
- Trigger point: Headless Chrome navigation to an attacker-selected URL
- Why exploitation is possible: Private-address and loopback destinations are not consistently rejected before the request is issued
Why this happens
The vulnerability results from failing to enforce destination validation on a server-side HTTP-capable component.
When a scraping tool accepts attacker-influenced URLs without applying private-address checks, the server-side browser can be used as a proxy to reach resources unavailable to the attacker directly.
This maps to CWE-918: Server-Side Request Forgery, where untrusted input controls outbound requests to internal or otherwise restricted destinations.
The vulnerability results from failing to enforce destination validation on a server-side HTTP-capable component.
When a scraping tool accepts attacker-influenced URLs without applying private-address checks, the server-side browser can be used as a proxy to reach resources unavailable to the attacker directly.
This maps to CWE-918: Server-Side Request Forgery, where untrusted input controls outbound requests to internal or otherwise restricted destinations.
Potential impact
- Internal services and administrative endpoints may be accessed
- Loopback or RFC1918-hosted data could be disclosed
- Cloud instance metadata and temporary credentials may be exposed
- An attacker could conduct reconnaissance against internal networks
- Compromised credentials could enable further unauthorized access
- Internal services and administrative endpoints may be accessed
- Loopback or RFC1918-hosted data could be disclosed
- Cloud instance metadata and temporary credentials may be exposed
- An attacker could conduct reconnaissance against internal networks
- Compromised credentials could enable further unauthorized access
General mitigation guidance
Mitigation typically focuses on making outbound destination validation mandatory and reducing trust in agent-generated URLs.
Common defensive patterns include:
- Allowing requests only to explicitly approved schemes, hosts, and destinations
- Rejecting loopback, link-local, RFC1918, reserved, and cloud metadata address ranges
- Resolving hostnames and validating the resulting addresses before connection and after redirects
- Disabling or restricting redirects and browser capabilities that are unnecessary for scraping
- Separating scraping workloads from sensitive network segments and metadata services
- Running the browser with least privilege and without access to unnecessary credentials
Mitigation typically focuses on making outbound destination validation mandatory and reducing trust in agent-generated URLs.
Common defensive patterns include:
- Allowing requests only to explicitly approved schemes, hosts, and destinations
- Rejecting loopback, link-local, RFC1918, reserved, and cloud metadata address ranges
- Resolving hostnames and validating the resulting addresses before connection and after redirects
- Disabling or restricting redirects and browser capabilities that are unnecessary for scraping
- Separating scraping workloads from sensitive network segments and metadata services
- Running the browser with least privilege and without access to unnecessary credentials
How teams detect issues like this
Organizations commonly detect SSRF risks through:
- Static analysis and code review for browser or HTTP navigation using untrusted URLs
- Checks confirming that URL validation is applied before connection and redirect handling
- Tests covering loopback, private, link-local, metadata, alternative numeric, and DNS-resolving destinations
- Egress network policies that deny access to internal ranges and cloud metadata endpoints
- Monitoring proxy, DNS, and browser logs for unexpected requests to private or metadata addresses
- Automated security review tools that flag missing SSRF protections in request and scraping flows
Organizations commonly detect SSRF risks through:
- Static analysis and code review for browser or HTTP navigation using untrusted URLs
- Checks confirming that URL validation is applied before connection and redirect handling
- Tests covering loopback, private, link-local, metadata, alternative numeric, and DNS-resolving destinations
- Egress network policies that deny access to internal ranges and cloud metadata endpoints
- Monitoring proxy, DNS, and browser logs for unexpected requests to private or metadata addresses
- Automated security review tools that flag missing SSRF protections in request and scraping flows
