The instance metadata service (IMDS) is a small internal web service that every major cloud provider runs for each virtual machine. A program running on the machine can ask it questions about itself, such as “what is my instance ID?” and “what region am I in?”. Most importantly, it can ask for temporary credentials that let the machine call cloud APIs without a stored password or key.
That last feature is why IMDS matters for security. It is a place where live cloud credentials are handed out on request, to anything that can reach it from inside the machine. If an attacker can make a server ask for them and read the answer, they walk away with the server’s cloud identity.
This guide explains what IMDS is, why it exists, how an attacker reaches it, what the difference between IMDSv1 and IMDSv2 means, where IMDSv2 stops helping, and how to configure your environment safely. No prior knowledge of cloud internals is assumed.
What IMDS is, in plain terms
When you run a virtual machine in the cloud, it often needs to do things in your cloud account. It might read a file from storage, write to a database, or fetch a secret. To do that, it has to prove who it is to the cloud provider. The old way was to put an access key on the machine. That is risky, because a key sitting on disk can be copied, forgotten, and never rotated.
The better way is to attach an identity to the machine, such as an IAM role on AWS, a managed identity on Azure, or a service account on Google Cloud. The machine then asks IMDS for short-lived credentials whenever it needs them. The cloud rotates them automatically. Nothing long-lived needs to be stored.
IMDS is the delivery point for that arrangement. It is reachable at a special address that only works from inside the machine itself: 169.254.169.254. This is a “link-local” address, meaning it is not routed over the internet. Only software running on that VM (or in some setups a container on it) can talk to it.
What IMDS tells a machine
IMDS exposes a lot more than credentials. Typical data includes:
- Instance ID, instance type, and hostname
- Region, availability zone, and network details such as private IP addresses
- Tags (if enabled)
- The identity attached to the machine and its temporary credentials
- “User data”, a script or configuration passed in at launch. This is sometimes misused to carry secrets, which makes IMDS even more sensitive.
On AWS, the credentials for an instance’s role are served from a path of the form /latest/meta-data/iam/security-credentials/<role-name>. A plain request to that path returns an access key ID, a secret access key, and a session token. Together these are a working login to AWS with the permissions of that role, valid until they expire.
Why this is a target
Think about what an attacker needs to obtain these credentials: a way to make the server send a request to 169.254.169.254 and show them the response. They do not need to log in to the machine or know any password. They need one of two things.
Route 1: Server-side request forgery (SSRF)
SSRF is a flaw where an application can be tricked into making a web request on an attacker’s behalf. Imagine a feature that fetches a web page from a URL the user supplies, such as a link preview, an image importer, or a webhook tester. If the application does not check where that URL points, an attacker can give it http://169.254.169.254/latest/meta-data/iam/security-credentials/ instead. The server, sitting inside the network, dutifully fetches it and returns the result to the attacker.
This is a well-known pattern. The 2019 breach of Capital One, widely reported, involved SSRF against a misconfigured web application firewall to retrieve role credentials from the metadata service. The OWASP SSRF prevention cheat sheet describes the underlying flaw, and OWASP’s SSRF overview is a good starting point if the term is new to you.
Route 2: Code execution on the machine
If an attacker can run commands on the server through a vulnerable application, an unpatched component, or an exposed admin interface, they can simply call IMDS themselves. This is a remote code execution scenario. Reading metadata is usually one of the first things an attacker does after getting a foothold, because it converts a compromise of one server into a cloud identity they can use from anywhere.
A real campaign illustrating this: attackers who took over an abandoned AI agent server used it to probe cloud metadata for credentials. We cover that in how an abandoned AI agent server becomes a door to your cloud credentials.
Why a stolen metadata credential is dangerous
Once the attacker has the temporary credentials, they can use them from their own machine, not just from the compromised server. The credentials are valid wherever they are presented, as far as the provider is concerned, until they expire. Two factors decide the damage:
- How long they last. Role credentials are temporary and refresh regularly, so an attacker has to keep coming back, but they only need a window. Within it they can enumerate your account, read data, and create new persistent access.
- What the role is allowed to do. This is the blast radius. A server whose role can only read one storage bucket yields a small breach. A server with broad administrator rights yields a catastrophic one. This is why least privilege on instance roles matters as much as hardening the metadata service itself.
IMDSv1 vs IMDSv2 (AWS)
AWS offers two versions of its metadata service, and the difference is the single most important configuration point on this topic.
IMDSv1 is the original, request-and-response design. Any plain HTTP GET request to the metadata address returns the data. That simplicity is exactly why SSRF works against it: a vulnerable app that can be made to issue one GET request to the right URL leaks the credentials.
IMDSv2 is session-oriented. Before reading anything, the caller must first send a PUT request to obtain a short-lived session token, then include that token in a header on every following request. The AWS documentation describes the flow in how IMDSv2 works. Three properties make IMDSv2 much harder to abuse:
- It needs a PUT request with custom headers. Many SSRF bugs only let an attacker control the URL of a GET request. They cannot choose the method or add headers, so they cannot complete the token handshake.
- It rejects requests that look proxied. IMDSv2 is designed to refuse requests carrying forwarding headers, which helps against reverse proxies and some firewalls that unwittingly relay a request.
- The token response has a limited network reach. By default, the token response is limited to a single network hop, so it does not travel beyond the instance. This makes it much harder for a request relayed from outside to receive the token. On container platforms, this is also why a container on a separate network namespace can lose access to metadata unless the hop limit is raised.
Put simply, IMDSv1 trusts any request that reaches it. IMDSv2 asks the caller to prove it is genuinely running on the machine and deliberately making the request.
How other clouds handle it
The mechanism differs, but the idea is the same. Azure’s metadata service at the same link-local address requires a Metadata: true header on requests and uses it to issue tokens for managed identities. Google Cloud’s metadata server requires a Metadata-Flavor: Google header. These header requirements block the simplest SSRF attempts, much as IMDSv2 does, though they are not as strict as AWS’s token handshake. The same principles apply across providers: limit who can reach the endpoint, and limit what the attached identity can do.
What IMDSv2 does not protect against
It is important to be honest about the boundary of this control, so you know what else you need.
- It does not stop code execution on the host. If an attacker can run commands on the machine, they can perform the PUT and GET steps themselves. IMDSv2 raises the bar against SSRF and misrouted requests. It does not help once the attacker is already inside.
- It does not shrink the role’s permissions. A hardened metadata service in front of an over-privileged role still leads to a large breach if anything goes wrong.
- It does not stop stolen credentials from working elsewhere by default. You can add conditions to your policies that tie credentials to the network or VPC they were issued in, such as the
aws:EC2InstanceSourceVPCcondition key. This makes credentials stolen from an instance much less useful when used from outside. Check the current AWS IAM documentation for the exact keys supported before relying on them. - It does not fix the underlying application flaw. The SSRF or code execution bug still needs patching.
How to lock down the metadata service
1. Require IMDSv2 and turn off IMDSv1
On AWS, set the instance’s metadata options to require tokens. This disables IMDSv1 for that instance:
aws ec2 modify-instance-metadata-options \
--instance-id i-0123456789abcdef0 \
--http-tokens required \
--http-endpoint enabledTo make this the default for new instances in a region, AWS lets you set account-level metadata defaults. See configuring the instance metadata service for current options. Before enforcing it broadly, check that older software on your instances does not depend on IMDSv1. Some old SDK versions and agents do. Test on non-critical instances first.
2. Keep the hop limit at 1 where containers are not meant to reach it
A hop limit of 1 keeps the metadata response from leaving the host. If you run containers that genuinely need metadata access, raise it deliberately for those instances rather than globally.
3. Shrink what each instance role can do
Give every instance only the permissions its workload needs: specific actions on specific resources. Review roles for unused permissions and remove them. CIEM helps by showing which entitlements an identity holds but never uses.
4. Turn the endpoint off where it is not needed
If a workload never calls metadata, disable the endpoint. No endpoint means nothing to attack. On AWS this is --http-endpoint disabled.
5. Fix SSRF at the application layer
Do not rely on infrastructure alone. Validate and restrict URLs your application fetches: allow-list the destinations it should reach, block link-local and private address ranges, and avoid following redirects blindly.
6. Keep secrets out of user data
User data is readable through metadata. Never put credentials in it. Retrieve secrets at run time from a secrets manager.
7. Reduce what is exposed to the internet
An SSRF or code-execution flaw can only be exploited if the vulnerable service is reachable. Keep management interfaces and internal tools off the public internet, and patch or retire end-of-life software, which is a frequent source of these flaws.
8. Watch for misuse
Credentials taken from metadata and used elsewhere often show up as an instance role making API calls from an unusual IP address, or performing discovery actions the instance never normally does. Cloud audit logs such as AWS CloudTrail record these calls. See what is AWS CloudTrail.
A short checklist
- Is IMDSv2 required on every instance, and IMDSv1 off?
- Is the hop limit 1 unless a container workload needs more?
- Does each instance role follow least privilege?
- Are management interfaces off the public internet?
- Are your internet-facing apps tested for SSRF?
- Is there any secret in user data?
- Would you notice an instance role being used from an outside IP?
How Cloudanix helps
Cloudanix does not change how a cloud provider’s metadata service works, and it cannot fix a vulnerable application for you. It finds the conditions that make a metadata attack possible and shows how far one would reach.
- Find weak configuration. Posture checks flag EC2 instances that do not enforce IMDSv2 and roles with excessive permissions, continuously rather than as a one-off audit.
- See the real blast radius. The unified asset graph and attack path analysis connect an internet-exposed, vulnerable workload to the role attached to it and to the data that role can reach, so you can tell which server matters most.
- Trim excess permissions. CIEM identifies unused entitlements on instance roles so they can be removed.
- Prioritize the vulnerabilities that lead here. Vulnerability findings are correlated with exposure and identity, and enriched with CISA KEV and EPSS data, so an exploitable flaw on a server with a powerful role rises to the top.
- Detect misuse. Cloud detection and response and cloud UEBA flag an identity used from a new location or running discovery calls it has never run before.
Frequently asked questions
What is the instance metadata service?
It is an internal service each cloud VM can query to learn about itself and to obtain temporary credentials for its attached cloud identity. It is reachable only from the machine itself at the address 169.254.169.254.
Why is IMDS a security risk?
Because it hands out live credentials to whatever can reach it from inside the machine. If an attacker uses SSRF or code execution to make the machine query it, they can obtain the machine’s cloud identity and use it elsewhere.
What is the difference between IMDSv1 and IMDSv2?
IMDSv1 answers any plain GET request. IMDSv2 requires a session token obtained through a PUT request and then supplied in a header on later requests. That extra handshake defeats many SSRF attacks, which cannot control request methods or headers.
Does IMDSv2 make me safe?
It makes a major class of attack much harder, but it does not stop an attacker who already has code execution on the host, and it does not limit what the instance role can do. Combine it with least-privilege roles and fixing the application flaws.
Is this only an AWS problem?
No. Azure and Google Cloud have equivalent metadata services that issue tokens to attached identities. Their header requirements block simple attacks, but the same principles apply: limit access to the endpoint and limit what the identity can do.
How do I check whether my instances enforce IMDSv2?
In AWS, check each instance’s metadata options for HttpTokens set to required. A cloud security posture tool can check this across all accounts and regions at once, which is easier than inspecting instances one by one.
