loading
Crawl a target and mine its archived URLs, then test every parameter that takes a URL for server-side request forgery using out-of-band detection.
Live pages and archived URLs are collected, then every parameter that looks like a URL is tested.
A finding means the server fetched an address we control.
A hostname or URL. Default example.com.
A PDF of confirmed SSRF, plus report.json.
Server-side request forgery is invisible from the outside. The response looks normal whether or not the server made the request you asked it to, so the bug sits in production until somebody thinks to test for it with a callback. That is also why it survives code review: the parameter looks like a URL because it is supposed to be one.
This finds the parameters that take a URL and tests each with out-of-band detection, so a finding means the server actually reached out. You get the reachable endpoints, the parameter that carried the payload, and the interaction that proves it, which is the evidence a developer needs to accept the ticket. Scheduling it makes it part of continuous security testing rather than a one-off engagement.
Crawling and archive mining produce different URL sets, and the union is what gets tested:
| url | param | source |
|---|---|---|
| https://example.com/fetch?url=https://internal | url | crawl |
| https://example.com/proxy?target=127.0.0.1 | target | crawl |
| https://api.example.com/webhook?callback=https://attacker.example.com | callback | archive |
| https://dev.example.com/import?src=http://169.254.169.254 | src | archive |
| https://example.com/preview?link=https://metadata.example.com | link | crawl |
Detection is out-of-band, so the report lists the interaction that arrived rather than a response body that looked unusual. That distinction is what makes these findings straightforward to reproduce.
No. The out-of-band interaction detection built into nuclei provides the listener, and the interactions it records are what the report is built from. You do not stand anything up.
Because the response is the same either way. A server that fetched your URL and one that ignored it can return identical bodies, which is exactly why this bug survives code review and why detection has to happen out of band.
Archive mining reads public data and touches nothing. The crawl and the payload delivery are traffic to the target, and an SSRF payload asks their server to make a request on your behalf, which is an action inside their network rather than a read of it. Run those only with authorization.
nuclei needs URLs. Producing them is most of this workflow, crawling the live application and recovering from archives the pages a crawl cannot reach, then merging both into one candidate set. The template run is the last step.
New parameters. Every release adds endpoints, and a parameter that takes a destination is the kind of thing that ships without anyone flagging it. Running after each deploy catches it while the change is still fresh in someone's memory.
Get a personalized demo
A 30-minute walkthrough. We map the platform to your stack and answer pricing and deployment questions for your environment.