Home / Knowledge hub / Instance metadata service
Knowledge hub
Instance metadata service
A cloud server's local service that hands out its own credentials to whoever asks.
What it means
The instance metadata service, or IMDS, is a small web service that every cloud virtual machine can call at a fixed local address, 169.254.169.254 on AWS. It tells the machine about itself: its name, network details and, if a role is attached, temporary credentials.
Software on the machine uses it to get credentials without storing keys. The weakness is that the service answers anyone who can make a request from that machine. If an attacker can make your server fetch a URL of their choice, they can ask it for its own credentials.
Why it matters
This is why server-side request forgery is treated so seriously in cloud applications. A flaw that looks small, such as a URL-fetching feature, can return credentials for the server's role, and those credentials work from anywhere until they expire. What the attacker can then do is set by the role's permissions.
The effect is a step from one flaw to cloud-account access, which is classic lateral movement. The size of the damage is controlled by the role, and by whether the metadata service was hardened. Both are decisions your team can make today, before any flaw is found.
How it shows up
You meet it on virtual machines and in containers running on them. Common issues are an application that fetches user-supplied URLs, an old metadata version that answers a plain GET request, and containers that can reach the host's metadata service.
AWS offers IMDSv2, which requires a session token obtained with a PUT request and is much harder to trigger through a simple forged request. Require it, limit the hop count so containers cannot reach it, and give roles minimal permissions. Test by checking whether URL features can reach the metadata address.
Questions people ask
Instance metadata service, answered
What is the difference between IMDSv1 and IMDSv2?
IMDSv1 answers a simple request. IMDSv2 requires a session token, obtained first with a PUT request, so a basic forged GET is no longer enough. AWS lets you require IMDSv2 on instances.
Why do attackers want the metadata service?
Because it can return temporary credentials for the server's role. With those, they can act in your cloud account as the server, within the role's permissions, without ever logging in.
Is the metadata address reachable from the internet?
No. It is a link-local address that only the machine itself can reach. The risk is that your own application can be tricked into making the request for the attacker.
Do other clouds have this?
Yes. Major cloud providers offer a similar metadata endpoint on a fixed local address, and each has its own protections. The risk pattern is the same: a forged request from the server itself.
How do we test for this?
Look for features that fetch URLs, such as imports, previews and webhooks, and check whether they can be pointed at the metadata address or at internal addresses. Also check metadata version settings on your instances.
Sources
Where this comes from
Related
Terms that sit next to this one
SSRF
Making your server fetch a URL of the attacker's choosing.
SSRF in APIs
API features that fetch a caller-supplied address, such as import by URL or webhooks.
IAM role
A set of cloud permissions that a person or service can temporarily assume.
Cloud credentials leak
Cloud access keys exposed in code, images or logs and then used by others.
Cloud privilege escalation
Using a small cloud permission to gain a much larger one inside the same account.
Can your app be made to ask?
Any feature that fetches a URL is worth testing against internal and cloud addresses. We report what we actually reached, with the request and the response. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.