SonicWall's 2025 Cyber Threat Report documented a 452% increase in SSRF attacks between 2023 and 2024. In October 2025, the Cl0p ransomware group weaponized a critical SSRF vulnerability in Oracle E-Business Suite against Fortune 500 companies. And the breach that proved SSRF could be catastrophic — the 2019 Capital One incident that exposed over 100 million customer records — exploited a vulnerability class that many organizations still don't test for. SSRF is the cloud era's most dangerous underestimated threat.
SSRF occupies a unique position in the vulnerability landscape. It's technically simple to understand, devastating in cloud environments, and persistently overlooked by development teams who don't realize that a feature accepting URLs from users is a potential gateway to their entire internal infrastructure. Every microservice that fetches an external resource, every image preview generator, every webhook endpoint, and every link unfurling feature is a potential SSRF attack surface. In cloud-native architectures, that attack surface includes the keys to the kingdom: cloud metadata services that hand out IAM credentials to anyone who asks from the right IP address.
What SSRF Is and Why Cloud Makes It Lethal
Server-Side Request Forgery occurs when an attacker tricks a server into making HTTP requests to destinations the attacker chooses. The server, trusting its own network context, can reach internal services, cloud metadata endpoints, and backend systems that are completely invisible to the outside world. The attacker weaponizes the server's network position and trust relationships against the organization.
In pre-cloud environments, SSRF was concerning but limited. An attacker might scan internal ports or access an internal admin panel. In cloud environments, SSRF becomes catastrophic because of a single architectural feature: the cloud metadata service.
Every major cloud provider (AWS, GCP, Azure, DigitalOcean) runs a metadata service accessible from any virtual machine instance at a well-known IP address — typically 169.254.169.254. This service provides configuration data, network information, and critically, temporary IAM credentials for whatever role is assigned to the instance. A simple HTTP GET request from inside the instance returns credentials that can access S3 buckets, databases, and any other cloud service the role permits.
The metadata service requires no authentication by default. If an SSRF vulnerability allows an attacker to make the server request http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE-NAME, they receive working cloud credentials. That's the entire attack. No exploitation chain, no privilege escalation — just one HTTP request and you have the keys.
"My rule of thumb is that anywhere a hostname or IP address is accepted as user-input, there is a 50 percent chance that SSRF is possible and an attacker could potentially make requests to the metadata service." — Evan Johnson, Product Security, Cloudflare, writing on his personal blog about the Capital One breach, August 2019
The Capital One Breach: SSRF's Defining Moment
The 2019 Capital One breach remains the defining SSRF case study. A former AWS employee, Paige Thompson, exploited an SSRF vulnerability in a misconfigured web application firewall (WAF) running on an EC2 instance. The SSRF allowed her to query the AWS metadata service and retrieve temporary IAM credentials for a role called "ISRM-WAF-Role." That role had excessive permissions, including access to S3 buckets containing customer data.
The result: over 100 million customer records exposed, including 1 million Canadian social insurance numbers, 140,000 U.S. Social Security numbers, and 80,000 bank account numbers. Capital One paid over $190 million in settlements and regulatory penalties.
CloudSploit's post-breach analysis identified the core problem as a two-step failure: the SSRF vulnerability exposed IAM credentials, and the IAM role had far more permissions than it needed. As CloudSploit noted at the time, IAM role misconfigurations of this type are "likely present in nearly every single AWS account" because developers routinely use wildcard permissions rather than carefully scoping each role to its minimum required access.
The breach forced AWS to accelerate the rollout of IMDSv2, a hardened version of the metadata service that requires a token obtained via an HTTP PUT request before credentials are released. IMDSv2 mitigates basic SSRF attacks where the attacker controls only the URL destination but can't add custom headers. However, adoption has been slow, and many organizations still run instances with IMDSv1 enabled.
The 2025 Explosion: Cl0p, Oracle, and Zimbra
SSRF went from a specialist concern to a frontline ransomware weapon in 2025. In October, CrowdStrike's threat intelligence team confirmed that the Cl0p ransomware group (tracked as Graceful Spider) had been exploiting CVE-2025-61882, a critical SSRF vulnerability in Oracle E-Business Suite (EBS) versions 12.2.3 through 12.2.14, since at least August 2025. The vulnerability scored 9.8 on the CVSS scale and allowed pre-authenticated attackers to chain SSRF with CRLF injection, authentication bypass, and unsafe XSLT processing to achieve remote code execution.
Cl0p's exploitation of Oracle EBS represented a tactical evolution: using SSRF as the entry point of a multi-stage attack chain that ultimately deployed ransomware against Fortune 500 targets. The attack didn't require traditional ransomware encryption in all cases — Cl0p's model increasingly focuses on data theft and extortion, making SSRF's ability to access internal data stores directly valuable.
Separately, Zimbra's email collaboration platform suffered CVE-2025-25065, an SSRF vulnerability in its RSS feed proxy feature that allowed attackers to access internal services by manipulating feed URLs. Given Zimbra's widespread deployment across business environments, the vulnerability created immediate risk for thousands of organizations.
How SSRF Attacks Work in Practice
SSRF exploits target any server-side functionality that accepts a URL as input and fetches data from it. Common attack surfaces include image/file preview generators, webhook delivery systems, URL shorteners, link unfurling in chat applications, PDF renderers, and any integration that fetches data from user-specified endpoints.
The simplest SSRF attack modifies a URL parameter to point at an internal resource:
# Intended use: fetch external image preview
GET /api/preview?url=https://example.com/image.png
# SSRF attack: access cloud metadata
GET /api/preview?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/When filters exist, attackers employ bypass techniques including decimal IP notation (http://2130706433/ resolves to 127.0.0.1), IPv6 representations, DNS rebinding (configuring a domain to initially resolve to an allowed IP, then resolve to an internal IP on the second request), URL encoding, and redirect chains through attacker-controlled servers.
Blind SSRF — where the attacker doesn't receive the server's response directly — is exploited using out-of-band techniques. The attacker directs the server to connect to an external endpoint they control and observes the incoming request, which may contain sensitive data in headers, query parameters, or the request itself confirms that the server can reach internal resources.
Why Traditional Defenses Fail Against SSRF
SSRF exploits the fundamental trust relationship between a server and its internal network. Client-side protections like Content Security Policy, browser sandboxing, and CORS headers provide zero defense because the malicious request originates from the server, not the browser. Firewalls designed to block inbound traffic are irrelevant because the SSRF request is outbound from a trusted internal host. Web Application Firewalls can catch known patterns (like requests to 169.254.169.254) but struggle with the dozens of bypass techniques available to attackers.
The microservices architecture that defines modern cloud applications makes the problem worse. Each internal service trusts requests from other internal services by default. When an SSRF vulnerability turns a public-facing server into an attacker-controlled proxy, every internal API, database endpoint, and management interface becomes accessible.
How to Defend Against SSRF
- Enforce IMDSv2 on all cloud instances. For AWS, set
HttpTokens=requiredon every EC2 instance. This forces the use of session tokens for metadata access, which dramatically reduces SSRF impact when the attacker can only control the URL destination. Google Cloud Platform enforces a custom header (Metadata-Flavor: Google) by default. Ensure your cloud provider's equivalent protections are active. - Validate and restrict user-supplied URLs. Maintain an allowlist of permitted destination domains and protocols. Reject
file://,ftp://,gopher://, and any non-HTTP/HTTPS scheme. Resolve hostnames and verify the resulting IP is not in private ranges (10.x.x.x, 172.16-31.x.x, 192.168.x.x, 169.254.x.x, 127.x.x.x) before making the request. - Implement network segmentation. Web-facing application servers should not have direct network access to sensitive internal services, database management interfaces, or cloud management APIs. Use security groups and network ACLs to enforce least-privilege network access.
- Apply least-privilege IAM roles. Every EC2 instance, Lambda function, and container should have an IAM role scoped to the minimum permissions required. The Capital One breach was catastrophic because the WAF role had access to S3 buckets it didn't need. Wildcard permissions are an invitation to disaster.
- Disable unnecessary URL-fetching features. If your application doesn't need to fetch arbitrary URLs, don't build the functionality. If it needs to fetch from specific services, hardcode those destinations. The less user-controlled URL fetching your application performs, the smaller your SSRF attack surface.
- Monitor for SSRF indicators. Log and alert on outbound requests from application servers to metadata endpoints, private IP ranges, and unexpected internal services. Behavioral analysis can catch SSRF exploitation patterns that signature-based detection misses.
- Test specifically for SSRF. Include SSRF testing in your penetration testing scope. Many security assessments focus on XSS, SQLi, and authentication bypass while overlooking SSRF entirely. Given the 452% surge in attacks, this is no longer acceptable.
Key Takeaways
- SSRF is the cloud era's most dangerous vulnerability: A single SSRF bug can expose cloud IAM credentials, giving attackers access to entire cloud environments. The Capital One breach proved this at scale, and the 452% surge in attacks shows the threat is accelerating.
- Ransomware groups are weaponizing SSRF: Cl0p's exploitation of Oracle EBS SSRF against Fortune 500 targets in 2025 signals that SSRF is now a mainstream ransomware entry vector, not just a bug bounty finding.
- Cloud metadata services are the primary target: The metadata endpoint at
169.254.169.254is the single most valuable resource an SSRF attacker can reach. Enforce IMDSv2 (or equivalent) on every cloud instance immediately. - Traditional perimeter defenses don't help: SSRF exploits the server's own network position and trust relationships. Firewalls, browser security controls, and basic WAF rules are insufficient. Defense requires input validation, network segmentation, and IAM hardening.
- Any URL-fetching feature is an attack surface: Image previews, webhooks, link unfurling, RSS readers, PDF generators — if it accepts a URL and makes a server-side request, it's a potential SSRF vector. Audit every feature that fetches external resources.
SSRF has spent years being underestimated. It wasn't in the OWASP Top 10 when Capital One was breached. It was added in 2021 and consolidated under Broken Access Control in 2025. The security community's recognition has been slow, but the attackers haven't waited. With a 452% surge in attacks and ransomware groups actively weaponizing SSRF against enterprise targets, the era of treating this as a minor vulnerability is definitively over. If your organization runs cloud infrastructure and hasn't audited for SSRF, you're running on borrowed time.