What Is SSRF (Server-Side Request Forgery)? Complete Guide April 2026

You might assume internal services are safe from external attackers because they're not exposed to the internet. SSRF attacks break that assumption by making your own server do the requesting, borrowing its network position and implicit trust to reach systems you thought were protected. The Capital One breach proved a single forged request can cost hundreds of millions when cloud permissions aren't scoped correctly. We're explaining how attackers chain SSRF with metadata access, which validation gaps matter most, and the specific cloud configurations that actually limit blast radius when prevention fails.

TLDR:

• SSRF tricks servers into fetching unintended destinations, exposing cloud credentials and internal systems
• AWS metadata endpoints at 169.254.169.254 return IAM credentials without authentication by default
• The Capital One breach exposed 100M+ records through one SSRF request that retrieved overprivileged credentials
• IMDSv2 on AWS requires session tokens that block basic SSRF; must be configured manually, not on by default
• Gecko Security finds SSRF vulnerabilities traditional SAST misses by tracing unvalidated URL flows to internal endpoints

What Is SSRF (Server-Side Request Forgery)?

Server-Side Request Forgery (SSRF) is a web security vulnerability where an attacker tricks a server into making HTTP requests to an unintended destination. Instead of the server fetching a resource for legitimate purposes, the attacker redirects that request toward internal systems, cloud metadata endpoints, or other targets the attacker couldn't reach directly.

Quick note before we go further: if you searched "SSRF medical," you're thinking of Surgical Stabilization of Rib Fractures, a chest wall surgery. This guide covers the cybersecurity kind.

SSRF landed on the OWASP Top 10 as its own category in 2021, reflecting how frequently it appears in real breaches. The vulnerability is especially dangerous in cloud environments, where a single forged request can expose credentials that unlock an entire infrastructure.

How SSRF Attacks Work

Most web apps fetch remote resources on behalf of users. Think URL previews, webhook calls, file imports from external URLs. The problem starts when the server accepts a user-supplied URL and fetches it without validating where that URL actually points.

Here's the basic flow. You submit a URL. The server makes the request. You get back whatever the server received. From the server's perspective, the request is totally legitimate. From the network's perspective, it came from a trusted internal source.

That trust is exactly what gets exploited. Internal services often skip authentication for requests coming from within the same network. An attacker who forces the server to make requests on their behalf effectively borrows that implicit trust. A request that would be blocked at the perimeter firewall sails right through when it originates from inside.

A simple example: a server accepts a url parameter to fetch an image. Instead of https://example.com/photo.jpg, you pass http://169.254.169.254/latest/meta-data/. That's the AWS metadata endpoint. The server fetches it, the response comes back to you, and now you have cloud credentials you were never supposed to see.

The validator never fires because the request format looks fine. There's no malicious payload in the syntax. The vulnerability lives entirely in the logic gap between what the application accepts and what it should accept.

Types of SSRF Attacks

Not all SSRF attacks behave the same way. The biggest dividing line is whether the attacker can see the server's response.

There are three main variants worth knowing:

• Basic (in-band) SSRF: The response from the forged request comes back directly to the attacker. You supply a URL, the server fetches it, and the response body is returned to you. Exploiting cloud metadata endpoints or internal APIs typically falls here.
• Blind SSRF: The server makes the request, but you never see the response. Attackers rely on out-of-band techniques, pointing the server at a controlled external host and watching for incoming DNS lookups or HTTP callbacks to confirm the vulnerability.
• Semi-blind SSRF: You can't read the full response, but you get partial signals like HTTP status codes, response times, or behavioral differences depending on whether a port is open. A fast timeout on port 22 versus a slow one on port 9200 reveals internal service info without reading a single byte.

The blind and semi-blind variants are harder to detect during testing but just as dangerous. Attackers who confirm a blind SSRF can still map internal infrastructure, exfiltrate data via DNS, or chain the issue with other vulnerabilities.

SSRF Attack Targets and Impact

SSRF attacks are a starting point, not a dead-end. Once an attacker controls where the server makes requests, the question becomes: what's reachable from here?

