Blind SSRF Detection: How Vexta's Built-In OOB Callback Server Proves It

Blind SSRF detection means proving that a server made an outbound request you triggered, even when nothing in its HTTP response shows it happened. Vexta is VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, and it ships a built-in out-of-band, or OOB, callback server: a listener that waits on DNS and HTTP/HTTPS for a payload to phone home, so a hunter gets a real, correlated callback as evidence instead of an educated guess based on response timing alone.

What is out-of-band detection, and why does blind SSRF need it?

Out-of-band detection means confirming a payload worked through a side channel, a DNS lookup or an HTTP request arriving somewhere the tester controls, rather than through the direct response to the original request. It is the only reliable way to catch a bug whose effect never shows up in that response at all.

Blind server-side request forgery is exactly that case: the vulnerable server issues an outbound request on your behalf, but the application's own HTTP response gives no hint that it happened. Without a side channel to watch, a hunter is left inferring the bug from indirect signals like response delay, which is exactly the kind of guess Vexta's proof-of-exploitation approach is built to avoid. Vexta's OOB server gives that side channel a home: a DNS and HTTP/HTTPS listener the scanner controls, waiting for the callback the payload was designed to trigger.

How does Vexta know which finding a callback belongs to?

Every OOB payload Vexta sends carries a unique correlation ID. When a callback lands on the listener, whether it is a DNS query or an HTTP hit, that ID is what ties the callback back to the exact payload and finding that produced it, even when a scan has many OOB probes in flight against different parameters at once.

That matters in practice more than it sounds like it should. A scan running dozens of blind-injection probes in parallel needs a way to know which specific parameter, on which specific request, caused a given callback to fire a minute later. Without per-payload correlation, a callback server is just a log of hits with no way to attribute any of them.

It also removes a step that used to be manual busywork. A hunter running their own standalone callback catcher against a handful of probes can usually keep track of which payload was which by hand. That stops being practical once a scanner is sending hundreds of OOB payloads across a full target, which is the normal case for an automated scan rather than a handful of manual tests.

What classes of bugs does this prove?

The same OOB listener backs proof for blind SQL injection, blind SSRF, XXE, and blind XSS. In each case the pattern is similar: the payload asks the target to reach out to an address under the listener's control, and the callback is the proof the injection point actually executed rather than just being reflected or ignored.

Blind XXE, for instance, gets an XML parser to resolve an external entity that points at the OOB domain; a stored blind XSS payload waits until it renders in someone else's browser, an admin dashboard being a common case, and phones home the moment it fires. Blind SQL injection can trigger a DNS lookup through a database function the injected query calls. All four rely on the same underlying idea: if the target reaches out, the listener sees it.

How this connects to Vexta's proof verdicts

Vexta's proof-of-exploitation engine marks every finding proven, refuted or unproven. A callback landing on the OOB listener is what turns a blind SSRF or blind XSS finding into proven rather than a guess. If the listener itself has a transient problem, offline or unreachable at the wrong moment, the finding lands as unproven, never refuted. That design choice means a network hiccup on the tester's own infrastructure can never be mistaken for evidence that a real bug doesn't exist.

Working safely within scope

OOB confirmation is exploitation-adjacent by nature: it asks a target's server to reach out to infrastructure the tester controls, which is meaningfully different from a payload that only echoes back in the same response. That is exactly why it belongs inside an authorized engagement's rules, whether that is a program's in-scope definition or a signed statement of work, rather than run against anything outside it. The callback itself is a non-destructive confirmation step: its only job is to prove a request happened, not to pivot further once it does.

Key takeaways

The essentials on Vexta's OOB callback server: