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

Modern API security is often compromised by the enumeration of URL-accepting parameters. During a campaign documented in early 2025, threat actors leveraged six distinct parameter names to probe cloud-hosted APIs for Server-Side Request Forgery (SSRF) vulnerabilities: url, dest, file, redirect, target, and uri. These parameters are not vulnerabilities in themselves, but they provide the essential interface for attackers to force an API to make unauthorized outbound requests to sensitive internal resources, specifically the Instance Metadata Service (IMDS) at 169.254.169.254.

These parameters appear ubiquitously across standard production features:

• Webhooks and Callbacks: Using url or dest for asynchronous notifications or OAuth flows.
• Content Fetchers: Using file or target for import-from-URL functionalities.
• Media Processing: PDF renderers, screenshot engines, avatar fetchers, and link previewers, which frequently utilize all six parameter types to process external assets.

The severity of an SSRF vulnerability is determined by the IMDS configuration enforced at the hypervisor level. In environments running IMDSv1, a single unauthenticated GET request to the metadata endpoint can return a JSON object containing temporary security credentials (AccessKeyId, SecretAccessKey, and Token). Attackers use the six identified parameters to exfiltrate these credentials, often chaining redirects to bypass simple URL validation.

To mitigate this risk, enterprise engineers must move beyond basic input validation. While URL allowlists and DNS rebinding protections are necessary, they are frequently bypassed via relay servers and redirect chains. The most effective control is the migration to IMDSv2. By setting HttpTokens=required and HttpPutResponseHopLimit=1, you mandate that requests include a session token retrieved via a PUT method, effectively nullifying the impact of classic SSRF. For existing cloud deployments, auditors should verify the metadata status of every instance: aws ec2 describe-instances --query 'Reservations[].Instances[].[InstanceId,MetadataOptions.HttpTokens]'. Any instance returning a status other than required remains susceptible to credential exfiltration via these standard parameter types.

In cloud‑hosted APIs the instance metadata service (IMDS) is the decisive factor that turns a generic SSRF flaw into a credential‑theft vector. The reason is simple: the metadata endpoint http://169.254.169.254 exposes the IAM role attached to the instance, and the way that endpoint authenticates requests is controlled by the IMDS version selected at launch.

IMDSv1 behavior

• Accepts an unauthenticated GET request directly to /latest/meta-data/iam/security-credentials/<role>.
• Returns a JSON document containing AccessKeyId, SecretAccessKey, and Token that are valid for several hours.
• Any of the six common URL‑accepting parameters (e.g., url, dest, file, target, uri, redirect) can be used to cause the vulnerable service to issue that single GET request, completing credential theft in one hop.

IMDSv2 behavior

• Requires a prior PUT to /latest/api/token with the header X-aws-ec2-metadata-token-ttl-seconds to obtain a session token.
• Subsequent metadata fetches must include X-aws-ec2-metadata-token header; otherwise the request is rejected.
• This extra round‑trip blocks the classic “single‑request” SSRF chain used against IMDSv1.

Because the IMDS request is often the final step in the exploitation chain, the presence of IMDSv1 multiplies the severity of any SSRF finding from “information disclosure” to “critical credential theft.” The evidence shows real‑world exploits (e.g., CVE‑2021‑21311, Mandiant UNC2903) that succeeded solely because the target instance allowed IMDSv1.

Practical mitigation steps

• Enforce IMDSv2 at instance launch:

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

• Verify configuration across all instances:

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

• For new workloads, include --metadata-options HttpTokens=required in the launch template.
• Apply provider‑specific header checks (e.g., GCP’s Metadata-Flavor: Google, Azure’s Metadata: true) which already block unauthenticated metadata access.

By ensuring that every EC2 instance runs IMDSv2, the SSRF severity multiplier is reduced from credential theft to mere data exposure, aligning the risk posture with controls required by standards such as NIST SP 800‑53 and ISO 27001.

Server-Side Request Forgery (SSRF) represents a critical risk in modern API architectures, particularly when URL-accepting parameters enable internal network access. Attackers do not typically invent these vectors; they enumerate standard API patterns such as webhook callbacks (e.g., url, dest), import-from-URL features (e.g., file, target), and various link preview or OAuth validators. When these endpoints are exploited, they serve as a gateway to Remote Code Execution (RCE) or sensitive data exfiltration.

The severity of an SSRF vulnerability is frequently dictated by the underlying cloud instance metadata service (IMDS) configuration. Specifically, IMDSv1 responds to unauthenticated GET requests, allowing an SSRF hit to yield temporary AWS IAM credentials—including AccessKeyId, SecretAccessKey, and Token—in a single HTTP hop. This escalation path transforms a standard SSRF into a total account compromise.

Historical exploitation templates confirm this trajectory:

• CVE-2021-26855 (ProxyLogon): Utilized an X-BEResource cookie to force internal redirects. In cloud-hosted instances, this mechanism was capable of reaching the IMDS metadata endpoint, escalating to full OS-level RCE when chained with subsequent vulnerabilities.
• CVE-2021-21985 (VMware vCenter): An unauthenticated vSAN Health Check plugin used a URL parameter to trigger SSRF, which, when directed at the metadata service, provided high-privilege service account credentials.
• CVE-2021-21311 (Adminer): Demonstrated the use of 301 redirects to bypass basic redirect-blocking filters, ultimately accessing IAM credentials from the local metadata service.

