Cloud Metadata Endpoints: Security Risks and Protection

Every major cloud provider exposes an instance metadata service to virtual machines running on their platform -- typically reachable at the link-local address 169.254.169.254. From inside the instance, a simple HTTP request to that address can return the instance's configuration, networking details, and, in many default configurations, temporary security credentials for whatever role or identity the instance was assigned.

Why it's dangerous specifically in combination with SSRF

The metadata endpoint is only supposed to be reachable from the instance itself -- it's not exposed to the public internet. But if a server-side process can be tricked into making an HTTP request to an attacker-chosen address (classic SSRF), and that address happens to be the metadata endpoint, the attacker gets the server to fetch its own cloud credentials and hand them over in the response. No direct network access to the metadata endpoint is needed from outside -- the vulnerable server does the fetching on the attacker's behalf.

• 169.254.169.254 falls within the broader 169.254.0.0/16 link-local range, which should never be treated as a legitimate public DNS resolution target.
• Some providers have moved to a token-gated version of the metadata service specifically to raise the bar against naive SSRF, but blocking the address entirely at the application layer remains the more robust defense.
• This is exactly why link-local addresses belong on the same blocklist as private and loopback ranges in any tool that resolves user-supplied domains -- it's not a separate, lesser category of risk.

The practical takeaway

Any system that resolves and requests a URL on a user's behalf needs to treat 169.254.169.254 -- and the wider link-local range it lives in -- as strictly off-limits, checked at the point of the actual request, every time, regardless of how the address was arrived at (typed directly, or reached through a DNS record pointing straight at it).

It's not unique to one cloud provider

169.254.169.254 specifically is the AWS, Google Cloud, and Azure convention, but the underlying pattern -- a link-local address exposing instance identity and credentials only to the instance itself -- shows up across virtually every major cloud and container platform in some form, sometimes at the same address, sometimes at a provider-specific one. Kubernetes clusters commonly have their own internal metadata-adjacent endpoints reachable from inside a pod. The specific address is worth memorizing for the common cloud providers, but the general principle -- treat every metadata-style endpoint as off-limits to anything that resolves and fetches a user-supplied URL, regardless of which platform it's running on -- is the part that actually generalizes.

IMDSv2: a real mitigation, not just a filter

AWS's response to years of exactly this exploitation pattern was a second version of its metadata service, IMDSv2, which requires a session token obtained via a special PUT request before any metadata can be read -- and, critically, that PUT request cannot be replicated by a simple SSRF-triggered GET request that most vulnerable code paths actually make.

It's a meaningful improvement, but it's opt-in on many accounts for backward compatibility, and it protects only the metadata endpoint specifically -- it does nothing for every other private and internal address an SSRF could still reach. Application-level filtering of resolved addresses remains necessary regardless of which metadata service version is in use.