What Is Server-Side Request Forgery (SSRF)?

Web server that fetches a URL on request is doing something ordinary, until an attacker chooses the URL. Server-side request forgery (SSRF) abuses exactly that feature, tricking a server into sending requests to destinations the attacker picks, from internal admin panels to cloud credential stores.

Because the request comes from the trusted server, it reaches places the public internet cannot. SSRF entered the OWASP Top 10 in 2021 as the only category chosen purely by community survey. In the cloud, a single SSRF flaw is enough to expose an entire account, as it did in the Capital One breach of 106 million records.

What is Server-Side Request Forgery (SSRF)?

Server-side request forgery is a web vulnerability that lets an attacker make a server send requests on their behalf to targets the attacker specifies. It turns a trusted server into an unwilling proxy, a confused deputy that carries out the attacker's instructions with its own privileges and network access.

That network position is the whole point. A server usually sits inside the perimeter, able to reach internal services, databases, and cloud metadata endpoints that block direct access from outside. SSRF borrows that reach, letting an outsider knock on internal doors through a server allowed to open them.

How Does SSRF Work?

SSRF exploits a common feature in three steps.

1. Vulnerable URL Handling

Many applications accept a URL from the user, for link previews, webhooks, document conversion, or image fetching, then request that URL server-side. When the application fetches it without validating the destination, the door opens.

2. Redirecting the Server

The attacker supplies a URL pointing somewhere unintended, an internal IP, localhost, or a cloud metadata address, instead of the expected external resource. The server, trusting its input, sends the request anyway.

3. Reaching Internal Targets

The request lands on a resource the attacker cannot reach directly. Depending on the target, the response leaks internal data, service details, or cloud credentials back through the vulnerable application.

A concrete example makes the pattern clear. A link-preview feature normally fetches the external page a user names:

https://example.com/page

An attacker instead supplies an internal address, and the trusting server fetches it and returns the result:

http://169.254.169.254/latest/meta-data/iam/security-credentials/

That single request pulls the temporary cloud credentials of the server's role straight back to the attacker.

Types of SSRF

SSRF varies by how much of the response the attacker sees:

1. In-band SSRF. The server returns the response of the forged request directly to the attacker, exposing internal data in full.
2. Blind SSRF. The response never comes back, so the attacker confirms the request through side effects such as an out-of-band callback to a server they control.
3. Semi-blind SSRF. Partial signals leak, like response timing or error messages, letting the attacker infer results without seeing the full body.

What Attackers Achieve with SSRF

A single SSRF flaw opens several attack paths:

• Cloud credential theft. Querying a cloud metadata endpoint to steal the temporary IAM credentials attached to the server's role.
• Internal reconnaissance. Port-scanning the internal network and mapping services that never face the internet.
• Service access. Reaching admin panels, databases, and management interfaces protected only by network location.
• Data exfiltration. Pulling files and secrets from internal storage and configuration endpoints.
• Remote code execution. Chaining SSRF into vulnerable internal services to run commands, in the most severe cases.

How far any of these reach depends on the vulnerable server's position and privileges. Finding which internet-facing apps and APIs accept URLs in the first place, through external vulnerability scanning, is what turns SSRF from an invisible risk into a fixable one.

Cloud Metadata Attacks and the Capital One Breach

SSRF became a cloud problem because of one address. Every major cloud provider runs an instance metadata service, reachable only from the machine itself at a fixed internal address such as 169.254.169.254. It hands out configuration and, critically, the temporary credentials for the identity role attached to the instance.

The 2019 Capital One breach followed that path exactly. An attacker exploited SSRF in a misconfigured web application firewall to reach the AWS metadata endpoint, retrieved the credentials of the firewall's over-privileged role, and used them to read storage buckets holding roughly 106 million customer records. As Krebs on Security detailed, no password was cracked; the server was simply persuaded to ask the metadata service for its own keys.

AWS answered with IMDSv2, which requires a session token obtained through a request that most SSRF cannot send. It hardens the metadata service without removing the underlying flaw, which is why SSRF stays dangerous wherever the older version remains enabled.

Notable SSRF Vulnerabilities

SSRF keeps surfacing in critical software, often chained into far worse outcomes:

