vulns.co
/
mcp by GKData.io

SSRF hunting

Server-side request forgery is a fetch you do not control. Prove the server made the request with a canary, then decide whether it is metadata, an internal app, or a file handler.

Playbooks

  • SSRF Hunting - Find server-side request forgery, then pivot to metadata and internal services.
  • XXE Injection - Abuse XML external entity parsing to read files, perform SSRF, or exfiltrate data out-of-band.
  • Webhooks, Unfurl, PDF, Image SSRF - Every 'fetch this URL for me' feature is SSRF. Canary, then internal, then metadata.
  • Blind Command / Server-side OAST - Use controlled, callback-only discriminators to distinguish server-side processing from reflection and to establish a safe evidence trail for blind command or fetch hypotheses.
  • Cloud storage and public object hunting - Public buckets still pay, but only after you prove ownership. DNS, TLS SAN, response body, or a billing alias. Guessing a brand name is recon, not a report.

Gadgets

Payloads

  • Server-Side Request Forgery - Point the server inward. Cloud metadata endpoints leak credentials; the bypass block (decimal/hex IP, IPv6, enclosed-alphanumerics, DNS rebinding hosts) defeats common allow-list filters.
  • XML External Entity - Classic file read via inline entity; blind exfiltration via an external DTD you host. Also works through SVG and Office (docx/xlsx) uploads. Avoid billion-laughs on prod - it's a DoS.
  • Open Redirect - Escape allow-list redirect validation. Low impact alone, but chains into OAuth token theft and SSRF filter bypass. Test on redirect_uri, next, returnUrl, url, and dest params.
  • Prompt Injection / LLM - Probes for LLM-backed features (chat, RAG, agents). Start with a benign marker to prove the model follows injected instructions, then escalate to system-prompt leak, insecure output handling (output → XSS/SSRF/command sink), and tool/agent abuse. Indirect probes go inside data the model ingests (docs, pages, emails, filenames). Keep PoCs benign - use OAST callbacks, never real exfil. See the /bypasses/ ai-guardrails sheet.

Bypasses

  • SSRF filter bypass - Defeat allow-list / blocklist URL validation to reach internal or cloud-metadata endpoints. IP-format tricks and parser confusion are the highest-yield.
  • JWT header / key tricks - The payload is a distraction. The header is the attack: alg, kid, jku, x5u, and whether the server fetches a key you control.
  • Cloud metadata SSRF - You already have a server-side fetch. These are the destinations and the header gadgets for IMDS.
  • XXE parser still fetches - Prove the parser resolves an external identifier with a canary. Do not file-read or hit metadata first.

Checklists

  • SSRF - Canary first. Metadata second. File handlers last.
  • Cloud / SaaS extras - Public buckets and metadata still pay. Most of the work is proving it is theirs.
  • LLM / prompt injection - The model is not the product. The tools it can call are.

Tools

  • gf - A wrapper around grep with reusable pattern packs (xss, sqli, ssrf, lfi, redirect). Instantly slices URL lists into likely-vulnerable candidates.
  • unfurl - Pulls out and formats parts of URLs (domains, paths, params, keys). Handy for building custom wordlists from URL corpora.
  • interactsh - Out-of-band interaction gathering (OOB/OAST). Catches blind SSRF, RCE, and XXE via DNS/HTTP callbacks. Self-hostable.
  • tlsx - Fast TLS grabber that pulls SANs, issuers, and cert metadata - a rich, often-overlooked source of new subdomains and internal hostnames.

Workflows

Questions

When is SSRF actually high impact?

When you can show the server fetched a URL you control, then a second hop to metadata, an internal admin, or a file parser. A DNS callback alone is the primitive, not the report.

Should I hit cloud metadata first?

No. Canary first. Metadata second, and only if the program allows it. IMDSv2 and header-gated metadata are harder gadgets, not 'safe'.

This page is the public form of hunt_brief("ssrf") on the MCP connector. Authorized testing only.