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
F5 Labs documented a campaign in March 2025 that highlighted a critical vulnerability class: Server-Side Request Forgery (SSRF) in APIs. The attackers focused on six common parameter names that commonly accept URLs: url, dest, file, redirect, target, and uri. These parameters are ubiquitous in modern API development, often used for functionalities like webhook integrations, content fetching, or redirecting users. The sheer prevalence of these parameter types means a vast attack surface exists across countless production systems.
The probing campaign, which generated over 69,000 requests, targeted the internal IP address 169.254.169.254. This is the default IP address for the Instance Metadata Service (IMDS) on Amazon Web Services (AWS) and similar services on other cloud providers. The IMDS provides information about the running instance, including its configuration, network details, and, crucially, temporary security credentials. The fact that no zero-day exploits were used underscores the severity of the issue – it relies on fundamental design choices in API development and cloud deployment.
The IMDSv1/IMDSv2 Decision: The Severity Multiplier
The true danger of an SSRF vulnerability in an API is directly tied to the configuration of the cloud environment, specifically the version of the Instance Metadata Service being used. Cloud providers offer mechanisms for applications running on instances to retrieve metadata about the instance itself. This metadata can include sensitive information, such as IAM role credentials. There are typically two versions of this service: IMDSv1 and IMDSv2.
IMDSv1 is the older, simpler version. It allows unauthenticated access to instance metadata from within the instance. This means that if an attacker can trick an API running on the instance into making a request to 169.254.169.254, they can potentially retrieve sensitive data, including temporary credentials. These credentials can then be used to access other cloud resources, often with broad permissions, leading to full account compromise.
IMDSv2, on the other hand, introduces a crucial security enhancement: session-based authentication. To access metadata via IMDSv2, a client must first establish a session by making a specific request to the IMDS endpoint. This session requires a token that is obtained through an authenticated process. Consequently, an SSRF vulnerability alone cannot directly steal credentials when IMDSv2 is enforced. The attacker would first need to bypass the IMDSv2 session token requirement, which is a significantly harder task.
The decision to use IMDSv1 or IMDSv2 is made at the time the cloud instance is launched or configured. Many organizations, for reasons of convenience or legacy compatibility, may still be running instances with IMDSv1 enabled. This decision, made during the initial deployment, effectively sets an invisible severity multiplier for any SSRF vulnerability discovered within applications running on those instances. A medium-severity SSRF in an application becomes a critical, high-impact attack vector for credential theft if IMDSv1 is active.
The Attack Flow: From API Parameter to Cloud Credentials
The attack depicted by the F5 Labs campaign illustrates a straightforward yet potent attack chain. An attacker identifies an API endpoint that accepts one of the six vulnerable parameter types (url, dest, file, redirect, target, uri). Instead of providing a legitimate external URL, the attacker crafts a request that includes the internal IMDS endpoint: http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME (where ROLE_NAME is a placeholder for the actual role name, which can often be discovered through other metadata requests).
When the API processes this malicious input, it makes an outbound request to 169.254.169.254. If the instance is configured with IMDSv1, the API server will receive the request and return the instance's IAM role credentials. These credentials typically include an access key ID, secret access key, and a session token. With these credentials, the attacker can then impersonate the instance and access any AWS services that the associated IAM role has permissions for. This could range from reading sensitive data in S3 buckets to launching new instances or modifying network configurations, effectively giving them control over a significant portion of the cloud environment.
The campaign's scale (69,433 probes) indicates that attackers are actively scanning for and exploiting this vulnerability across the internet. The lack of sophisticated techniques suggests that this is a low-hanging fruit for attackers targeting cloud-hosted applications. Organizations that have not migrated to IMDSv2 or do not have robust SSRF defenses in place are at immediate risk.
Mitigation Strategies: Defense in Depth
Addressing this vulnerability requires a multi-layered approach, focusing on both API security and cloud infrastructure hardening. The most critical step is to enforce IMDSv2 for all cloud instances. This single change dramatically raises the bar for attackers attempting to exploit SSRF vulnerabilities for credential theft. Cloud security teams should audit their deployments to ensure IMDSv1 is disabled wherever possible.
For API developers, the primary mitigation is input validation. Treat any parameter that accepts a URL with extreme suspicion. Implement strict validation rules to ensure that only expected and safe URLs are accepted. This includes:
- Allowlisting: Only permit requests to known, trusted domains or IP addresses. Reject all others.
- Blocklisting: While less effective than allowlisting, block known internal IP addresses, including
169.254.169.254and private IP ranges (e.g.,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16). - Protocol Validation: Ensure that only HTTP or HTTPS protocols are used, and reject others like `file://`.
- URL Parsing: Use robust URL parsing libraries to dissect the URL components and validate them individually before constructing a new request.
Furthermore, network segmentation and firewall rules can add another layer of defense. By restricting outbound traffic from API servers to only necessary destinations, the ability of an SSRF vulnerability to reach sensitive internal endpoints like the IMDS can be curtailed. Web Application Firewalls (WAFs) can also be configured to detect and block common SSRF patterns, although they are not a foolproof solution against novel or well-obfuscated attacks.
The prevalence of these six parameter types means that a comprehensive security audit of all API endpoints is necessary. Developers should also consider implementing client-side validation where appropriate, although server-side validation remains paramount. The threat actor's broad, unauthenticated probes demonstrate that the attack surface is being actively enumerated. If your API accepts any form of URL input, it is a potential target for SSRF attacks, and the severity is dictated by your cloud's IMDS configuration.