• ProxyLogon (CVE-2021-26855). An unauthenticated SSRF flaw in Microsoft Exchange, rated CVSS 9.8, that let attackers issue internal requests as the server and, chained with other bugs, seize thousands of Exchange servers worldwide in 2021.
• Oracle E-Business Suite (CVE-2025-61882). A pre-authentication SSRF chained with CRLF injection and unsafe XSLT processing into remote code execution, rated CVSS 9.8. The Cl0p ransomware group exploited it as a zero-day from August 2025 to steal data from enterprise ERP systems.

Both share the SSRF fingerprint: a server persuaded to make a request it was never meant to make, against a target the attacker chose.

SSRF vs CSRF

SSRF and CSRF sound alike and get confused constantly, yet they target opposite sides of a web transaction.

In short, SSRF abuses the server's trusted network position, while CSRF abuses a site's trust in an already authenticated user.

SSRF Bypass Techniques

Naive defenses that blocklist internal addresses rarely hold, because attackers disguise the same destination in many ways:

• Alternate IP encodings. Writing 169.254.169.254 as a decimal, octal, or hexadecimal integer to slip past string-based blocklists.
• DNS rebinding. Pointing a domain at a safe address during validation, then re-resolving it to an internal address when the request fires.
• Open-redirect chaining. Passing an allowed external URL that redirects the server to an internal target.
• IPv6 and shorthand. Using IPv6 loopback, mapped addresses, or shortened forms that a blocklist of IPv4 strings misses.

SSRF in AI Systems and MCP Servers

AI infrastructure has become fresh ground for SSRF. Large language model applications, agent frameworks, and the Model Context Protocol (MCP) servers that connect AI to external tools constantly fetch URLs, call APIs, and process user-supplied content, the exact pattern SSRF abuses.

The exposure is already measurable. CloudSEK's analysis of an unauthenticated MCP server traced a chain from SSRF to local file access to AWS credential theft, and research it cited found more than a third of thousands of MCP servers examined were vulnerable to SSRF. Thousands of these servers sit exposed on the public internet.

High-severity SSRF flaws in AI-adjacent products underline the trend. A 2025 SSRF vulnerability in Azure OpenAI, scored at the maximum CVSS 10.0, let attackers retrieve managed identity tokens, extending the metadata-theft pattern from cloud servers to modern AI services.

How to Prevent SSRF

SSRF defense works in layers, since no single control covers every bypass.

Application Controls

• Allowlist destinations. Permit only known, required hosts and schemes, rather than trying to blocklist bad ones.
• Disable unused URL schemes. Reject file://, gopher://, dict://, and other schemes an application never needs.
• Validate after resolution. Resolve the hostname and check the final IP, defeating DNS rebinding and redirect tricks.

Network Controls

• Filter egress traffic. Block outbound requests from application servers to internal ranges and metadata addresses.
• Segment internal services. Keep sensitive systems off the network paths a compromised server reaches.

Cloud Controls

• Enforce IMDSv2. Require the session-token metadata service, per AWS guidance, so a basic SSRF cannot read cloud credentials.
• Apply least-privilege roles. Give each instance the minimum permissions, so stolen credentials unlock little.
• Watch for exposed handlers. Track internet-facing apps and APIs that fetch URLs, the entry points attackers probe first.

Frequently Asked Questions

How do you test for SSRF?

Testing for SSRF combines manual probing with out-of-band detection, supplying URLs that point to a monitored server and watching for callbacks. Tools such as Burp Suite's Collaborator confirm blind SSRF this way.

How serious is an SSRF vulnerability?

SSRF severity ranges from minor information disclosure to full cloud account takeover, and credential-theft cases routinely score 8.8 to 9.8 on the CVSS scale. Impact depends on what the vulnerable server reaches.

Does a web application firewall stop SSRF?

No, a WAF gives limited protection and often misses SSRF entirely, as the Capital One breach showed when the attack passed through a misconfigured WAF. Allowlisting and egress filtering are stronger controls.

What is the difference between SSRF and an open redirect?

An open redirect sends a user's browser to an attacker-chosen URL, while SSRF makes the server itself send the request. Attackers often chain an open redirect to bypass SSRF allowlists.

Can SSRF be used to read local files?

Yes, where the server's client supports the file scheme, SSRF reaches local files such as configuration and credential stores. Disabling unused URL schemes removes this path.

Does SSRF only affect cloud applications?

No, SSRF threatens any server that fetches URLs, whether cloud-hosted or on-premises, by reaching internal networks and services. Cloud metadata endpoints simply make the impact more severe.