The Best SSRF Tools in 2026

A tools listicle is only useful if the author actually uses the tools. This is the short list of SSRF tools I have spent real engagement hours with in 2026, ranked by how often I reach for each one, with honest notes on where each fits and where each falls short.

If you want the underlying mechanics first, the server-side request forgery deep dive covers the variants, the blind SSRF guide covers out-of-band confirmation, and the cloud metadata SSRF guide covers the IMDS attack surface. This article is for the choice of which tool to run.

The decision matrix

A quick read of the table: SSRFmap is the default automation. Gopherus is the payload forge for the protocol-smuggling cases. Burp Collaborator and interactsh are the OOB listeners. ffuf is the entry-point finder. PayloadsAllTheThings is where every cloud-metadata path lives.

1. SSRFmap

Repo: github.com/swisskyrepo/SSRFmap

The default. If you only learn one SSRF tool, learn this one.

SSRFmap takes a captured request file (Burp-style) with a marked injection point, and walks an entire library of SSRF modules against it: AWS IMDS, GCP metadata, Azure metadata, Alibaba metadata, DigitalOcean metadata, port scanning, Redis (raw and gopher), MySQL, FastCGI, SMTP, Zabbix, and a long tail of internal-service probes. The marker is SSRF in the request body or query string; the tool substitutes payloads at that point and reports what came back.

What I like:

• The module system is the right abstraction. Each module knows the protocol it speaks, the URL shape it needs, and how to recognise a hit. Adding a module is a small Python file.
• Cloud-metadata coverage is current. AWS IMDSv1 and the IMDSv2 token dance are both implemented; GCP, Azure, Alibaba, Oracle Cloud, and IBM Cloud are covered out of the box.
• Port scanning over an SSRF primitive is fast enough to be useful, and the output is grep-friendly.
• The gopher:// modules pair cleanly with Gopherus for the cases where the built-in payload is not quite right.

What I do not like:

• The SSRF marker convention is fine until your injection point sits inside a JSON body that the server re-serialises, at which point you fight quoting. Hand-craft the request file in those cases.
• Some modules assume a permissive backend client (urllib, requests, Java URL). Targets fronted by a strict allowlist proxy require manual tuning that the tool will not do for you.
• Default verbosity is heavy. Pipe to a file and grep.
• Single-author maintenance, so issue triage is spikier than a sponsored project.

When to use it. Always start here once you have a confirmed or suspected SSRF primitive. Capture the vulnerable request in Burp, save with SSRF as the placeholder, point SSRFmap at it. If it finds metadata, you are done. If it does not, move to manual via Burp Repeater plus Gopherus.

Typical command:

ssrfmap -r request.txt -p url -m readfiles,portscan,redis,aws

Full reference: the SSRF deep dive covers what each module is actually probing for.

2. Gopherus

Repo: github.com/tarunkant/Gopherus

The payload forge for SSRF-to-RCE chains over gopher://.

Gopherus generates ready-to-fire gopher:// URLs for the protocols that internal services speak in cleartext over TCP: Redis (SET + CONFIG SET dbfilename for cron or webshell drops), MySQL (auth + query smuggling), FastCGI (PHP-FPM unauth RCE via PHP_VALUE headers), SMTP (mail smuggling), and Zabbix agent. You answer a few prompts about the target service, it emits the URL-encoded gopher payload, you drop it into the SSRF parameter.

What I like:

• It is the only tool that knows the wire format of these services well enough to produce a working payload on the first try. Hand-crafting a Redis-via-gopher URL by hand is doable but tedious.
• FastCGI mode is the one that earns the tool its reputation. PHP-FPM listening on a Unix socket or internal port is still a depressingly common finding in 2026.
• Output is just a string. Easy to pipe into SSRFmap, ffuf, or a Burp Repeater paste.

What I do not like:

• Maintenance is light. The codebase has not changed materially in a while, and a couple of payload templates assume older service versions (modern Redis 7 ACLs will reject some defaults).
• The interactive prompt flow is awkward to script. Wrap it in expect if you need automation.
• Python 2 cruft has mostly been cleaned up but the install is still rougher than it should be.

