// The mistake: treating every callback the same
Many hunters celebrate the moment they receive a DNS or HTTP hit on their listener. And yes, it feels good. Your payload reached something. But that alone does not always prove high impact.
A callback from a public cloud IP could be a preview bot, a security scanner, a CDN worker, a link unfurler, a mail gateway, or a sandbox. Interesting? Yes. Enough for a strong bug bounty report? Not always.
The real question is: “Who made the request, and from where?”
That is why private IP ranges matter. When the source points to 10.x.x.x, 172.16.x.x, or 192.168.x.x, the story changes. Your payload may have reached an internal worker, a backend renderer, an image processor, a PDF generator, or another service living inside the target's private network.
// Public callback vs internal callback
Public IP callback
Could be a bot, proxy, CDN, scanner, email gateway, cloud function, or preview service. Useful signal, but you need context before claiming impact.
Internal IP callback
Suggests that the request came from inside a private network segment. This can strongly support SSRF, backend processing, and internal reachability.
// The private ranges you should recognize instantly
When reading pingback logs, these ranges should immediately stand out. They are commonly used for internal networks, containers, cloud VPCs, Kubernetes clusters, private services, and backend workers.
| Range | Type | Why it matters |
|---|---|---|
| 10.0.0.0/8 | Private | Very common in cloud VPCs, corporate networks, Kubernetes clusters, and backend service networks. |
| 172.16.0.0/12 | Private | Often appears in Docker, container networks, internal microservices, and private cloud segments. |
| 192.168.0.0/16 | Private | Common in local networks, internal appliances, test environments, and small infrastructure setups. |
| 169.254.0.0/16 | Link-local | Can be interesting in cloud metadata contexts, but needs careful validation and program-safe testing. |
| Public cloud IP | Public | Still useful, but may belong to CDN, scanner, gateway, sandbox, or third-party processing service. |
// What a useful pingback hit looks like
The important line is not just the callback. It is the combination of protocol, subdomain label, timestamp, path, and source IP. Here, the label pdf-renderer tells you which payload fired, while 10.24.7.18 suggests the request came from a backend component on an internal network.
avatar-upload, pdf-export, invoice-notes, xml-import, or email-template. When the hit arrives later, you immediately know which feature triggered it.
// Where internal callbacks usually come from
PDF renderers
Export-to-PDF features often fetch remote images, CSS files, fonts, iframes, or HTML resources from backend infrastructure.
Image processors
Avatar uploads, SVG rendering, image resizing, thumbnail generation, and metadata parsing can trigger backend requests.
XML importers
Blind XXE often produces no visible output. A DNS hit from a private IP can prove that a backend XML parser touched your external entity.
Email and notification systems
Link previews, HTML templates, tracking protection, and mail gateways may resolve URLs long after the original request.
Background jobs and cron workers
The request may not happen immediately. It can arrive minutes or hours later when an async worker processes the uploaded file or queued task.
// Safe payload examples for attribution
You do not need dangerous payloads to prove the point. In most reports, a unique DNS or HTTP callback with clear attribution is enough to show that backend processing happened.
# Generic URL for HTML/PDF/image fetch tests https://pdf-export.abc123.pingback.sh/render-check # SVG external reference example <svg xmlns="http://www.w3.org/2000/svg"> <image href="https://svg-upload.abc123.pingback.sh/image" /> </svg> # XML external entity identifier for blind XXE testing <!DOCTYPE root [ <!ENTITY pingback SYSTEM "https://xml-import.abc123.pingback.sh/xxe"> ]> <root>&pingback;</root> # Keep labels readable: feature-name.abc123.pingback.sh endpoint-name.abc123.pingback.sh payload-type.abc123.pingback.sh
// How this changes severity
A weak report says: “I received a callback.”
A strong report says: “The Export to PDF backend worker fetched an attacker-controlled URL. The request came from 10.24.7.18, a private IP range, proving server-side processing from inside the target environment. This indicates SSRF/internal network reachability.”
// What to include in your report
- Exact feature — identify where the URL or payload was submitted: PDF export, avatar upload, XML import, webhook setup, invoice notes, etc.
- Unique listener label — use readable subdomains so the hit can be tied to a specific payload and feature.
- Timestamp correlation — show when the payload was submitted and when the callback arrived.
- Source IP analysis — explain whether the hit came from public infrastructure or a private/internal range.
- Protocol details — DNS-only hits are still useful. HTTP hits add headers and paths. SMTP hits can prove mail-related processing.
- Impact explanation — focus on server-side request behavior, internal network reachability, and what an attacker could safely infer.
- Minimal-risk PoC — avoid extracting secrets or scanning internal services unless explicitly authorized.
// Why PingBack makes this easier
A generic request catcher tells you that something happened. PingBack helps you understand the bug bounty context: DNS, HTTP, SMTP, and XSS-style callbacks in one place, with feature-specific payload labels and logs that are easy to screenshot for reports.
The point is not to collect random hits. The point is to separate noise from evidence. A crawler hit is noise. A backend worker calling from an internal range after a file upload is evidence.