Cloud Metadata Service Abuse: Turning SSRF Into Credentials in Modern Web Stacks

A server-side request forgery is usually treated as a moderate finding. When the server runs in a cloud environment with a metadata service reachable from the instance, the same bug can hand over credentials that the workload uses to talk to the rest of the account.

Why the reader needs this

The metadata service is reachable from inside the instance at a link-local address and is not routable from the internet. That design is what makes it convenient and what makes it dangerous: an application that can be induced to fetch a URL can be induced to fetch the metadata endpoint.

The result is not just information disclosure. On many platforms the metadata service issues temporary credentials or tokens that the instance can use, and those credentials carry whatever permissions the instance role or managed identity has.

Technical context

The classic endpoint is 169.254.169.254. On some platforms a request to a well-known path returns instance identity documents, and a further request returns temporary credentials. On others, the workload requests a token from a local endpoint and presents it to the cloud control plane.

Newer platforms require a session-oriented request that is harder to trigger through a simple SSRF. That mitigation raises the bar, but it does not remove the risk when an attacker can control headers or make multiple requests.

Explanation: where SSRF meets metadata

The dangerous combination is a server-side feature that fetches a user-supplied URL and returns or reflects the response. Common examples include image proxies, webhook testers, PDF renderers, link previews and import-from-URL features.

When such a feature runs on an instance with a permissive role, the attacker can request the metadata endpoint, read the credentials, and use them from their own machine. Because the credentials are legitimate, the activity may look like normal automation.

Defensive implications

• Require the session-oriented metadata mode where the platform offers it, and set the hop limit to one so that containers cannot reach the metadata service through the host.
• Apply least privilege to instance roles and managed identities. A workload that only reads one bucket should not be able to modify the account.
• Block egress to link-local addresses from application containers, and validate outbound destinations in URL-fetching features.
• Do not return raw responses from server-side fetches to the user. Return a normalized result instead.
• Monitor for metadata endpoint access from unexpected processes, and for credential use from outside the expected network range.

Limits exist. Some platforms do not offer the stronger metadata mode, and some workloads legitimately need broad permissions. In those cases the compensating control is network-level blocking plus monitoring.

References

• AWS documentation, Instance metadata and user data.
• Microsoft Learn, Managed identities for Azure resources.
• Google Cloud documentation, About VM metadata.