An SSRF becomes remote code execution when the vulnerable server can reach a cloud metadata endpoint, retrieve credentials, and use them to run code on your infrastructure. On its own an SSRF often scores as medium severity — chained through metadata it is critical. Here is the exact path.
What is SSRF and why is it dangerous in the cloud?
Server-Side Request Forgery (SSRF) lets an attacker make the server send HTTP requests to destinations of their choosing. In a cloud environment, the highest-value destination is the instance metadata service (IMDS) at 169.254.169.254, which hands out temporary credentials to any process that can reach it.
The chain, step by step
- Find the SSRF. A URL parameter, webhook, PDF renderer or image fetcher that takes a user-supplied URL and fetches it server-side.
- Reach the metadata endpoint. Point it at
http://169.254.169.254/latest/meta-data/iam/security-credentials/to enumerate the instance role. - Pull the credentials. Fetch the role's temporary
AccessKeyId,SecretAccessKeyandToken. - Escalate to code execution. Use those credentials against the cloud API — a deploy pipeline, a Lambda update, or an SSM
SendCommand— to run code on the target.
Each step is modest on its own. Together they are a full breach — and a CVSS score on the SSRF alone would never show it.
How do you break the chain?
- Enforce IMDSv2 (session-token required) so a naive SSRF can't read credentials.
- Egress-filter the metadata IP at the network layer.
- Validate and allow-list outbound URLs; never fetch user-supplied hosts directly.
- Scope instance roles to least privilege so stolen credentials do little.
Break any single link and the chain collapses. That is exactly what proof of exploitation surfaces that a scanner cannot: the path, not the isolated finding.
Want this run against your own stack, safely? Point us at your attack surface.