AWS IMDSv2.

IMDSv2 is the second version of the EC2 Instance Metadata Service, introduced by AWS in November 2019 in direct response to the Capital One breach and other SSRF-driven cloud credential theft. In that breach, disclosed on 19 July 2019, Paige Thompson ("erratic") abused a Server-Side Request Forgery flaw in a misconfigured web application firewall to reach the link-local endpoint http://169.254.169.254/latest/meta-data/iam/security-credentials/. The WAF's over-privileged IAM role, ISRM-WAF-Role, returned temporary STS credentials that let her list and copy data from more than 700 S3 buckets — roughly 106 million customer records. The incident later cost Capital One an $80M OCC penalty and a $190M class-action settlement.

How IMDSv2 defeats SSRF

With IMDSv1, any GET to the metadata IP returned credentials, so a reflected or server-side request forgery sufficed. IMDSv2 makes the flow session-oriented: the client must first PUT /latest/api/token with an X-aws-ec2-metadata-token-ttl-seconds header, then send the returned token on every read via X-aws-ec2-metadata-token. A naive SSRF cannot easily issue a PUT with a custom header, and setting HttpPutResponseHopLimit: 1 stops containers one network hop away from reaching the service.

flowchart TD
  A[App with SSRF flaw] -->|GET 169.254.169.254| B{Metadata mode?}
  B -->|IMDSv1 optional| C[Returns IAM credentials]
  C --> D[Attacker exfiltrates S3 data]
  B -->|IMDSv2 required| E[Rejected: no session token]
  E --> F[PUT /latest/api/token + TTL header needed]
  F -->|SSRF cannot issue PUT| G[Credential theft blocked]

Defences

Enforce HttpTokens: required org-wide via an SCP or the account-level instance-metadata-defaults setting, pin the hop limit to 1, and use CSPM/Wiz findings to hunt legacy AMIs still permitting IMDSv1. Scope instance-role IAM policies to least privilege so a leaked token yields little.