AWS Launches IMDSv2 (Nov 2019): Closing the Capital One Attack Path

Retrospective: this article looks back at events from November 2019, written in 2026 with the benefit of hindsight.

In November 2019, four months after the Capital One breach, AWS released version 2 of the EC2 Instance Metadata Service (IMDSv2). It was designed specifically to stop the server-side request forgery attack path used in that breach.

How IMDSv2 works

The metadata service, reachable from inside an instance at 169.254.169.254, provides information including temporary credentials for the instance's IAM role. With IMDSv1, a simple GET request returned those credentials — so any vulnerability that let an attacker make the server send a request could retrieve them.

IMDSv2 requires a session token:

1. The caller sends a PUT request to obtain a token, with a TTL header.
2. Subsequent metadata requests must include that token.

Most SSRF vulnerabilities only allow GET requests or don't allow custom headers, so they can't complete the token step. AWS also added protections: PUT requests with an X-Forwarded-For header are rejected (blocking many proxy and WAF scenarios), and the token response has a default hop limit of 1, so it can't easily leave the instance through a forwarding device.

Why adoption took years

IMDSv2 was optional at launch to avoid breaking applications. Older SDKs and agents had to be updated. AWS gradually added account-level defaults, AMI settings, Security Hub controls and CloudWatch metrics to help customers migrate, and newer instance types and AMIs moved toward IMDSv2-only by default.

In hindsight

IMDSv2 is a good example of a provider building a targeted fix into the platform after a major incident. It is also a reminder that optional security features need active adoption: years later, IMDSv1-enabled instances are still a frequent assessment finding.