Common targets include cloud metadata endpoints (AWS, GCP, and Azure all expose them), internal admin panels, databases, and services that assume localhost requests are safe. From there, attackers can steal IAM credentials, map internal networks, or reach services like Redis and Elasticsearch that have no authentication by default.

The stakes are real. SonicWall's 2025 Cyber Threat Report found a 452% increase in SSRF attacks from 2023 to 2024, driven largely by AI-powered tools automating what once required manual probing.

Impact spans credential theft, data exfiltration, lateral movement, and in some configurations, remote code execution when SSRF reaches services that accept commands. What makes it especially dangerous is how well it chains with other weaknesses: one forged request to a metadata service hands you credentials, those credentials unlock object storage, that storage exposes a config file with a database password. No single bug caused the breach, but SSRF opened the door.

SSRF in Cloud Environments

Cloud environments make SSRF dramatically more dangerous because of one design decision: metadata services. Every major cloud provider exposes instance metadata at a predictable, non-routable endpoint that any process running on the server can query without authentication.

The endpoints are well-known:

• AWS: http://169.254.169.254/latest/meta-data/
• GCP: http://metadata.google.internal/computeMetadata/v1/
• Azure: http://169.254.169.254/metadata/instance

Query any of these from a compromised server and you get back IAM roles, temporary access credentials, instance configurations, and sometimes user data scripts containing hardcoded secrets. Those credentials often carry broad permissions because developers scope cloud roles for convenience instead of least-privilege. One forged request hands an attacker keys to S3 buckets, RDS instances, and secrets managers.

The Capital One breach is the canonical example. An attacker exploited an SSRF vulnerability to query the AWS metadata endpoint, retrieved IAM credentials, and accessed over 100 million customer records. The financial fallout reached nearly $300 million in litigation and settlements, plus an $80 million OCC penalty. The vulnerability itself was unremarkable. The cloud architecture turned it into a disaster.

The Capital One Breach: SSRF Case Study

The 2019 Capital One breach is worth dissecting beyond the headline numbers already mentioned, because the attack chain itself is instructive.

The attacker targeted a misconfigured AWS WAF sitting in front of Capital One's infrastructure. That WAF had SSRF protections disabled, which let a crafted request pass through to the internal server. From there, the server queried http://169.254.169.254/latest/meta-data/iam/security-credentials/ and returned temporary IAM credentials back to the attacker.

Those credentials had ListBuckets and GetObject permissions. The attacker ran a sync against over 700 S3 folders. No lateral movement required. No zero-day. Just one misconfigured rule, one forged request, and keys that were scoped too broadly.

The real lesson here is that SSRF becomes catastrophic when cloud permissions aren't scoped tightly. The vulnerability opened the door, but overprivileged IAM roles let the attacker walk through every room.

Common SSRF Attack Vectors and Payloads

SSRF vulnerabilities cluster around specific patterns in code. If your application accepts a URL from a user and fetches it server-side, that's the risk surface.

The most common entry points:

• URL parameters that fetch remote content (?url=, ?src=, ?path=, ?feed=)
• Webhook configurations where users supply a callback endpoint
• File import features that accept URLs instead of direct uploads
• PDF or screenshot generators that render user-supplied URLs
• API integrations where the server proxies requests on behalf of a client

Common Payload Patterns

Against unfiltered endpoints, straightforward payloads work: http://169.254.169.254/latest/meta-data/iam/security-credentials/ for AWS, or http://localhost:6379/ to probe Redis. Internal service discovery often starts with http://10.0.0.1 and increments from there.

When basic payloads get blocked, attackers shift to filter bypass techniques:

• IP encoding: http://2130706433/ (decimal form of 127.0.0.1)
• Octal notation: http://0177.0.0.1/
• IPv6 loopback: http://[::1]/
• DNS rebinding: a domain resolving to a public IP during validation but switching to an internal IP on the actual request
• URL fragments and redirects: https://attacker.com/redirect?to=http://internal-service/
• Protocol switching: file:///etc/passwd, dict://, gopher:// for non-HTTP targets

