Blocked by SSRF Migration: The Vulnerability Stalling Cloud Moves and Funding Ransomware Campaigns

Security teams are halting cloud migrations when SSRF vulnerabilities surface in the application inventory. That halt is costing organizations weeks of lost migration time. But the alternative — migrating without remediating — hands attackers a direct path to cloud credentials. This is the landscape in 2026, and it is getting sharper.

Picture a security engineering team three weeks into a high-priority cloud migration. Applications are moving from on-premises servers to AWS. Architecture reviews are done. IAM roles are configured. Egress controls are in place. Then a routine vulnerability scan flags a server-side request forgery condition embedded in a legacy web application that is part of the migration payload. The migration halts. Engineers scramble. The go-live date slips.

This scenario is not hypothetical. Across enterprise cloud programs in 2025 and into 2026, SSRF vulnerabilities became one of the primary blockers of cloud migration timelines — not because they are new, but because cloud environments transform what was once a medium-severity application bug into a critical infrastructure threat. According to IBM X-Force's analysis of the 2025 cloud threat landscape, more than 60% of enterprise cloud incidents stemmed not from provider vulnerabilities but from customer misconfigurations, compliance lapses, and poor migration governance.

What SSRF Does in a Cloud Environment

Server-Side Request Forgery is a vulnerability class in which an attacker tricks a server-side application into making HTTP requests to an unintended destination. The server acts as an unwilling proxy, forwarding requests to internal systems the attacker cannot reach directly. In a traditional on-premises environment, the blast radius is bounded: the attacker might reach another internal host, scan ports, or access an administrative interface.

In a cloud environment, the calculus changes entirely. Cloud providers expose internal metadata services — AWS at 169.254.169.254, Azure at 169.254.169.254/metadata, and GCP at metadata.google.internal — that are accessible to any process running on the host. These services deliver temporary IAM credentials, configuration data, and instance identity documents on request. They are intentionally available to trusted workloads. They become catastrophically dangerous when reachable through an SSRF vulnerability.

When a web application running on an EC2 instance is SSRF-vulnerable, an attacker can cause it to fetch the AWS Instance Metadata Service endpoint at /latest/meta-data/iam/security-credentials/ and return the temporary access key, secret key, and session token tied to the instance's IAM role. In the MITRE ATT&CK framework, this maps directly to T1552.005 (Unsecured Credentials: Cloud Instance Metadata API). With those credentials, the attacker can interact with AWS APIs — reading S3 buckets (T1530), launching instances, modifying security groups, escalating to administrative access (T1078.004) — without ever touching the instance itself.

The 2019 Capital One breach, which exposed over 106 million customer records, was caused by exactly this chain. A misconfigured web application firewall in front of AWS infrastructure allowed an attacker to exploit an SSRF condition and retrieve IAM credentials from the IMDS. That single incident triggered the development of IMDSv2 and remains the canonical reference point for SSRF risk in cloud environments.

According to Vectra AI's February 2026 analysis, SSRF attacks increased by 452% between 2023 and 2024, a surge they attribute largely to AI-powered automation lowering the barrier to entry for attackers who previously lacked the expertise to exploit these vulnerabilities at scale. — Vectra AI, Server-Side Request Forgery: Attacks & Prevention (February 2026)

At Sweet Security, 80% of customers reported experiencing SSRF attack attempts in their cloud environments, according to a Cloud Security Alliance report. SSRF reached number 10 on the OWASP Top 10 2021 list — and ranked first in the community survey that led to its inclusion, reflecting the security community's own assessment of its growing prevalence.

The IMDSv2 Migration That Millions Have Not Finished

AWS introduced the Instance Metadata Service Version 2 (IMDSv2) in November 2019. IMDSv2 replaces the stateless GET-based access pattern of IMDSv1 with a session-oriented model: to get a metadata token, a caller must first issue a PUT request with a custom header (X-aws-ec2-metadata-token-ttl-seconds). That token must then accompany every subsequent metadata request. Session tokens expire within six hours and cannot be forwarded across network hops.

The security improvement is significant. Because SSRF vulnerabilities typically allow control of the destination URL but not the HTTP method or custom headers, the PUT-plus-header requirement blocks the vast majority of SSRF-based credential theft. AWS's own analysis confirmed that this combination — a session token initiated by a PUT, with a default TTL of 1 on the PUT response packet — protects against misconfigured proxies, open reverse proxies, and most known SSRF vulnerability classes.