H1 reports highlight the diverse implementation of these attacks. H1 #508459 demonstrated a webhook parameter triggering a 303 redirect to retrieve production IAM roles. H1 #643278 identified blind SSRF where, despite the absence of an HTTP response body, the attacker confirmed success via out-of-band DNS callbacks. H1 #1624140 emphasized that even high-security environments often maintain legacy IMDSv1 configurations, leaving them susceptible to cross-account privilege escalation.

To mitigate these risks, engineering teams must transition to IMDSv2, which requires a PUT request with a session token header, effectively neutralizing classic SSRF chains. For existing infrastructure, administrators should audit instance metadata options using the aws ec2 describe-instances command and mandate HttpTokens=required to block unauthorized access to the metadata layer.

Server-Side Request Forgery (SSRF) is frequently mischaracterized as a low-severity issue if the application does not return a visible response body to the attacker. In production environments, SSRF is rarely benign. Even when HTTP responses are suppressed or hidden by the application layer, the underlying request still executes from the server's context. This enables blind SSRF, where attackers confirm success and exfiltrate data through out-of-band (OOB) techniques.

In blind SSRF, the server acts as a proxy for the attacker. Because the server itself initiates the outbound connection, it can interact with internal network resources or the Instance Metadata Service (IMDS). Attackers rely on OOB callbacks to bridge the visibility gap:

• DNS Callbacks: Using tools that generate unique subdomains (e.g., collaborator.net), an attacker forces the target server to perform a DNS lookup. The arrival of this query at the attacker's infrastructure confirms execution despite the absence of an HTTP response.
• Data Exfiltration: Sensitive data—such as cloud provider credentials—can be exfiltrated by embedding stolen values into the path or query string of an outbound request, or by encoding them within DNS TXT queries that the attacker monitors.

The severity of these SSRF vectors is fundamentally tied to the cloud provider's metadata configuration. For AWS environments, the IMDSv1/IMDSv2 decision acts as a critical severity multiplier. If IMDSv1 remains active, an unauthenticated GET request to 169.254.169.254 is sufficient to retrieve IAM security credentials. Attackers exploit this via URL-accepting parameters common in modern APIs, such as url, dest, file, target, redirect, and uri. These parameters facilitate the entire exploitation chain, often utilizing 301 or 303 redirects to bypass simple input filters.

To mitigate the risks associated with blind SSRF and OOB exfiltration, engineers must move beyond input validation and enforce architectural controls:

• Enforce IMDSv2: Transition all instances to require session-oriented tokens (HttpTokens=required). This mandates a PUT request before metadata access, effectively neutralizing simple SSRF vectors.
• Constraint Configuration: Configure the IMDS hop limit to 1 (--http-put-response-hop-limit 1) to prevent redirect-based bypasses.
• Header Gating: Ensure sensitive internal endpoints require specific headers (e.g., Metadata-Flavor: Google for GCP or Metadata: true for Azure), which standard SSRF payloads generally cannot replicate.

Server‑Side Request Forgery (SSRF) in cloud‑hosted APIs often escalates from data exposure to credential theft when the instance metadata service (IMDS) is reachable. IMDSv1 answers a single unauthenticated GET http://169.254.169.254/latest/meta-data/iam/security-credentials/<role> with a JSON document that contains long‑lived AWS access keys. IMDSv2 mitigates this risk by requiring a prior PUT request that returns a one‑time token, which must be presented on subsequent metadata calls. Because the IMDS version is selected at launch, the decision acts as a “severity multiplier” for any of the six URL‑accepting parameter types (webhook url/dest, import‑from‑URL file/target, PDF/screenshot renderers, avatar fetchers, link previewers, and OAuth callbacks) identified by OWASP API Top 10 (API7:2023).

Actionable hardening steps

• Enforce IMDSv2 at the hypervisor level. Include the required metadata options in the launch configuration so that every new instance defaults to HttpTokens=required. Example AWS CLI command for an existing instance:

  aws ec2 modify-instance-metadata-options \
  --instance-id i-0123456789abcdef0 \
  --http-tokens required \
  --http-put-response-hop-limit 1

  The hop‑limit of 1 blocks redirect chains that attempt to reach the metadata endpoint.
• Embed the same options in instance templates. Define a template that contains --metadata-options HttpTokens=required so that any EC2 instance created from the template inherits the protection automatically, eliminating post‑deployment remediation tickets.
• Audit existing EC2 workloads. Query the metadata configuration of all running instances:

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

  Any instance reporting optional or disabled is still using IMDSv1 and must be remediated.
• Enumerate vulnerable API parameters. Use the MAGO team tool (mago.team) to scan your services for the six URL‑accepting parameters and automatically test each against 169.254.169.254 with and without the IMDSv2 token header. The tool produces a concise report that can be fed into your CI/CD gate.

Integrating these controls aligns with compliance frameworks such as NIST SP 800‑53 (SC‑7) and ISO 27001 (A.12.5.1), which require protection of privileged credentials and regular vulnerability assessments. By enforcing IMDSv2 at launch, standardizing instance templates, and continuously auditing both infrastructure and API surface, engineers reduce the SSRF attack surface from critical credential theft to a lower‑severity information‑disclosure scenario.