The EC2 instance metadata service is one of those features that everyone uses and few people inspect carefully. It exists to provide running instances with their assigned IAM credentials, instance configuration data and bootstrap information. It also sits at the centre of a vulnerability class that has produced some of the most notable cloud breaches of the last few years. Server side request forgery vulnerabilities, when combined with the metadata service, can hand an attacker the credentials of any role assigned to the instance.
IMDSv2 Closes Most Of The Door
AWS introduced version two of the instance metadata service in response to the abuse of version one. IMDSv2 uses session tokens that must be requested before any metadata can be read, which breaks the simple SSRF payload that previously sufficed. The catch is that the old version is still available on many instances for backward compatibility. Configure new instances to require IMDSv2, and migrate existing instances onto the same setting as fast as the workload allows. A capable AWS pen testing engagement should report any instances still allowing IMDSv1 as a priority finding.
Application Layer SSRF Is Still A Threat
Even with IMDSv2, applications that proxy arbitrary user input into outbound HTTP requests can still produce dangerous outcomes. A vulnerability inside the application itself, where attacker controlled headers reach the metadata endpoint correctly, can still extract credentials. The application layer fix is to apply strict allow lists for outbound destinations and to reject metadata service addresses explicitly.
Expert Commentary
William Fieldhouse, Director of Aardwolf Security Ltd
A subtle pattern we have reported is an application that correctly blocks the standard metadata IP address and overlooks the various aliases AWS provides for the same service. An attacker who knows the aliases reaches the metadata service through the side door, even though the front door was locked.
Workload Identity Beats Static Credentials
Long lived credentials sitting in environment variables, configuration files or developer workstations are a perennial source of cloud breaches. AWS workload identity features such as IAM Roles for Service Accounts on EKS and instance role attribution eliminate the static credential entirely. Migrate where you can. The credentials that do not exist cannot leak. Migration to workload identity is often easier than teams expect. The supporting features in modern AWS services have matured considerably, and the documentation now covers most common scenarios in useful detail.
Role Permissions Should Be Minimal
Even if an attacker reaches the metadata service, the damage is bounded by the permissions of the role assigned to the instance. Instances should hold the smallest set of permissions the workload requires and no more. The classic finding of an instance role with broad administrative permissions is the difference between a contained incident and a full account compromise. Pair role hygiene with a vulnerability scan services approach that hunts for SSRF in your application portfolio and the chain weakens significantly.
The metadata service is enormously useful. It also concentrates risk in one place. Worth treating with the respect that concentration deserves. Cloud workload identity is one of the better security developments of the last few years. The migration is worth the effort for any organisation operating meaningfully in AWS. Cloud security is a shared responsibility model in name and a fully owned responsibility model in practice. The configuration choices that matter live on your side of the line, regardless of how the provider markets the platform.