Problem Framing

Server-Side Request Forgery (SSRF) is a critical web security vulnerability where an attacker can induce the server-side application to make unintended HTTP requests to an arbitrary domain of the attacker's choosing ^[1]. This allows the server, acting as a proxy, to bypass network segmentation, firewalls, and access internal resources that would otherwise be inaccessible from the external network ^[2][3][4]. The impact ranges from sensitive data exposure, including cloud credentials, to Remote Code Execution (RCE) ^[5][6][7].

Modern application architectures, particularly those leveraging cloud services, microservices, and AI/ML frameworks, introduce a vast attack surface where SSRF vulnerabilities can manifest and have severe consequences ^{[8][9][10][11]}. The ability for an attacker to control the origin and destination of server-initiated requests makes SSRF a highly potent threat vector, especially when combined with other vulnerabilities ^[12][13].

Core Mechanics

At its core, SSRF occurs when an application takes user-supplied input that dictates the URL or destination of a server-initiated request, and this input is not adequately validated or sanitized ^[5][14]. The application then acts on this input, making a request on behalf of the user to a resource that the application itself can reach, but the user cannot directly reach from their client.

The fundamental mechanism involves an attacker providing a URL that points to:

• Internal resources: Such as localhost, 127.0.0.1, or other private IP addresses within the internal network ^[15][2][4]. This allows attackers to enumerate internal services, access administrative panels, or pivot deeper into the network.
• Cloud Provider Metadata Services (IMDS): For cloud-hosted applications, metadata endpoints like 169.254.169.254 (AWS) are prime targets. SSRF can be used to retrieve temporary credentials, instance metadata, and other sensitive information, leading to cloud account compromise ^{[5][16][6][3][17][18]}.
• External but trusted third-party services: Which might then be used as a pivot point to attack other internal or external systems.

The server performs the request, and if the response is reflected back to the attacker, it's a "full-read" SSRF. If the attacker can only infer success or failure through indirect means (e.g., timing differences, DNS callbacks), it's a "blind" SSRF ^[19][20].

Notable Techniques

Attackers employ a diverse set of techniques to discover and exploit SSRF vulnerabilities, often chaining them with other weaknesses.

Bypassing Input Validation and Filters

Initial SSRF checks often involve allowlists or denylists of IPs, protocols, or hostnames. Attackers have developed numerous methods to bypass these:

• IP Address Obfuscation: Naive filters might block 127.0.0.1. Attackers can use decimal representations (e.g., 2130706433), octal (0177.0.0.1), hexadecimal, or IPv6-mapped IPv4 addresses ([::ffff:127.0.0.1] or [0:0:0:0:0:ffff:127.0.0.1]) to reach localhost or private IPs ^{[15][2][21][22][23][24]}.
• URL Parsing Discrepancies and Quirks: Different libraries or components might parse URLs differently. Attackers leverage this by using characters like @, #, or %2523 (double URL-encoded fragment) to trick parsers, especially when targeting whitelists ^[25][26][24]. Similarly, using double slashes (//) can sometimes bypass validation ^[27].
• Redirect-Based Bypasses: Exploiting HTTP redirects (301, 302, 303, 307, 308) allows attackers to steer the server's request to a disallowed destination after initial validation. HTTP 303 redirects are particularly interesting as they can change a POST request to a GET request, useful for exfiltrating data ^{[28][29][30][31][32][33]}.
• DNS Rebinding: Attackers set up DNS servers that initially resolve a malicious domain to a public IP, satisfying a whitelist check. After the initial DNS resolution, the DNS server quickly changes the IP to a private one (e.g., 127.0.0.1), allowing the SSRF request to hit internal resources ^{[34][31][35][36][37][38]}.
• Protocol Abuse: Beyond HTTP/HTTPS, SSRF can exploit other URL schemes like file:// (for local file reads) ^[39][40], gopher:// (for sending arbitrary TCP data, useful for exploiting services like Redis or Kafka) ^[41][42], dict://, sftp://, ldap://, and tftp:// ^[43][40][24].
• Path Traversal and Normalization Bypasses: Using backslashes (\) or other techniques can sometimes bypass path validation ^[27].
• File Extension Manipulation: Appending seemingly innocuous file extensions (e.g., .yaml, .mp3) can sometimes trick servers into accepting requests to internal resources that they would otherwise block ^[44][45].

Targeting Cloud Metadata Services

Accessing cloud metadata endpoints is a high-value SSRF target. Attackers aim for:

• AWS IMDSv1: The legacy metadata service at 169.254.169.254 is vulnerable to SSRF. Attackers can retrieve temporary IAM credentials, leading to extensive cloud account compromise ^{[5][16][6][17][46][47][48][49][50][18][51]}.
• IMDSv2 Bypass: The newer IMDSv2 requires a PUT request to obtain a token before accessing metadata. While this mitigates simple SSRF, attackers can still bypass it by exploiting other vulnerabilities (e.g., prototype pollution, header injection) to obtain tokens or by exploiting applications that still allow IMDSv1 ^{[52][53][46][54]}.
• Other Cloud Providers: Similar metadata services exist for Azure and GCP, and SSRF can be used to target them ^{[8][3][55][56]}.