The technical act of enforcing IMDSv2 on a single instance is a single API call: aws ec2 modify-instance-metadata-options --instance-id i-xxx --http-tokens required. The organizational reality across a large fleet is more complex. Applications, agents, and third-party tools written before IMDSv2 may rely on IMDSv1 behavior — simple unauthenticated GET requests to the metadata endpoint. Disabling IMDSv1 on a host where a legacy application still depends on it will break that application, sometimes silently.

Datadog Security Labs, in their December 2024 analysis of the migration path, noted that the transition from IMDSv1 to IMDSv2 presents significant operational challenges in large distributed environments, particularly around gaining full visibility into which instances and workloads still depend on the legacy metadata protocol. AWS provides detection tooling to help: the CloudWatch MetadataNoToken metric identifies instances still making IMDSv1 calls; the aws-imds-packet-analyzer tool uses eBPF to identify specific processes making those calls; and CloudTrail's ec2RoleDelivery property pinpoints which IAM roles are still receiving IMDSv1-derived credentials.

In March 2024, AWS introduced regional-level defaults via modify-instance-metadata-defaults, allowing organizations to require IMDSv2 for all new instances in a region without touching existing ones. Amazon Linux 2023 ships with IMDSv1 disabled by default. These are meaningful advances — but the installed base of pre-2023 instances and legacy tooling means enforcement remains a staged, multi-account project for many organizations.

Enforcement can be applied at three levels: the individual instance, the Auto Scaling group, or across an organizational unit via AWS Service Control Policies. SCPs are particularly powerful: they can block the creation of any EC2 instance that still supports IMDSv1, and prevent IMDSv1-derived credentials from accessing AWS APIs at all. Datadog Security Labs recommends SCPs as the final enforcement layer after detection and application remediation are confirmed complete.

# Enforce IMDSv2 on a running instance (no restart required)
aws ec2 modify-instance-metadata-options \
  --instance-id i-0123456789abcdef0 \
  --http-tokens required \
  --http-endpoint enabled

# Set IMDSv2 as default for all new instances in a region
aws ec2 modify-instance-metadata-defaults \
  --http-tokens required

The 2025 Surge: Coordinated, Not Random

March 9, 2025 marked what GreyNoise Intelligence described as a coordinated surge in SSRF exploitation across multiple widely-used platforms. GreyNoise observed approximately 400 unique IP addresses actively exploiting 10 different SSRF-related CVEs simultaneously. The firm characterized the pattern as structured exploitation rather than routine botnet noise: the same IPs were targeting multiple CVEs in parallel, suggesting automation or pre-compromise intelligence. The top target countries included the United States, Germany, Singapore, India, and Japan, with early activity traced back to Israel as far as January 2025.

Preceding the March surge, GreyNoise detected Grafana path traversal attempts from the same IP ranges — a signal that attackers were conducting multi-phase reconnaissance before escalating to SSRF exploitation. That sequencing aligns with a pattern Fortinet's threat intelligence team had documented separately: a significant uptick in AWS instance credential compromises tied to Grafana SSRF attacks leveraging CVE-2020-13379, a three-year-old SSRF vulnerability in Grafana versions 3.0.1 through 7.0.2. Fortinet's telemetry showed approximately 14% of monitored Grafana installations fell within the affected version range — a substantial attack surface when projected across global cloud infrastructure.

IBM X-Force's 2026 Threat Intelligence Index found that threat actors in 2025 moved away from targeting hardened endpoints and instead focused on exploiting foundational open-source ecosystems and cloud infrastructure at the platform level. — IBM X-Force Threat Intelligence Index 2026

F5 Labs separately documented a four-day campaign in March 2025 specifically targeting EC2 instance metadata through SSRF against websites hosted in AWS. The campaign was not tied to a specific CVE — it exploited the gap between organizations that had completed the IMDSv1-to-IMDSv2 migration and those that had not. F5's analysis was direct: the single most effective remediation is migrating from IMDSv1 to IMDSv2, because requiring a secret token via a custom header eliminates the metadata exposure path that SSRF exploits depend on.

