SSRF in Exchange leads to root access in all instances

A single unsanitized URL field in Shopify's Exchange Marketplace turned into a path to root access across every instance - a textbook demonstration of why server-side fetches need strict controls.

The Target

Shopify Exchange Marketplace was a platform that allowed merchants to buy and sell their Shopify stores. As part of listing a store, the feature let sellers import a screenshot by supplying a URL - the application's server would fetch the remote resource and display it. That "fetch from URL" functionality was the attack surface.

The Vulnerability

The bug was a Server-Side Request Forgery (SSRF). When the Shopify server fetched the URL provided by a user, it performed no validation to block requests targeting internal network ranges or cloud metadata endpoints. The application trusted the user-supplied URL unconditionally, made the HTTP request from within Shopify's own infrastructure, and returned or acted on the response.

The cloud metadata endpoint at 169.254.169.254 is a well-known address available inside virtually every major cloud provider (AWS, GCP, Azure). It is only reachable from within the cloud instance itself - exactly where Shopify's application server was running. A successful fetch to that address exposes instance identity documents, IAM role credentials, and internal API tokens.

How It Was Found

The researcher identified the store screenshot import feature as a user-controlled server-side fetch. By substituting the legitimate screenshot URL with the cloud metadata endpoint, they confirmed the server made outbound requests to attacker-controlled targets (SSRF confirmed via a Burp Collaborator-style callback), and then pivoted to internal addresses.

An illustrative request targeting the metadata endpoint:

POST /exchange/import_screenshot HTTP/1.1
Host: exchange.shopify.com
Content-Type: application/json
 
{
  "store_url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"
}

With the metadata service responding, the next step was reading IAM credentials and using them to move laterally across Shopify's internal cloud infrastructure - ultimately reaching root access on internal instances.

Impact

• Direct read access to the AWS/cloud instance metadata for Shopify's production infrastructure.
• Retrieval of temporary IAM credentials tied to the instance role - usable to authenticate as that role via the AWS API.
• The researcher reported obtaining root-level access across all Exchange instances, meaning complete compromise of that tier of Shopify's infrastructure.
• Any data stored or accessible by those instances - merchant store data, transactions, credentials - was within reach.

This is rated critical and illustrates why SSRF in a cloud environment is dramatically more dangerous than in on-premises deployments.

The Fix

Proper SSRF remediation involves multiple layers:

1. Allowlist outbound destinations - the fetch should only be permitted to known-good image hosting domains, not arbitrary URLs.
2. Block internal IP ranges at the network level - cloud security groups and host-based firewall rules should prevent application servers from reaching 169.254.169.254, 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16.
3. Use IMDSv2 (AWS) - the newer metadata service version requires a session-oriented token, preventing simple GET-based SSRF from reaching it.
4. Perform fetches in an isolated environment with no privileged network access rather than from the primary application host.

What You Can Learn

• SSRF is about trust boundaries. The server's network position is privileged - attackers use SSRF to reach things the attacker's own machine cannot.
• 169.254.169.254 is a universal red flag in cloud SSRF. Every cloud security assessment should test whether user-supplied URLs can reach the metadata endpoint.
• Cloud = amplified impact. On-premises SSRF might reach internal services. Cloud SSRF can hand the attacker IAM credentials and, from there, lateral movement across the entire account.
• Allowlists beat denylists for URL validation. Denylists of "bad" IP ranges are bypassable with DNS rebinding or alternate representations (0xa9fea9fe, http://[::ffff:169.254.169.254]/). An allowlist of permitted domains is far more robust.
• Out-of-band confirmation is essential. If the server does not reflect the fetched content back to you, use a callback service to prove the request was made before targeting internal addresses.