A payment processing API allows merchants to register a webhook URL: “When a payment succeeds, POST the transaction details to this URL.” The merchant registers their endpoint, and the API calls it on each event.
The API validates that the URL uses HTTPS and has a valid hostname. It does not check whether the hostname resolves to a private/internal IP address. It does not check whether the URL is on the same internal network as the API server.
http://internal-admin.company.internal/api/users. When a payment event fires, the API POSTs the event payload to the internal admin panel. The admin panel has no authentication requirement for internal callers. The API receives the response (user list) and, depending on implementation, may log it, return it in an error, or store it. The attacker has read the internal user database through the webhook response flow.Many SSRF defenses validate the URL hostname without resolving it. An attacker registers a domain they control (e.g., attacker.com) that resolves to an internal IP (e.g., 10.0.0.1). The hostname check passes (it’s not an internal IP). The actual HTTP request goes to 10.0.0.1. This is DNS rebinding — the fix is to resolve the hostname to an IP and validate the IP, not just the hostname string.