Wiz researchers documented a separate case in 2025 involving CVE-2025-51591 (CVSS 6.5), a vulnerability in Pandoc's HTML document processing that stems from Pandoc rendering <iframe> tags without restriction. Attackers submitted HTML documents containing iframe elements whose src attributes targeted the AWS IMDS endpoint at 169.254.169.254, targeting sensitive paths including /latest/meta-data/iam/info to harvest IAM credentials. Wiz observed exploitation attempts dating back to August 2025. In the specific incident Wiz analyzed, the attack was neutralized because the target had enforced IMDSv2 — the iframe-initiated GET request could not produce a valid session token. That outcome illustrates the enforced-IMDSv2 defense working exactly as designed. As Wiz researchers Hila Ramati and Gili Tikochinski explained, any application that can reach the IMDS endpoint and carries an SSRF flaw gives attackers a path to harvest temporary credentials without requiring direct access to the host itself.

CVE-2025-61882 and the Cl0p Escalation

October 2025 brought a higher-profile demonstration of what SSRF looks like when combined with pre-authentication exploitation and chained with additional vulnerabilities. CVE-2025-61882, a critical SSRF vulnerability in Oracle E-Business Suite versions 12.2.3 through 12.2.14, scored 9.8 on the CVSS scale. According to Google Cloud's Mandiant Threat Intelligence (GTIG), the Cl0p ransomware group — tracked by different vendors as TA505, FIN11, and Graceful Spider — had been exploiting this vulnerability as a zero-day with suspicious activity tracing back to July 10, 2025, and confirmed compromise by August 9, 2025, more than eight weeks before Oracle's public disclosure. Oracle released an emergency out-of-cycle patch on October 4, 2025. CISA added CVE-2025-61882 to its Known Exploited Vulnerabilities catalog on October 6, 2025. A companion vulnerability, CVE-2025-61884, affecting the Oracle Configurator component, was disclosed on October 11, 2025 as part of the same exploit chain.

The vulnerability allowed unauthenticated attackers to chain SSRF with CRLF injection, authentication bypass, and unsafe XSLT processing to achieve remote code execution — all without valid credentials. The attack sequence works as follows: a specially crafted HTTP request to the vulnerable UiServlet endpoint causes the EBS server to fetch an attacker-controlled XSL stylesheet via SSRF; that stylesheet uses Java reflection to execute shell commands, establishing a reverse shell back to attacker infrastructure. Vectra AI's February 2026 analysis described the campaign as a turning point in how organized threat actors weaponize server-side request forgery, noting that Fortune 500 organizations were affected globally.

The Cl0p campaign demonstrated something security teams need to internalize: SSRF is no longer primarily an opportunistic vulnerability exploited by general scanning. It is now a deliberate first-stage capability in ransomware deployment chains, actively researched and weaponized by organized threat actors operating on coordinated timelines.

Azure, a Perfect CVSS Score, and Tenant Boundary Crossing

AWS is not the only cloud platform carrying SSRF risk at the infrastructure level. CVE-2025-53767, disclosed during Microsoft's August 2025 Patch Tuesday (August 12, 2025), received a CVSS score of 10.0 — a perfect score reflecting low attack complexity, no authentication requirement, and a Scope:Changed designation meaning the vulnerability crosses security boundaries beyond the vulnerable component itself. The flaw, classified as CWE-918, stems from insufficient validation of user-supplied input in Azure OpenAI services, enabling crafted requests to reach internal endpoints including the Azure Instance Metadata Service and exposing access tokens. With those tokens, an attacker could potentially escalate privileges and access Azure resources across service boundaries, including Azure Resource Manager, Key Vault secrets, storage accounts, and connected services.

Microsoft patched the vulnerability, but Vectra AI's analysis observed that the incident exposed systemic architectural risks in cloud service platforms that no single patch can resolve. Azure managed identity tokens are functionally equivalent to the AWS IAM credentials exposed through IMDS: short-lived, high-privilege, and trusted by downstream services. An attacker who retrieves them through SSRF can interact with cloud control planes using credentials that appear entirely legitimate, bypassing signature-based detection that looks for known-bad indicators rather than unusual-but-authenticated API patterns.

SSRF in Containers and Kubernetes Environments

The article's discussion of SSRF risk has, until now, centered on traditional EC2 instances and IAM roles. But containerized and Kubernetes-native workloads introduce a separate credential exposure surface that is equally dangerous and, in many organizations, less well-understood.

In Kubernetes, every pod can be assigned a service account. That service account's token is mounted at a predictable path: /var/run/secrets/kubernetes.io/serviceaccount/token. An SSRF vulnerability in a containerized application can be used to reach the Kubernetes API server directly, leveraging the pod's service account token to query secrets, list namespaces, or create new workloads — actions that map to T1552.007 (Container API). If the service account has overly broad ClusterRole bindings, the blast radius extends across the entire cluster.

The metadata endpoint problem persists here as well. Pods running on cloud-hosted Kubernetes nodes (EKS, AKS, GKE) can still reach the cloud provider's IMDS endpoint at 169.254.169.254 unless network policies or node-level configurations block it. On AWS EKS, the --disable-pod-imds flag and the Amazon VPC CNI plugin's AWS_EC2_METADATA_DISABLED environment variable can restrict IMDS access at the pod level. On GKE, Workload Identity replaces node-level credentials with per-pod identity tokens that are scoped and time-limited. On AKS, Azure Workload Identity serves an analogous function.

The risk compounds in environments where Kubernetes namespaces are used as trust boundaries without network policies to enforce isolation. A compromised pod in one namespace can, through SSRF, reach services in other namespaces that assume internal traffic is trusted. Lateral movement in this context — mapped to T1210 (Exploitation of Remote Services) — is often invisible to perimeter-focused monitoring because it never crosses the cluster boundary.

DNS Rebinding, Protocol Smuggling, and Bypass Techniques

IMDSv2 and URL allowlisting are necessary controls, but they are not universally sufficient. Attackers have developed techniques specifically designed to evade SSRF protections, and security teams evaluating their remediation posture need to understand where gaps remain.

DNS rebinding attacks exploit the gap between hostname validation and DNS resolution. An application may validate that a user-supplied URL resolves to a permitted external host at the time of the check. But DNS records can change between the validation step and the actual HTTP request. An attacker who controls a DNS server can return a legitimate IP during validation and then switch to 169.254.169.254 when the application actually fetches the resource. This bypasses hostname-based allowlists entirely. The mitigation requires resolving the hostname and then validating the resulting IP address — not the hostname — immediately before the request is issued, with no caching in between.

Protocol smuggling exploits applications that do not restrict URL schemes. If an application accepts gopher://, file://, or dict:// schemes, attackers can use them to interact with internal services in ways that HTTP-only protections do not anticipate. The gopher:// protocol is particularly dangerous because it allows arbitrary TCP data to be sent, enabling attackers to interact with services like Redis, Memcached, or SMTP servers that operate on internal networks without authentication. Effective SSRF prevention must restrict URL schemes to http and https only.

Redirect-based bypasses chain SSRF with open redirect vulnerabilities. An application's allowlist may permit requests to a trusted external domain. If that domain contains an open redirect, the attacker can use it to bounce the request to an internal endpoint. The application sees a permitted destination; the actual request lands on the metadata service. This is why OWASP's guidance emphasizes following zero redirects in SSRF-susceptible contexts, or re-validating the destination after every redirect hop.

Encoding and obfuscation techniques target pattern-matching defenses. IP addresses can be represented in decimal (2852039166 for 169.254.169.254), hexadecimal (0xA9FEA9FE), octal, or IPv6 notation. URL encoding, double encoding, and mixed-case variations can evade signature-based WAF rules. Base64-encoded payloads embedded in non-standard headers like Referer have been observed bypassing WAFs that primarily inspect URL parameters and form data. These bypass techniques reinforce why deny-list approaches to SSRF prevention fail: the encoding space is unbounded, and any approach that attempts to enumerate bad inputs will be outpaced by attacker creativity.

SSRF in AI and LLM-Integrated Services

The rapid adoption of AI and large language model services has introduced a new and expanding SSRF attack surface. LLM-integrated applications routinely fetch external resources on behalf of users — retrieving web pages for summarization, processing document URLs, executing tool calls, or loading data from user-specified endpoints. Each of these interactions represents a potential SSRF vector if input validation is not enforced at the application layer.

