Skip to content
OPS // KITitspentest.sh

X-SSR

SSRFmap

Python tool that takes a confirmed SSRF and automates exploitation against cloud metadata, internal services, and more.

Official siteBack to catalog

OVERVIEW

SSRFmap (github.com/swisskyrepo/SSRFmap) takes a saved HTTP request containing a server-side request forgery and automates what a tester would otherwise do by hand one payload at a time: it fuzzes the vulnerable parameter through a set of modules — readfiles, portscan, networkscan, cloud metadata (AWS, GCP, Alibaba), Redis, MySQL, Docker, SMTP, and more — each built around a known SSRF-to-impact technique.

It's designed to sit downstream of manual confirmation rather than to find SSRF itself: point it at a Burp-exported request file with the vulnerable parameter marked, and it drives that single confirmed injection point through every applicable exploitation path instead of requiring a new manual payload for each one.

USE CASES

Practical use cases

  • 01

    Pivoting a confirmed SSRF into AWS/GCP/Alibaba instance metadata to pull temporary credentials.

  • 02

    Port-scanning and fingerprinting internal hosts reachable only from the vulnerable server.

  • 03

    Abusing SSRF against internal Redis, MySQL, or Docker daemons for further compromise.

  • 04

    Reading local files on the vulnerable host through the file-read module instead of writing a one-off script.

QUICK START

Once a raw SSRF has been confirmed manually, to systematically drive it toward cloud metadata endpoints, internal port scanning, and known backend services.

  1. Confirm the SSRF manually first and capture the vulnerable request with Burp Suite.
  2. Save the request to a file and note which parameter is injectable.
  3. Install SSRFmap's dependencies from its repo (it ships a uv/pip-based setup).
  4. Run it against the saved request with the parameter flag and the modules relevant to the target stack.
  5. Review each module's output and confirm impact manually before reporting it.
python3 ssrfmap.py -r request.txt -p url -m readfiles,portscan

BEFORE YOU RUN IT

What to check before running it

Cloud-metadata and internal-service modules can reach production credentials and internal systems outside the documented scope — confirm the target's network boundaries before running the broader module set.

Any file, credential, or internal response an SSRFmap module retrieves is live sensitive data and should be handled and stored per the engagement's evidence rules, not left in scratch output.

Some modules (Redis, Docker) can write or execute, not just read — treat them as exploitation, not just detection, and get explicit sign-off before running them.

KEEP EXPLORING

View the whole phase →