The gopher protocol deserves special mention. It lets attackers craft raw TCP payloads, meaning SSRF through gopher can interact with Redis, Memcached, or SMTP directly, which opens the door to remote code execution in certain configurations.

Allowlist bypasses through open redirects are particularly tricky. Many filters validate the initial URL but follow redirects without re-checking. A server that only allows https://trusted-domain.com can still be redirected to http://169.254.169.254/ if trusted-domain.com has an open redirect endpoint.

Blind SSRF Detection Techniques

Blind SSRF is harder to confirm than basic SSRF, but the core detection principle stays the same: if you can't read the response, make the server talk to something you control instead.

Out-of-band (OOB) detection is the standard approach. Point the forged request at an external host you monitor, then watch for incoming connections. Tools built for this include:

• Burp Collaborator (built into Burp Suite Pro) for automated callback detection within a proxied testing session
• interactsh (open source, self-hostable) when you need full control over your listener infrastructure
• webhook.site for quick callback monitoring without any setup overhead

A DNS lookup from the target server confirms SSRF exists, even without HTTP response data. The server resolved your domain, which means it made the request.

Timing-based inference works when OOB isn't possible. Request an internal location that should exist, then one that shouldn't. A faster timeout on the second suggests the port is closed. A slow connection attempt suggests something is listening.

Application behavior changes are the third signal. Error messages that vary by target IP, response time differences, or status code changes based on what was fetched all suggest the server is acting on your input.

SSRF Prevention and Mitigation Strategies

Effective SSRF defense works in layers. No single control is enough on its own.

Application Layer

• Validate user-supplied URLs against an allowlist of approved domains and schemes, never a blocklist, since attackers can always find bypass techniques for blocklists.
• Block non-HTTP protocols: file://, gopher://, dict://, ftp://
• Resolve the URL, then re-validate the resolved IP against private ranges before fetching to catch DNS rebinding attacks.
• Disable redirects, or re-validate every redirect destination before following it.

Network Layer

• Restrict outbound traffic from application servers to only required destinations.
• Use egress filtering to block requests to RFC 1918 ranges (10.x, 172.16.x, 192.168.x) and loopback IPs.
• Segment internal services so they are unreachable from web-tier servers by default.

Cloud Infrastructure

• Enforce IMDSv2 on AWS instances, which requires a session token and blocks simple GET requests to the metadata endpoint.
• Apply least-privilege IAM policies so stolen credentials have limited blast radius.
• Use cloud firewall rules to block metadata endpoint access from application processes that don't need it.

OWASP's SSRF prevention guidance notes that input validation alone is insufficient. Network controls and cloud hardening must back it up, because applications inevitably have edge cases that allowlists miss.

SSRF Mitigation in Cloud Platforms

Each major cloud provider has built defenses into their metadata services, but they require explicit configuration. None of them are on by default.

AWS: IMDSv2

IMDSv2 replaces simple GET requests with a session-based flow. The server must first call the metadata endpoint with a PUT request to get a session token, then include that token in subsequent requests. SSRF attacks using basic GET requests fail completely since there's no token to include.

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

The hop limit matters too. Setting it to 1 means the token request can't survive a network hop, which blocks container-to-host metadata pivoting.

Azure and GCP

Azure IMDS requires a Metadata: true header. Requests without it get rejected, stopping basic SSRF probes since most vulnerability scanners don't include that header automatically.

GCP Workload Identity Federation replaces long-lived service account keys with short-lived tokens tied to specific workloads. Even if an attacker retrieves credentials via SSRF, the token's scope and lifetime are severely limited.

For all three providers, monitoring metadata access patterns catches active exploitation. CloudTrail on AWS logs credential usage, so anomalous AssumeRole calls after metadata endpoint access are a reliable signal that something is wrong.

SSRF CVE Examples and Real-World Exploits

Real-world SSRF exploitation has accelerated sharply. On March 9, 2025, security researchers documented a coordinated campaign where 400+ IPs exploited multiple SSRF CVEs simultaneously, with substantial overlap across attack attempts suggesting organized tooling instead of scattered opportunistic scanning.

A few notable CVEs from that period:

• CVE-2025-61882: An SSRF vulnerability in Oracle E-Business Suite allowing unauthenticated attackers to reach internal Oracle services through exposed HTTP endpoints
• CVE-2025-1220: An SSRF flaw in PHP affecting applications that pass user input to certain URL-handling functions without adequate sanitization

What the March 2025 campaign revealed is that attackers aren't picking one target and moving on. The same infrastructure was probing dozens of known SSRF entry points in parallel, chaining CVEs with credential harvesting in a single automated pass. Incident response teams found evidence of metadata endpoint queries within minutes of initial access.

The pattern reinforces a consistent lesson: unpatched SSRF doesn't sit idle. Once a CVE is public, exploitation follows fast, often within hours as attackers integrate new exploits into automated scanning infrastructure.

How Gecko Security Detects SSRF and Business Logic Vulnerabilities

Traditional SAST tools miss SSRF for the same reason they miss most business logic flaws: pattern matching cannot tell you whether a URL fetch is safe without understanding what the server is allowed to reach. Gecko's compiler-accurate semantic indexing traces how user input flows through request handlers, across service boundaries, and into outbound HTTP calls, flagging cases where destination validation is absent or bypassable.

That's how we found CVE-2025-54381, an SSRF vulnerability in BentoML. The file upload processing accepted URLs without validating whether resolved destinations fell within internal network ranges. No obvious regex. No allowlist check. A rule-based scanner sees a fetch call. Gecko sees an unvalidated fetch call with a reachable cloud metadata endpoint at the end of the call chain.

SSRF rarely exists in isolation, which is why semantic analysis matters more than signature matching. The vulnerabilities that cause real damage are chains: an unvalidated URL parameter reaching a metadata endpoint, credentials returned with excessive IAM scope, no egress filtering at the network layer. Gecko's threat modeling builds those chains the way a pentester would, connecting gaps across code, infrastructure context, and trust boundaries to surface what actually matters.

If you want to see how it works against your codebase, try it free at app.gecko.security.

Final Thoughts on Server-Side Request Forgery Defense

What makes SSRF impact so severe is how well it chains: unvalidated input reaches a metadata endpoint, credentials return with broad IAM scope, no egress filtering blocks the next hop, and your infrastructure unravels from a single forged request. Input validation catches obvious payloads, but attackers bypass allowlists through DNS rebinding, open redirects, and protocol switching faster than signatures update. Gecko traces these paths semantically, connecting user input to outbound requests across service boundaries the way real exploitation works. Talk to our team if you want to see what reachable attack chains exist in your codebase before they show up in incident reports.

FAQ

What's the difference between SSRF and CSRF vulnerabilities?

SSRF tricks the server into making unintended requests to internal or external resources, while CSRF tricks a user's browser into making unauthorized requests to a web application where they're authenticated. SSRF exploits server-side trust relationships; CSRF exploits client-side session state.

How do I prevent SSRF when my application needs to fetch user-supplied URLs?

Validate URLs against an allowlist of approved domains and schemes, resolve the URL and re-validate the resolved IP against private ranges before fetching, and disable URL redirects or re-validate every redirect destination. Network-layer controls like egress filtering to block RFC 1918 ranges provide critical backup defense.

Can blind SSRF attacks be as dangerous as basic SSRF?

Yes. Blind SSRF lets attackers map internal infrastructure, trigger actions on internal services, and exfiltrate data through DNS or timing channels even without seeing response bodies. The lack of visible output makes detection harder, not exploitation less viable.

What is AWS IMDSv2 and why does it stop SSRF attacks?

IMDSv2 requires applications to obtain a session token via PUT request before querying the metadata endpoint, replacing the simple GET requests that SSRF attacks rely on. This session-based flow blocks basic forged requests since attackers can't include the required token.

When should I treat SSRF as a critical priority for remediation?

Fix SSRF immediately if your application runs in cloud environments with metadata endpoints, has access to internal services without authentication, or uses IAM roles with broad permissions. The Capital One breach showed how SSRF becomes catastrophic when cloud credentials are retrievable and overprivileged.