CVE-2024-6587, which appeared in the March 2025 GreyNoise surge data, targeted BerriAI's LiteLLM — an open-source proxy layer used to route API requests across multiple LLM providers. The SSRF vulnerability in LiteLLM's proxy endpoint allowed attackers to redirect requests to internal services, including cloud metadata endpoints. LiteLLM's architecture runs alongside the AI models it proxies, meaning a successful SSRF exploit inherits whatever cloud permissions the proxy service itself holds.

CVE-2025-53767, the CVSS 10.0 vulnerability in Azure OpenAI discussed earlier, demonstrated the same principle at platform scale. Cloudflare's WAF changelog documented ongoing advancements in SSRF payload techniques throughout 2025, including obfuscation patterns specifically targeting cloud metadata services in AI workloads. AnythingLLM, another widely-deployed open-source LLM platform, carried CVE-2024-0759 — an SSRF flaw that allowed attackers to force the LLM backend into making unauthorized internal network requests.

The OWASP Top 10 for LLM Applications (2025 edition) includes SSRF as a distinct risk category for LLM-integrated systems. The concern is structural: LLMs are designed to process and act on user-supplied input, and many LLM application architectures deliberately grant the model access to external resources. Defending against SSRF in this context requires treating every model-initiated outbound request with the same suspicion as a user-initiated one — enforcing allowlists, validating resolved IPs, restricting URL schemes, and applying network-level egress controls to the compute layer running the model.

Detecting SSRF Exploitation in Progress

Remediating SSRF at the code level and enforcing IMDSv2 are preventive controls. But prevention alone is incomplete without the ability to detect exploitation attempts — both to catch attacks that bypass preventive layers and to build organizational awareness of active targeting patterns.

At the application layer, SSRF detection starts with monitoring outbound HTTP requests initiated by the application. Any request from a web server to a link-local address range (169.254.0.0/16), a private IP range (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), or localhost that was triggered by user-supplied input is a high-confidence indicator. Datadog's Application and API Protection (AAP) documents detection rules that flag requests containing metadata URLs like 169.254.169.254 in POST request bodies, URL parameters, or HTTP headers. Application-layer security tools that inspect request traces can identify these patterns more effectively than perimeter WAFs, which see inbound traffic but not the subsequent server-initiated requests that characterize SSRF.

At the infrastructure layer on AWS, the CloudWatch metric MetadataNoToken identifies instances making IMDSv1 calls — which, after IMDSv2 enforcement is underway, are either misconfigured applications or active exploitation. CloudTrail logs every metadata-derived credential usage through the ec2RoleDelivery field: a value of 1.0 indicates IMDSv1 was used to obtain the credentials. VPC Flow Logs can flag traffic from application subnets to 169.254.169.254 that does not match expected metadata access patterns. On Kubernetes, audit logs from the API server can detect unexpected service account token usage — particularly requests from pods that do not normally interact with the Kubernetes API.

At the behavioral layer, the strongest signal is unusual API activity from credentials that were issued to EC2 instances or pods. If IAM credentials tied to a web server instance are suddenly used to list S3 buckets, enumerate IAM policies, or call sts:GetCallerIdentity from an IP address outside the VPC, that pattern is consistent with credential exfiltration via SSRF followed by off-instance usage (T1078.004). AWS GuardDuty and third-party CSPM tools can correlate these signals, but only if CloudTrail logging is enabled across all accounts and regions — a prerequisite that, like IMDSv2, is straightforward in principle and frequently incomplete in practice.

What the Migration Block Looks Like

Against this backdrop, the operational decision to halt a cloud migration when SSRF surfaces is rational. An application carrying an SSRF vulnerability in an on-premises environment is a contained problem. The same application deployed on a cloud instance with an IAM role attached becomes a potential credential source for the entire cloud account. IBM X-Force's 2025 analysis of cloud threat actor behavior found a clear directional shift: attackers moved away from attacking hardened endpoints and toward deliberately targeting cloud-adjacent identity and integration layers — the precise attack surface that SSRF-plus-IMDS exploitation represents.

Qualys's January 2026 serverless security analysis captured the risk compounding in modern architectures: security exposure multiplies through interconnected services, shared roles, and reused dependencies, converting what appear to be isolated weaknesses into organization-wide vulnerabilities. In a serverless environment where Lambda functions carry broad IAM permissions and interact with internal services, a single SSRF vulnerability in a function that accepts user-supplied URLs can give an attacker access to every AWS service the function's role can reach — without the attacker ever touching the function's code.