When to use it. Whenever the SSRF target speaks Redis, MySQL, FastCGI, SMTP, or Zabbix and the backend HTTP client follows redirects to gopher:// (curl with --proto-default gopher, libcurl with gopher enabled, the JVM's URL class in some versions). The PayloadsAllTheThings SSRF chapter has the up-to-date list of which clients still cooperate.

3. Burp Suite (Community and Professional) and Collaborator

Site: portswigger.net/burp

Not a single-purpose SSRF tool; the platform every manual SSRF workflow runs on.

Burp plays three distinct roles for SSRF:

1. Repeater. The hand-crafted-payload tweaking loop. Change the scheme, the host, the port, the encoding, watch the response. SSRF is the variant class where Repeater earns its keep.
2. Collaborator (Pro only). The OOB listener with public DNS plus HTTP plus SMTP endpoints. For blind SSRF where the response body tells you nothing, Collaborator is what tells you the request actually went somewhere.
3. Active Scanner (Pro only). Built-in SSRF detection probes that fire Collaborator payloads automatically and flag any callback as a confirmed finding.

What I like:

• Collaborator is the gold standard. Public DNS that you do not have to host, separate subdomains per probe so you can correlate findings, and the polling client is built into Burp.
• The manual Repeater workflow is unmatched for crafting bypass payloads (127.0.0.1 to 127.1 to 127.0.0.1.nip.io to decimal-encoded to IPv6-mapped) and seeing immediately which one the allowlist eats.
• The Intruder integration for parameter fuzzing is convenient when ffuf would be overkill.

What I do not like:

• Pro licence is around 500 USD per user per year. For SSRF work the Collaborator alone is worth it, but it is real money.
• Collaborator is hosted by PortSwigger on *.oastify.com. Some hardened targets blocklist the parent domain wholesale, which kills detections you would otherwise catch. interactsh on a custom domain is the workaround.
• The Community edition is essentially unusable for serious SSRF work because Collaborator is Pro-only.

When to use it. Always running in the background. Capture requests there, fire OOB probes through Collaborator, escape to SSRFmap and Gopherus for the scripted cases.

4. interactsh

Repo: github.com/projectdiscovery/interactsh

The free, self-hostable Collaborator alternative.

interactsh is an open-source OOB callback server from ProjectDiscovery. It runs on your own domain (so the listener URLs do not look like a known security-vendor host), supports DNS, HTTP, HTTPS, SMTP, and SMTPS, and ships both a hosted endpoint at oast.pro and a CLI that polls and decrypts callbacks locally.

What I like:

• Self-hostable on any domain you own. The blocklist trick that defeats Collaborator does not work if the listener is on a domain the target has never seen.
• Free and open-source. No per-seat licence.
• Integrates cleanly with Nuclei, ffuf, and the rest of the ProjectDiscovery stack, so a template that requires OOB confirmation just works.
• The encrypted-correlation design means even the hosted instance never sees the plaintext interaction data.

What I do not like:

• Self-hosting requires running a public DNS server (NS records, port 53) plus an HTTP listener with a wildcard certificate. The docs cover it, but it is more setup than "click install".
• The hosted oast.pro instance is itself signatured by some defender products by now, so the more popular it gets the more useful self-hosting becomes.
• Less polished UI than Burp Collaborator. The CLI output is functional rather than friendly.

When to use it. Whenever you do not want to pay for Burp Pro, or whenever the target's egress blocklist eats oastify.com. Pair it with ffuf for high-volume blind-SSRF fuzzing where each request needs an independent OOB token.

5. ffuf (and wfuzz)

Repo: github.com/ffuf/ffuf

The parameter-discovery layer. SSRFmap exploits; ffuf finds the entry point.

