Instance metadata service (IMDS)

Every cloud instance can query a well-known internal address to learn about itself: its region, its tags, its network, and crucially the temporary credentials for the identity role attached to it. This is how a workload authenticates to cloud APIs without a stored key. The security of it turns on how the endpoint is accessed. The older scheme answers any process on the instance that asks, with no token, which means anything that can make an outbound request from the instance can read the role credentials. The hardened scheme requires a session token obtained through a specific request first, which blocks the most common abuse. The endpoint is meant for the workload; the problem is when something else on the instance can reach it.

This is where a web vulnerability becomes a cloud compromise. A server-side request forgery makes the application fetch a URL of the attacker’s choosing; point it at the metadata endpoint and, on the unhardened scheme, the response is the instance role’s credentials. From the attacker’s seat, an SSRF that would otherwise be a curiosity is suddenly a set of cloud API keys, and from there the attack follows the identity graph. The recurring failure we find is instances still answering the unauthenticated scheme, or an application permitted to make arbitrary outbound requests. The web bug and the cloud exposure are the same finding, which is why testing them separately misses it.

We test the chain end to end: whether an application can be induced to reach the metadata endpoint, whether the endpoint answers without a session token, and what the returned role can then do. The finding is the full path from web request to cloud credentials to impact, which usually continues along the cloud attack path that the role’s permissions allow. We also flag long-lived access keys reachable the same way. This is part of how we test metadata and credential exposure.