SSRF Chains and Amplification

SSRF is often chained with other vulnerabilities to achieve greater impact:

• SSRF to RCE: SSRF can be used to reach internal services that are vulnerable to command injection or deserialization flaws, enabling RCE ^{[57][12][7][58][59][60][61][62]}. For instance, reaching Redis via SSRF and then sending commands to execute arbitrary code ^[63][24].
• SSRF to XSS: By making a server request to an internal endpoint that returns user-controlled data, and then reflecting that data back in an HTML context, SSRF can be used to achieve XSS, especially in blind scenarios ^[64][65].
• XXE to SSRF: XML External Entity (XXE) injection vulnerabilities can be leveraged to force the server to make HTTP requests, thus turning an XXE into an SSRF attack ^{[66][67][68][69]}.
• Open Redirect to SSRF: Chaining an open redirect vulnerability with an SSRF vulnerability allows an attacker to bypass whitelists and access internal resources ^[29][32].
• SSRF via File Uploads/Generators: Applications that process uploaded files (e.g., ZIP, SVG) or generate PDFs from HTML can be tricked into making SSRF requests if they fetch external resources based on user input within those files or HTML ^{[70][71][72][69]}.

Blind SSRF Detection

Detecting SSRF without direct response feedback is challenging. Techniques include:

• Out-of-Band Application Security Testing (OAST): Using services like Burp Collaborator or Interactsh, attackers can confirm SSRF by observing DNS lookups or HTTP requests made by the server to the OAST server ^{[73][74][75][38][76]}.
• Time-Based Blind SSRF: Measuring the time difference in server responses when targeting different internal ports or services to infer reachability ^[20][77].
• Error-Based Blind SSRF: Analyzing error messages for clues about internal network connectivity.

AI and LLM Framework Security

The rise of AI and Large Language Models (LLMs) has introduced new SSRF attack vectors. LLM gateways, RAG pipelines, and AI inference servers can be vulnerable:

• LLM Gateways/RAG Pipelines: Applications that fetch data from external or internal sources to augment LLM prompts (Retrieval-Augmented Generation) are susceptible. If URL fetching is not properly validated, attackers can craft requests to internal endpoints ^{[8][78][79][80][81][82]}.
• AI Agent Network Access: AI agents designed to interact with the network might have unvalidated outbound request capabilities, leading to SSRF ^[81][82][83].
• Specific AI Tools: Tools like LiteLLM, LMDeploy, ChatGPT's Custom GPT, and BerriAI/litellm have known SSRF vulnerabilities ^{[84][78][79][80][55][56][85][86]}.

Detection and Prevention

Effective SSRF prevention requires a multi-layered approach focusing on input validation, output encoding, and network controls.

Input Validation and Sanitization