ffuf is a Go-based web fuzzer. For SSRF its job is upstream of SSRFmap: it identifies which parameters on which endpoints feed a server-side fetch in the first place. Run it with a list of common SSRF-flavoured parameter names (url, uri, link, target, dest, redirect, image, file, path, callback, webhook, proxy) against every endpoint in your scope, with the value set to an interactsh callback URL, and harvest the parameters that produce a callback.

What I like:

• Very fast. Go concurrency, sane defaults, and the matcher/filter syntax is precise enough to cut through noisy targets.
• The -w wordlist + -fw/-fc/-fs filtering combination is exactly the shape SSRF discovery wants.
• Integrates with interactsh for the canary-callback workflow with no glue code.
• The recipe ecosystem is solid; SecLists ships SSRF-specific parameter wordlists.

What I do not like:

• It is a general-purpose fuzzer, so SSRF-aware features (recognise an IMDS response, recognise a port-scan timing pattern) are not built in. That is what SSRFmap is for.
• Output is JSON-or-text; building dashboards on top requires your own scripts.

When to use it. First, before SSRFmap. The flow is: hakrawler to enumerate URLs, ffuf to find the SSRF-feeding parameter, SSRFmap to exploit it.

wfuzz covers the same niche in Python. It is older and slower, but actively maintained (v3.1.1 shipped January 2026). I keep it installed for the handful of targets where ffuf's HTTP/2 client misbehaves and wfuzz's older HTTP/1.1-only stack happens to work.

6. Smuggler and hakrawler

Smuggler repo: github.com/defparam/smuggler hakrawler repo: github.com/hakluke/hakrawler

The feeders. Neither of these is an SSRF tool on its own; both surface the inputs SSRFmap and ffuf then consume.

hakrawler is a fast Go crawler that pulls URLs from JavaScript, robots, sitemaps, and the page HTML. For an SSRF assessment its job is to give you the full set of endpoints and parameters that ever touch a URL or filename argument, so ffuf has somewhere to fuzz.

Smuggler is a request-smuggling detection tool. It belongs in the SSRF toolbox because a successful smuggling primitive (CL.TE, TE.CL, TE.TE) often lets you reach internal hosts the front-end proxy would otherwise block, which is structurally the same thing as SSRF from a target-reachability perspective. Plus a host-header confusion bug (a different Smuggler trick, sometimes called "Host of Trouble") routes your request to a different backend, which can leak into SSRF when that backend trusts the original host header for outbound fetches.

What I like:

• hakrawler output pipes straight into ffuf via stdin. The whole discovery pipeline is one shell line.
• Smuggler's report format makes it obvious which primitive type was detected, which determines the smuggled-request shape.

What I do not like:

• hakrawler is read-only and unauthenticated; for SPAs that hide URLs behind login flows you still need Burp's content discovery or a manual Playwright crawl.
• Smuggler's false-positive rate on CDNs that aggressively normalise headers can be high. Always reproduce by hand before reporting.

When to use it. At the top of the pipeline. Both tools run before you know there is an SSRF; they hand you the candidate surface.

7. PayloadsAllTheThings (SSRF section)

Site: swisskyrepo.github.io/PayloadsAllTheThings/Server Side Request Forgery

Not a tool. The canonical reference. Use it as a lookup, not a copy-paste source.

