IMDS (Instance Metadata Service) is a critical part of the AWS EC2 experience: from the instance you can query metadata and, if there is an associated role (Instance Profile), obtain temporary credentials to access other services. The problem is not the idea; the problem is IMDSv1: an HTTP endpoint accessible without additional authentication from the instance’s local network. In practice, that makes it a perfect target when there is any SSRF (Server-Side Request Forgery) vector.
When this happens in a company, it rarely comes from “an exposed server without control.” It usually comes from something much more mundane: an application that fetches URLs to generate previews, a webhook that validates callbacks, a connector that integrates SaaS, or a microservice that allows pointing to internal endpoints “for convenience.” If that component runs on EC2 with a role with useful permissions, IMDSv1 is the shortcut to credentials.
What went wrong: IMDSv1 and the assumption of “it’s only accessible from the instance”
IMDSv1 listens on a link-local IP (169.254.169.254) accessible from the instance. In IMDSv1 there is no additional challenge (token) to prevent a tricked process from making the request. If an application inside that instance can be induced to request an arbitrary URL, you already have a bridge to IMDS.
In a corporate environment, the typical mistake is not “we didn’t know IMDS existed,” but treating it as a platform detail and delegating the risk to networks or a WAF. SSRF bypasses many perimeter controls because the traffic origin is the server itself. If the server has HTTP egress and the app allows forcing requests, the attacker does not need direct connectivity to IMDS: the app does the work.
The real consequence is direct: the attacker queries metadata service paths to enumerate the role and extract temporary credentials. From there, the incident stops being “compromise of an app” and becomes “compromise of AWS” within the scope of the role’s permissions. This escalates quickly when instance roles are used as an operational identity for backups, deployment, access to S3, reading parameters, or even administration.
How the abuse materializes: Capital One-style SSRF to reach credentials
An SSRF often seems harmless at first: an endpoint that receives a URL (to import images, validate a webhook, fetch a PDF) and returns content or just a status code. With IMDSv1, being able to do any GET to 169.254.169.254 is enough to start getting useful information. Even if the response is not shown in full, many apps leak pieces, log content, or allow timing/oracles sufficient to extract data.
In a typical chain, the attacker first “tests the waters” by requesting basic metadata and then goes after role credentials. Once they have temporary credentials, exploration moves to AWS APIs: listing buckets, reading secrets, querying parameters, accessing queues, or dumping logs. The impact depends on the role’s IAM, not the app; that’s why in companies the damage usually exceeds the perimeter of the team operating that application.
- Role enumeration on the instance
The attacker forces the app to request metadata service paths until identifying the role name (for example, by querying the IAM roles path in metadata). In real operations, this shows up as a pattern of anomalous internal requests from the app process itself or from generic HTTP libraries that “suddenly” start talking to 169.254.169.254.
- Exfiltration of temporary credentials and use outside the instance
With the role name, the next step is to request the credentials document (AccessKeyId/SecretAccessKey/Token). Even if they are temporary, they often last long enough to operate. In corporate incidents, the attacker uses them from their infrastructure to call AWS APIs, which complicates attribution if you don’t have CloudTrail well instrumented and alerts for use “from outside” (new IPs, new user-agents, region changes).
Why IMDSv2 changes the game: tokens, sessions, and real friction against SSRF
IMDSv2 introduces a token-based session mechanism (PUT to obtain a token with TTL, then GET including the token). This is not “security by obscurity”; it is a concrete barrier against SSRF because it requires the client to perform an additional request and manage headers. Many SSRFs do not allow controlling method/headers, or only allow simple GETs. That small requirement breaks a huge number of real vectors.
In practice, IMDSv2 does not make abuse impossible in all scenarios (there are advanced SSRFs that allow methods and headers), but it raises the cost and reduces the number of exploitable paths. In companies, this translates into a significant reduction of systemic risk: a class of common bugs stops being automatically “cloud credential theft.”
- The improvement is not theoretical: it reduces the “blast radius” of common vulnerabilities
SSRF shows up in security reviews more often than we would like, especially in internal services with integrations. Enforcing IMDSv2 turns many of those findings into an application problem (serious, yes) but not necessarily into access to IAM credentials. That difference changes severity, containment urgency, and incident scope.
- IMDSv1 keeps a permanently open door
The risk of IMDSv1 does not depend on “whether there is SSRF today.” It depends on one appearing someday (in your code, in a library, in a legacy component, in a forgotten endpoint). In corporate environments with long cycles and multiple teams, assuming there will be no SSRF is betting against statistics.
How to do it in practice: enforce IMDSv2 and validate that IMDSv1 is not available
Operationally, the goal is for EC2 instances to run with IMDSv2 required (not “optional”) and, when possible, reduce exposure of the metadata service. This is managed at the instance or launch template (Launch Template) level and should be part of the platform standard, not an exception per team.
The common mistake in companies is “we enabled IMDSv2” but left it in optional mode so as not to break anything. That keeps IMDSv1 alive. If you want to close the fast path to credentials via basic SSRF, you need require. When something breaks, it usually reveals old dependencies (bootstrap scripts, agents, legacy AMIs) that are worth fixing, not perpetuating.
Expected configuration (at the instance or Launch Template level):
- HttpTokens = required
- HttpEndpoint = enabled (if you need it; if not, disabling it in specific cases reduces surface area)
- HttpPutResponseHopLimit adjusted (the default is usually sufficient; review if you have proxies/sidecars that may access IMDS)
Each point has operational impact: required forces libraries/tools to support IMDSv2; endpoint determines whether the service exists; and the hop limit affects whether “intermediate” network components can reach the metadata service. In architectures with local proxies or complex network configurations, this last parameter can prevent unwanted access from components that should not touch metadata.
Validation in AWS: check in the EC2 console (Instance details → Metadata options) that IMDSv2: required is applied. At inventory level, use AWS CLI to audit fleets:
aws ec2 describe-instances --query "Reservations[].Instances[].MetadataOptions"
In incident response and continuous hardening, this allows you to quickly detect instances that are still on IMDSv1 (tokens optional) and prioritize. The practical evidence is binary: if tokens are not required, the IMDSv1 vector still exists.
Recommendations for corporate environments
IMDSv1 is dangerous because it turns a relatively common SSRF into a direct path to the instance role’s temporary credentials. In a company, that usually amplifies the incident from one application to multiple resources in AWS, conditioned only by the IAM permissions assigned to the Instance Profile.
Enforcing IMDSv2 (tokens required) introduces real friction against SSRF and drastically reduces the number of exploitable scenarios. The measure is concrete, verifiable, and should be managed as a platform standard: in Launch Templates, in base AMIs, and in periodic audits that detect exceptions.
The practice that works best is to treat IMDSv1 as technical debt with security risk: identify instances with optional tokens, fix dependencies that prevent IMDSv2, and continuously validate that the change remains applied. The goal is not “to comply,” it is to prevent the next SSRF from ending in out-of-control AWS credentials.
Interested in Cloud Security?
Technical analysis, hands-on labs and real-world cloud security insights.