The migration block is not, therefore, an overreaction. It is recognition that the threat model changes fundamentally at cloud migration time. Organizations that move SSRF-vulnerable applications into cloud environments without remediating first are transferring an on-premises bug into a platform where it becomes an identity-layer vulnerability with cloud-wide blast radius.

The remediation path for applications is well-defined. OWASP's SSRF prevention guidance recommends allowlisting outbound destinations rather than blocklisting — deny-lists are bypass-prone. Input validation should enforce URL scheme, hostname, and port restrictions at the HTTP client level, not only in application logic. DNS resolution should be validated after hostname allowlisting to confirm that allowed hostnames do not resolve to private or link-local address ranges. Network-level egress filtering should back application controls as a defense-in-depth layer. For AWS infrastructure specifically, migrating to IMDSv2 and disabling IMDSv1 is, as Java Code Geeks emphasized in their November 2025 AWS migration security guide, the single most impactful step an organization can take — a straightforward change that eliminates one of the largest remaining attack vectors.

MITRE ATT&CK Mapping: SSRF Across the Kill Chain

SSRF-based cloud attacks do not map to a single MITRE ATT&CK technique. They chain across multiple tactics, from initial access through exfiltration or impact. The following table maps each stage of the SSRF-to-cloud-compromise chain to its corresponding ATT&CK technique, providing security teams with a framework for building detection coverage at every stage rather than relying on a single control.

Attack Stage	MITRE ATT&CK Technique	SSRF Context
Reconnaissance	T1595.002 — Vulnerability Scanning	Automated scanning of SSRF-prone endpoints (e.g., Grafana path traversal before the March 2025 surge)
Initial Access	T1190 — Exploit Public-Facing Application	SSRF payload delivery to vulnerable web applications, APIs, or LLM proxy endpoints
Credential Access	T1552.005 — Cloud Instance Metadata API	Fetching IAM credentials from IMDS at 169.254.169.254 via the SSRF-compromised application
Credential Access	T1552.007 — Container API	Accessing Kubernetes service account tokens or secrets via SSRF in containerized workloads
Valid Credentials	T1078.004 — Cloud Accounts	Using stolen IAM or managed identity tokens to authenticate as a legitimate cloud principal
Execution	T1059 — Command and Scripting Interpreter	Chaining SSRF with XSLT injection or deserialization for RCE (e.g., CVE-2025-61882)
Discovery	T1046 — Network Service Discovery	Using SSRF to probe internal services, port scan, or enumerate internal network topology
Lateral Movement	T1210 — Exploitation of Remote Services	Pivoting from SSRF foothold to internal services (Redis, Memcached, Kubernetes API) without authentication
Collection	T1530 — Data from Cloud Storage	Using stolen cloud credentials to access S3 buckets, Azure Blob Storage, or GCS objects
Exfiltration	T1567.002 — Exfiltration to Cloud Storage	Moving harvested data to attacker-controlled cloud storage using the victim's own API credentials
Impact	T1486 — Data Encrypted for Impact	Ransomware deployment after SSRF-enabled initial access (e.g., Cl0p campaign via CVE-2025-61882)

Each row in this table represents a detection opportunity. Organizations that build alerting around only the initial access stage — blocking known SSRF payloads at the WAF — miss the credential theft, lateral movement, and exfiltration stages that follow when prevention fails. The strongest detection posture monitors for anomalous IMDS access patterns (T1552.005), unexpected cloud API activity from instance-bound credentials (T1078.004), and unusual data access in cloud storage services (T1530) simultaneously.

Key Takeaways