The SSRF chapter of PayloadsAllTheThings is the single best maintained reference for cloud-metadata endpoints (AWS IMDSv1 and IMDSv2, GCP, Azure, DigitalOcean, Oracle Cloud, IBM Cloud, Alibaba, Tencent, Hetzner), localhost-bypass encodings (127.0.0.1 vs 127.1 vs 2130706433 vs 0x7f.0.0.1 vs [::1] vs 127.0.0.1.nip.io), and the wrapper-protocol payloads (file://, dict://, ldap://, gopher://, jar://).

What I like:

• Pull requests get merged. The repo genuinely tracks current cloud-metadata service quirks (IMDSv2 hop-count limits, GCP's Metadata-Flavor: Google header requirement, Azure's Metadata: true header).
• The bypass section is organised by failure mode, not by payload, which is the right shape when you are stuck.
• 60k+ stars, very-active maintenance, easy to trust as a baseline.

What I do not like:

• Markdown-only. There is no machine-readable form, so building tooling on top requires scraping.
• Some bypass payloads are duplicated across multiple sub-pages; finding "the" canonical entry sometimes takes a second pass.

When to use it. Open it in a browser tab and keep it there for the duration of any SSRF engagement. The IMDS path you need, the localhost bypass you forgot, the gopher syntax you misremembered: all there.

What I do not recommend

Old "ssrf-detector" scripts

Several Python and PHP scripts from the mid-2010s self-identify as SSRF detectors. They typically fire a hardcoded http://169.254.169.254/latest/meta-data/ and look for an AWS-shaped response. That worked in 2016. In 2026 every cloud target has IMDSv2 by default, the request is rejected without the token dance, and the script reports "not vulnerable" against a target that is in fact vulnerable. Worse, some of these scripts have not been updated for the GCP or Azure endpoints at all. Skip them.

Commercial WAF testers that include "SSRF" as a checkbox

Several commercial DAST suites advertise SSRF coverage as one of dozens of features. In practice they fire a couple of canned payloads at localhost and 169.254.169.254, flag any 200 response, and call it a finding. The false-positive rate is high enough that the report is worse than useless: a developer who sees five false SSRF alerts will ignore the sixth one that is real. If you want SSRF coverage, run SSRFmap. If you want continuous SSRF coverage, write a Nuclei template against interactsh and run it on a schedule.

Tools I dropped from this year's list

• SSRF-King (Burp extension). Useful in its day; the underlying detection logic is now better covered by Burp's own Active Scanner plus interactsh. The extension has not been updated meaningfully in years and triggers on too many false positives against modern frameworks.
• fimap (file inclusion / SSRF crossover). Project is unmaintained. The local-file-read SSRF payloads it generated are now in PayloadsAllTheThings, and the rest of its coverage is below SSRFmap's baseline.
• Random "AWS metadata stealer" one-off scripts. Replaced by SSRFmap's AWS module which handles IMDSv2 correctly.

Which tool should I use? (Decision tree)

A short flow for the common cases:

• Do you already know where the SSRF entry point is?
  • No. hakrawler to enumerate URLs, ffuf with an SSRF parameter wordlist plus an interactsh callback to find the parameter, then come back.
  • Yes. Continue.
• Is the goal "confirm the bug exists" against a blind target?
  • Yes. interactsh (or Burp Collaborator if you have Pro). Fire a payload, wait for the callback.
• Is the goal cloud-metadata extraction?
  • Yes. SSRFmap with the appropriate cloud module. Cross-reference PayloadsAllTheThings if the built-in module is silent and you suspect a non-default IMDS configuration.
• Is the goal SSRF-to-RCE via an internal service?
  • Yes. Gopherus for the payload, SSRFmap for the delivery, Burp Repeater for the hand-tuning step where it always ends up.
• Are you behind a strict outbound allowlist that only accepts certain hosts?
  • Yes. Drop to manual via Burp Repeater. Try every encoding in the PayloadsAllTheThings bypass section. Open redirects on allowlisted hosts are often the way in. See the DNS rebinding SSRF guide for the time-of-check vs time-of-use angle.
• Are you teaching someone the underlying mechanics?
  • Manual first. PortSwigger Web Security Academy SSRF labs, then the SSRF deep dive. Tooling after they understand the variants.

A note on the year stamp

I will refresh this list every twelve months. The slug stays stable (best-ssrf-tools-2026 is a redirect target you can rely on; future years update the H1 and title). Tools added, dropped, and re-ranked here will appear in the next refresh with a short changelog at the top.

Where to go next

• Server-side request forgery: variants, exploitation, and defence for the underlying mechanics
• Blind SSRF: out-of-band confirmation patterns for the OOB workflow
• Cloud metadata SSRF: IMDS, GCP, Azure for the cloud-attack surface
• DNS rebinding SSRF: bypassing allowlists at request time for the TOCTOU angle
• Web application security vulnerabilities taxonomy for the broader map