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

In March 2025, a single threat actor made 69,433 probes across servers using six parameter names: url, dest, file, redirect, target, uri. The target was always the same: 169.254.169.254. No zero-day was involved. Every parameter tested ships in production APIs today.

Every cloud-hosted API carries an invisible SSRF severity multiplier set at instance launch: IMDSv1 or IMDSv2. The six URL-accepting parameter categories present in virtually every production API form the attack surface. The IMDSv1/v2 decision made at deployment converts any SSRF hit from medium-severity data exposure to critical credential theft in a single unauthenticated request.

The six parameter types present in every production API

The March 2025 F5 Labs campaign documented what security engineers should have known for years: attackers do not invent SSRF attack surfaces, they enumerate them. Six URL-accepting parameter types appear across virtually every production API: webhook callbacks (url, dest), import-from-URL (file, target), and PDF and screenshot renderers. Avatar fetchers, link previewers, and OAuth callback validators complete the set. Each category carries a distinct exploitation chain.

OWASP classifies webhooks, callbacks, and URL imports as the primary SSRF vectors in modern APIs (API7:2023). H1 #508459 shows an Omise webhook URL parameter retrieving AWS IAM credentials via HTTP 303 redirect. H1 #643278 shows a Dynatrace custom integration endpoint producing the same outcome through blind SSRF.

The attacker's job is to enumerate these parameters, not create them. A typical e-commerce API has payment webhooks, avatar uploads, link previews for social sharing, and at least one OAuth callback URL endpoint. That puts 4 of the 6 types present before the first deploy.

IMDSv1 vs IMDSv2: the severity multiplier

IMDSv1 responds to a single unauthenticated GET:

GET http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>

The response is a JSON object containing AccessKeyId, SecretAccessKey, and Token valid for hours. Any of the six parameter types above completes that credential theft in one HTTP hop. This is why SSRF in cloud-hosted APIs has consistently higher real-world impact than CVSS scores suggest.

IMDSv2 requires a PUT with the X-aws-ec2-metadata-token-ttl-seconds header before any metadata fetch. That session token blocks most classic SSRF. AWS disabled IMDSv1 by default for new instances in November 2023. Existing instances continue running IMDSv1 unless explicitly migrated.

CVE-2021-21311 (Adminer SSRF, CVSS 7.2) demonstrated this chain exactly. Mandiant's UNC2903 used relay boxes with 301 redirects to bypass direct redirect blocking and retrieve IAM credentials from IMDS. No authentication was required, only an instance with IMDSv1 active.

Three CVEs that defined the exploitation template

CVE-2021-26855 (ProxyLogon, CVSS 9.8) is the most studied case of SSRF through an API endpoint. Exchange ECP accepted an X-BEResource cookie header that redirected requests internally to arbitrary backends without authentication. Chained with CVE-2021-26858, the result was full OS-level RCE. The Hafnium group and multiple ransomware operations exploited this chain in Q1 2021, before patches were available to most organizations. In cloud-hosted Exchange deployments, the same SSRF-to-internal-backend chain reaches 169.254.169.254 instead of on-premise backend services.

CVE-2021-21985 (VMware vCenter, CVSS 9.8) operated differently: a default-enabled plugin in vCenter 6.5, 6.7, and 7.0 exposed an unauthenticated API on port 443. The vSAN Health Check plugin combined CWE-918 (SSRF) with CWE-20 (improper input validation) to achieve RCE with the OS privileges of the vCenter service account. The attack vector was the plugin's URL parameter. The cloud deployment equivalent routes the same unauthenticated request to the instance metadata endpoint, with IMDSv1 returning credentials directly.

CVE-2021-21311 closes the set at CVSS 7.2 with real-world critical impact. Adminer processed database connections via URL. UNC2903 set up relay servers responding with 301 redirects pointing to 169.254.169.254, bypassing direct-redirect blocking. The recovered IAM credentials enabled lateral movement to other AWS resources in the account.

Three H1 reports mapped by parameter type

H1 #508459 (Omise) is the clearest webhook SSRF case. The payment platform's webhook URL parameter accepted arbitrary URLs. The researcher configured an intermediary server responding with HTTP 303 to 169.254.169.254/latest/meta-data/iam/security-credentials/aws-opsworks-ec2-role. The returned credentials were production-valid.

H1 #643278 (Dynatrace) demonstrated blind SSRF on the same parameter type. The monitoring platform returned only success or failure status for custom webhook integrations. The researcher confirmed exfiltration via out-of-band DNS callback: the Dynatrace server made the request and credentials were retrieved. No visible HTTP response was available to the attacker.

H1 #1624140 (U.S. Department of Defense) confirms that IMDSv1 remained active in high-security government infrastructure. A single GET to 169.254.169.254 returned AWS metadata. The researcher documented potential cross-account privilege escalation from the recovered credentials.

Blind SSRF: no visible response, but the request executed

Most production SSRF vulnerabilities return no response body to the attacker. The fetched content is processed internally by the server. That does not make the vulnerability benign; it makes detection harder for defenders and more labor-intensive for attackers.

The standard technique is OOB callback. Burp Collaborator and interactsh generate unique subdomains per test. A DNS query from the target server to unique-id.collaborator.net proves SSRF execution even without an HTTP response. The probe across all six parameter types uses url=http://unique-id.collaborator.net.

Blind SSRF against IMDSv1 remains critical without a visible HTTP response. Credentials can be exfiltrated via DNS TXT queries, or the attacker uses recovered credentials directly without seeing them in transit. Any request from the target server to an attacker-controlled endpoint can carry the payload in query string or path.

The pre-deployment control that changes the severity class

URL allowlists and DNS rebinding mitigations address the bypass mechanism. The control that reduces SSRF from critical credential theft to information disclosure is enforcing IMDSv2 at the hypervisor level, before the API deploys.

For existing instances:

aws ec2 modify-instance-metadata-options \
  --instance-id <id> \
  --http-tokens required \
  --http-put-response-hop-limit 1

The hop-limit=1 blocks the redirect chain H1 #508459 demonstrated. For new launches, --metadata-options HttpTokens=required belongs in the instance template, not in a post-exploit remediation ticket.

GCP requires the Metadata-Flavor: Google header on all responses. Azure requires Metadata: true. Standard SSRF fetches return 400 errors on those providers because no standard HTTP library includes those headers. GCP and Azure metadata layers are header-gated by default. AWS was not, until November 2023.

The MAGO team tool (mago.team) enumerates the six URL-accepting parameter types across API endpoints. It automatically tests whether each accepts requests to 169.254.169.254, with and without the PUT header required by IMDSv2.

Audit your API for the six parameter types before the next pentest finds them. Then check every EC2 instance hosting a URL-accepting endpoint:

aws ec2 describe-instances \
  --query 'Reservations[].Instances[].[InstanceId,MetadataOptions.HttpTokens]'

Any result that is not required is an IMDSv1 instance waiting for someone to find your webhook URL.