Cloud Metadata SSRF Attacks: AWS IMDSv2, GCP & Azure Defense

All major hyper-scale cloud infrastructure providers - including Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, and DigitalOcean - implement an internal instance metadata service accessible strictly from within running virtual machines or container hosts. This service is universally hosted at the non-routable IPv4 link-local address 169.254.169.254 (defined by RFC 3927). The instance metadata service is designed to allow bootstrap initialization scripts, cloud-init daemons, and software agents to retrieve contextual operating parameters - such as the virtual machine's instance ID, availability zone, security groups, public IP address, and, most critically, temporary IAM role credentials.

Because the link-local address is physically isolated to the host instance and cannot be routed across the public internet, early cloud implementations (like AWS IMDSv1) operated under a flawed assumption of network trust: any process executing on the virtual machine was assumed to be an authorized system service. In legacy IMDSv1, querying metadata requires zero authentication: an HTTP GET request to http://169.254.169.254/latest/meta-data/iam/security-credentials/{role-name} immediately returns the active IAM role's AccessKeyId, SecretAccessKey, and Token session parameters.

When a web application hosted on that virtual machine contains a Server-Side Request Forgery (SSRF) vulnerability - such as an unvalidated profile image URL importer, a PDF generation tool that renders remote HTML stylesheets, or a webhook verification endpoint - an external adversary can supply http://169.254.169.254 into the target parameter. The backend server issues the request using its internal network privileges, retrieves the secret IAM credentials, and reflects them back to the attacker. With these credentials, the attacker can connect directly to AWS cloud APIs using the AWS CLI, downloading sensitive S3 buckets, snapshotting production RDS databases, and pivoting across the entire cloud tenant.

Audit your endpoints and test for cloud metadata exposures using the WeSecureX Security Scanner and inspect external subdomains on Attack Surface Management.

To eradicate the cloud metadata SSRF attack vector, AWS engineered the Instance Metadata Service Version 2 (IMDSv2). IMDSv2 replaces the unauthenticated GET model of IMDSv1 with a secure, session-oriented protocol that requires callers to perform a two-step cryptographic handshake.

Under IMDSv2, any client or software process attempting to access metadata must first issue an HTTP PUT request to http://169.254.169.254/latest/api/token, supplying a mandatory custom header: X-aws-ec2-metadata-token-ttl-seconds: 21600 (specifying the session token lifetime in seconds, up to a maximum of 6 hours). In response, the metadata service generates a cryptographically signed, unguessable session token. All subsequent metadata queries must include this token in an X-aws-ec2-metadata-token header.

Because the vast majority of real-world SSRF vulnerabilities (e.g., in PDF converters, image importers, and webhook dispatchers) are restricted to standard HTTP GET or POST requests and cannot forge custom HTTP PUT verbs or custom header attributes across network boundaries, IMDSv2 completely neutralizes metadata exfiltration. Furthermore, in containerized Docker or Kubernetes architectures running on EC2 hosts, setting the metadata response hop limit to 1 (http-put-response-hop-limit 1) guarantees that IP packets cannot traverse the Docker virtual network bridge, permanently barring containerized microservices from stealing the underlying EC2 host's IAM instance profile.

Enforcing IMDSv2 across all AWS launch templates, Auto Scaling groups, and standalone instances is considered an absolute security baseline in modern cloud architecture.

Audit your cloud instance metadata configurations and perimeter security with the WeSecureX Vulnerabilities Catalog and Attack Surface Reconnaissance.

A widespread engineering mistake when mitigating SSRF is attempting to validate user-supplied URLs using regular expressions or performing a single hostname check before fetching the URL. Attackers easily bypass naive application-layer string filters using DNS Rebinding and IP obfuscation techniques.

In a DNS Rebinding attack, an adversary registers a custom domain (such as evil-rebind.com) configured on an authoritative nameserver that delivers responses with a Time-to-Live (TTL) of 0 seconds. When the application server executes its validation logic, it performs a DNS lookup: the nameserver responds with a harmless public IP address (such as 93.184.216.34). Because the IP is public, the validation check passes. A few milliseconds later, when the application's HTTP client opens a TCP socket to execute the request, the socket library performs a second DNS query because the TTL expired. At this instant, the nameserver responds with 169.254.169.254 or 127.0.0.1, coercing the server into connecting directly to the restricted internal metadata endpoint.

Building an impenetrable defense against SSRF requires a two-phase socket pinning architecture:

1. Asynchronous DNS Resolution: Resolve the target hostname using the host DNS resolver to obtain all associated IPv4 and IPv6 addresses.
2. CIDR Subnet Validation: Assert that none of the resolved IPs fall within private subnets (RFC 1918 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), loopback space (127.0.0.0/8, ::1), or link-local metadata space (169.254.0.0/16, fe80::/10).
3. Socket IP Pinning: Pass the pre-validated IP address directly into the HTTP client socket options so the outgoing TCP connection connects exclusively to the verified IP without performing a second DNS query.
4. Disable Redirect Following: Configure HTTP fetch libraries with redirect: 'manual' to prevent attackers from using 301 redirects to jump to metadata endpoints.

Check your open ports and perimeter routing with the WeSecureX Open Port Scanner and verify DNS records using our DNS Record Lookup.