• Strict Allowlisting: This is the most robust defense. Instead of denylisting, applications should only permit requests to a predefined, trusted list of URLs or IP addresses ^[16][3][87].
• URL Parsing and Schema Enforcement: Validate that user-supplied URLs use only allowed schemes (e.g., http, https) and reject others (e.g., file://, gopher://, dict://). Enforce strict URL parsing to prevent malformed inputs from bypassing checks ^[88][37][89].
• Disable Unused URL Schemas: If your application doesn't require specific URL schemes for its functionality, disable support for them ^[90][91].
• Validate Hostnames and IPs: When allowlisting, ensure validation correctly handles IP address representations (decimal, octal, hex, IPv6) and that hostnames are properly resolved and validated against the allowlist ^{[15][2][21][22][23]}.
• Sanitize Redirects: If redirects are necessary, ensure they point to legitimate, trusted destinations and do not redirect to internal IPs or disallowed domains ^[29][32].

Network Controls and Egress Filtering

• Egress Filtering: Implement strict firewall rules on servers to prevent outbound connections to unauthorized IP ranges or destinations ^[92][93]. This is a crucial defense-in-depth measure.
• Separate Network Zones: Isolate internal services from externally facing application servers.
• Metadata Service Enforcement: Enforce IMDSv2 for AWS instances and equivalent controls for other cloud providers to prevent unauthorized access to metadata ^{[52][16][94][49][95]}.

Application-Level Defenses

• Use Secure HTTP Libraries: Utilize libraries that have robust SSRF protection mechanisms or follow security best practices ^[88][96].
• Avoid Trusting Headers for Origin Information: Do not blindly trust headers like Host, X-Forwarded-For, or X-Forwarded-Proto for security-sensitive decisions, as they can be manipulated ^[97][98][25].
• Regular Patching and Monitoring: Keep all software, libraries, and dependencies updated to patch known SSRF vulnerabilities ^{[99][100][101][12][11][102][103][7][58][59][104][105][106][107][108][109][110][111]}. Monitor network logs for anomalous outbound requests.
• Disable Unused Features: If features like PDF generation or image proxying are not essential, consider disabling them. If they are necessary, ensure their URL fetching capabilities are strictly validated.

Tooling

A range of tools aids in discovering, exploiting, and defending against SSRF vulnerabilities:

• Burp Suite: An indispensable tool for manual testing. Features like Intruder for fuzzing and Collaborator for out-of-band detection are invaluable for SSRF hunting ^{[73][74][75][112][38][113][114]}. Extensions like IP Decimal Converter can help bypass WAFs ^[115].
• Nuclei: A versatile template-based scanner that can be used with specific SSRF templates for automated detection ^[116][117].
• SSRFmap: An automatic SSRF fuzzer and exploitation tool supporting various modules for scanning, exploitation, and RCE ^[118][119].
• Interactsh/Burp Collaborator: Essential for detecting blind SSRF by providing unique DNS and HTTP endpoints for callback monitoring ^{[74][75][38][76]}.
• DNS Rebinding Tools: Services like rbndr.us or Singularity automate DNS rebinding attacks for bypassing SSRF protections ^[34][35][37].
• Gopherus: A tool for generating gopher:// links, particularly useful for SSRF exploitation against TCP services like Redis or Kafka for RCE ^[41][42].
• See-SURF: A Python-based scanner for identifying potential SSRF parameters ^[72].
• Drawbridge: A library designed to provide SSRF protection for Python's requests and httpx libraries ^[120].
• CNAPPgoat: Used to demonstrate SSRF exploitation scenarios in cloud environments like AWS EC2 ^[121][51].
• Static Analysis Security Testing (SAST) tools: Can identify vulnerable code patterns indicative of SSRF before deployment ^[13].

Recent Developments

The SSRF landscape is constantly evolving:

• AI and LLM Infrastructure Vulnerabilities: SSRF has become a significant concern in AI applications. Vulnerabilities in LLM gateways, RAG pipelines, and tools like LiteLLM, LMDeploy, and ChatGPT's Custom GPT have been actively exploited, often leading to credential theft and internal network access ^{[8][84][78][79][80][55][56][85][86][122]}.
• Sophisticated Bypass Techniques: Attackers continue to develop advanced methods to bypass filters, including complex URL parsing tricks, DNS rebinding, HTTP/2 smuggling, and exploiting subtle differences in how network protocols or libraries handle data ^{[31][35][123][33][24]}.
• Rapid Exploitation: Once vulnerabilities are disclosed, especially in popular AI tools, exploitation can be incredibly swift. For instance, LMDeploy's CVE-2026-33626 was exploited within hours of disclosure ^[80].
• Focus on Cloud Environments: The prevalence of cloud-native applications means SSRF targeting cloud metadata services remains a critical and actively exploited threat ^{[5][6][3][17][46][47][48][49][50][18][51]}.
• Exploitation of Medium-Severity Vulnerabilities: Even SSRF vulnerabilities with moderate CVSS scores are frequently exploited, demonstrating their practical impact ^[124].

Where to Go Deeper

For practitioners seeking to deepen their understanding and practical skills in SSRF, the following resources are highly recommended:

• PortSwigger Web Security Academy: Offers numerous labs specifically designed for learning SSRF exploitation, including basic SSRF, blind SSRF, and bypass techniques ^{[24][112][125]}.
• OWASP SSRF Cheat Sheets and Guides: The OWASP Foundation provides comprehensive documentation on SSRF, including attack vectors, prevention strategies, and typical targets ^{[126][127][91]}.
• Bug Bounty Writeups and Blogs: Many researchers share detailed analyses of SSRF vulnerabilities they discover, including exploit chains and bypasses. Platforms like Medium, x.com (formerly Twitter) security researchers, and dedicated security blogs are invaluable ^{[28][128][67][7][58][59][129][130][74][75][36][45][131][92][132][133][97][134][135][68][136][137][138][139][140][55][141][56][142][143][105][39][144][46][145][47][54][146][147][148][149][64][150][151][152][112][121][153][154][37][155][156][89][157][158][159][90][40][160][118][38][20][161][162][163][164][165][166][167][168][22][169][32][170][171][172][173][174][175][176][177][178][63][179][180][181][182][183][184][185][186][187][60][61][48][49][188][189][50][190][191][192][193][194][124][195][196][197][198][87][199][107][14][113][200][201][202][77][18][203][23][76][115][108][204][95][205][109][206][123][33][51][70][207][208][71][209][114][72][119][210][116][117][85][86][211][212][122][213][214][215][216][217][218][219][220][221][222][223][224][225][226][111][227][228][65][229][230][231][232][233][24][62][41][42][234][235][69]}.
• Tooling Documentation and Repositories: Exploring the documentation and codebases of popular SSRF tools like SSRFmap, Gopherus, and See-SURF can provide practical insights into exploitation techniques ^{[118][41][119]}.
• CVE Databases and Security Advisories: Staying updated with newly disclosed SSRF vulnerabilities (CVEs) and vendor advisories is crucial for understanding evolving threats and attack patterns ^{[84][99][100][57][101][12][11][102][80][103][21][236][7][58][59][129][130][237][238][36][45][132][133][97][134][135][239][68][141][142][143][105][240][39][241][144][150][151][121][20][165][166][167][168][173][174][176][177][178][63][179][183][185][60][61][199][107][108][204][109][122][213][214][216][217][218][219][220][221][222][223][224][111][227][229][231]}.