SSRF in APIs: Six URL-Accepting Parameter Types and the IMDSv1/IMDSv2 Decision That Determines Severity

In March 2025, a singular threat actor conducted 69,433 probes across servers, targeting a consistent endpoint at 169.254.169.254. Six different parameter names were utilized in these attacks: url, dest, file, redirect, target, and uri. These parameters are present in production APIs worldwide, and each cloud-hosted API carries an invisible SSRF severity multiplier, determined by the IMDSv1 or IMDSv2 at deployment.

Six URL-accepting parameter types are present in virtually every production API, forming the attack surface. These parameters include webhook callbacks (url, dest), import-from-URL (file, target), PDF and screenshot renderers, avatar fetchers, link previewers, and OAuth callback validators. Each category carries a distinct exploitation chain, with webhooks, callbacks, and URL imports classified as the primary SSRF vectors in modern APIs (API7:2023).

The IMDSv1 and IMDSv2 decision made at deployment can convert any SSRF hit from a medium-severity data exposure to a critical credential theft in a single unauthenticated request. IMDSv1 responds to a single unauthenticated GET request, returning a JSON object containing AccessKeyId, SecretAccessKey, and Token valid for hours. IMDSv2 requires a PUT with the X-aws-ec2-metadata-token-ttl-seconds header before any metadata fetch, blocking most classic SSRF attacks.

AWS disabled IMDSv1 by default for new instances in November 2023, but existing instances continue running IMDSv1 unless explicitly migrated.

Three CVEs defined the exploitation template for SSRF through API endpoints: CVE-2021-21311 (Adminer SSRF, CVSS 7.2), CVE-2021-26855 (ProxyLogon, CVSS 9.8), and CVE-2021-21985 (VMware vCenter, CVSS 9.8). These vulnerabilities highlight the severity of SSRF attacks in cloud-hosted APIs and the importance of IMDSv1/IMDSv2 decision-making in determining the severity of such attacks.