SSRF in 2026: Cloud Metadata, IMDSv2 Bypasses, and Real Impact

Server-Side Request Forgery stays near the top of cloud-era bug classes because of one target: the cloud metadata service, which hands out temporary credentials to anything that can reach it from inside the instance.

The classic kill chain

Find a feature that fetches a URL you control (webhook, PDF/image-from-URL, link preview, import-from-URL), then point it at the metadata endpoint:

# AWS IMDSv1 (legacy, no token required)
curl "http://vulnerable.app/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/"
# -> role name, then:
curl "http://vulnerable.app/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE"
# -> AccessKeyId / SecretAccessKey / Token = cloud account access

The same idea applies to GCP (metadata.google.internal, requires the Metadata-Flavor: Google header) and Azure IMDS.

Why IMDSv2 matters

AWS IMDSv2 requires a PUT to obtain a session token first, which a simple GET-based SSRF cannot do — so enforcing IMDSv2 (and setting the hop limit to 1) blocks the easy path. Many environments still allow IMDSv1, which is why this remains a live finding.

Bypasses pentesters still try

• Alternate IP encodings of 169.254.169.254 (decimal, octal, IPv6-mapped).
• Redirect-based SSRF where the allow-list checks the first URL but follows a redirect to metadata.
• DNS rebinding against a hostname that resolves to the metadata IP after the check.

Defences

1. Enforce IMDSv2 and set the metadata hop limit to 1.
2. Validate and re-resolve URLs after redirects; block link-local and private ranges.
3. Egress controls so app servers cannot reach 169.254.169.254 unless they must.
4. Least-privilege instance roles so a leaked credential is low-value.

RingSafe tests for SSRF-to-cloud-takeover chains in web and cloud pentests. See our VAPT services. Test only systems you are authorised to assess.