1. SSRF is a cloud-tier threat, not just an application bug. On-premises, SSRF is a lateral movement risk. In cloud environments with attached IAM roles, it is a full account-compromise path (T1552.005). The threat model changes at migration time, and security posture must change with it.
2. The IMDSv2 migration is the single highest-impact control available on AWS. Enforcing IMDSv2 and disabling IMDSv1 eliminates the metadata credential-theft vector that enabled the Capital One breach and that the March 2025 coordinated exploitation campaign targeted. According to Palo Alto Networks' Unit 42 data, 55% of organizations have not completed this migration.
3. The 2025 SSRF surge was structured, not opportunistic. GreyNoise's documentation of 400 IPs simultaneously targeting 10 CVEs, preceded by Grafana reconnaissance (T1595.002), reflects organized automation and pre-compromise planning — not random scanning. SSRF is a deliberate capability in active attacker playbooks, including ransomware deployment chains.
4. Containers and Kubernetes extend the SSRF blast radius beyond EC2. SSRF in containerized workloads can reach Kubernetes API servers, pod service account tokens (T1552.007), and cross-namespace services. EKS, GKE, and AKS each require platform-specific controls to restrict IMDS access at the pod level.
5. DNS rebinding and protocol smuggling can bypass IMDSv2 and allowlists. Hostname validation alone is insufficient. SSRF defenses must validate resolved IP addresses at request time, restrict URL schemes to HTTP/HTTPS, follow zero redirects in sensitive contexts, and treat all user-supplied URLs as untrusted regardless of apparent domain.
6. AI and LLM services are a rapidly expanding SSRF attack surface. LLM-integrated applications that fetch external resources on behalf of users carry inherent SSRF risk. CVE-2024-6587 (LiteLLM), CVE-2024-0759 (AnythingLLM), and CVE-2025-53767 (Azure OpenAI) demonstrate that this is not theoretical — it is actively exploited.
7. Blocking a migration for SSRF remediation is the correct call. Organizations that migrate SSRF-vulnerable applications into cloud environments before remediation are expanding a contained application risk into a cloud-wide identity-layer exposure. The temporary delay imposed by remediation is the right trade.
8. Detection must cover the full MITRE ATT&CK chain, not just initial access. WAF-based SSRF blocking addresses only T1190. Organizations need detection at the credential access (T1552.005), valid accounts (T1078.004), and cloud storage access (T1530) stages to catch attacks that bypass perimeter controls.
9. Defense-in-depth is required because no single control is sufficient. IMDSv2 enforcement, allowlist-based URL validation, network-level egress filtering, least-privilege IAM scoping, and behavioral monitoring at the IMDS query level must all be in place. As OWASP notes in its SSRF prevention guidance, deny-lists are bypass-prone — relying on any single layer will leave gaps that determined attackers will find.

The phrase "blocked by SSRF migration" will keep appearing in incident timelines and project retrospectives as long as SSRF-vulnerable applications are being moved into cloud environments where IAM credentials are a GET request away. The fix exists. The tooling exists. The enforcement mechanisms exist. What is missing, in the organizations that remain exposed, is the organizational priority to complete a migration that started in 2019 and is still unfinished in 2026.

Sources

• Vectra AI — Server-Side Request Forgery: Attacks & Prevention (February 2026)
• IBM X-Force Threat Intelligence Index 2026 — Cloud Attacks Are Evolving
• GreyNoise Intelligence — New SSRF Exploitation Surge (March 2025)
• F5 Labs — Campaign Targets Amazon EC2 Instance Metadata via SSRF (April 2025)
• Qualys — Serverless Security Risks 2026: Mitigating Identity & SSRF RCE Threats
• Datadog Security Labs — From Detection to Enforcement: Migrating from IMDSv1 to IMDSv2
• AWS Security Blog — Defense in Depth Against SSRF Vulnerabilities with IMDSv2
• Fortinet — AWS Credential Compromises Tied to Grafana SSRF Attacks
• Wiz — IMDS Abused: Hunting Rare Behaviors to Uncover Exploits (September 2025)
• Cloud Security Alliance — Defending Against SSRF Attacks in Cloud Native Applications
• OWASP — Server Side Request Forgery Prevention Cheat Sheet
• Java Code Geeks — AWS Migration Challenges and Security Vulnerabilities (November 2025)
• MITRE ATT&CK — T1190: Exploit Public-Facing Application
• MITRE ATT&CK — T1552.005: Unsecured Credentials: Cloud Instance Metadata API
• MITRE ATT&CK — T1078.004: Valid Accounts: Cloud Accounts
• Datadog — Detect SSRF Attacks in Cloud Applications and APIs (April 2025)
• Cloudflare WAF Changelog — SSRF Generic and Obfuscated Payloads (June 2025)