An API implements OAuth 2.0 social login via a third-party identity provider. During the OAuth flow, the API makes server-side requests to the identity provider’s endpoints to exchange authorization codes for tokens and to fetch the user’s profile data.

The API’s SSRF protection blocks user-supplied URLs that resolve to private IP ranges. But requests to the identity provider’s well-known endpoints — https://identity.provider.example.com/userinfo — are exempt from this validation because they are trusted third-party calls.

An attacker gains control of a subdomain of the identity provider (through a misconfigured DNS record or subdomain takeover). They set up a server at oauth.identity.provider.example.com that returns an HTTP 302 redirect pointing to http://169.254.169.254/latest/meta-data/iam/security-credentials/app-role. The consuming API follows the redirect — trusting that anything returned by the identity provider domain is safe — and receives IAM credentials from the AWS metadata service. The SSRF validation that would have blocked a user-supplied URL never fires for a redirect from a trusted source.