Webhook-url-http-3a-2f-2f169.254.169.254-2fmetadata-2fidentity-2foauth2-2ftoken !!hot!! Jun 2026

(169\.254\.169\.254).*(metadata|identity|oauth2|token)

: Applications that accept webhook URLs from untrusted sources (e.g., user input, third-party APIs) without validation become SSRF vectors. If an attacker can control the webhook URL, they can force the application to make requests to internal resources – including the metadata service.

Root causes * AWS EC2 Instance Metadata Service v1 (IMDSv1) Without Restrictions. AWS EC2 instances running with IMDSv1 enabled al... Metadata Security Protocol on Azure Instance Metadata ...

By understanding the mechanics of SSRF, recognizing encoded payloads, and implementing layered defenses (URL validation, network restrictions, least privilege, and monitoring), you can protect your cloud infrastructure from turning into an open token faucet. AWS EC2 instances running with IMDSv1 enabled al

Which (Azure, AWS, or GCP) hosts your application?

This approach is essential for understanding how to leverage the ARM token to explore further permissions or execute actions withi... Hunters Security

In Azure environments, attackers specifically target /metadata/identity/oauth2/token because the returned token often has broad permissions (e.g., Contributor on a subscription). Which (Azure, AWS, or GCP) hosts your application

http://169.254.169.254/metadata/identity/oauth2/token

The specific path in the keyword— /metadata/identity/oauth2/token —is the Azure-specific endpoint for fetching managed identity tokens. : The IMDS "magic" IP.

: Modern IMDS implementations require a specific HTTP header (like Metadata: true ) that cannot be easily forged in a simple SSRF attack. Ensure your cloud configurations enforce these requirements. To the untrained eye

This log entry represents a classic . While this specific attempt appears to target Azure, similar logic applies to AWS ( http://169.254.169.254/latest/meta-data/ ) and GCP. Immediate investigation is required to determine if the application processed this URL and if any tokens were leaked.

In the world of web application security, few attack vectors are as insidious—and as widely misunderstood—as Server-Side Request Forgery (SSRF). One particular pattern has emerged as a hallmark of sophisticated cloud-native attacks: a webhook URL pointing to the internal metadata service, often encoded as webhook-url-http-3A-2F-2F169.254.169.254-2Fmetadata-2Fidentity-2Foauth2-2Ftoken . This seemingly cryptic string decodes to http://169.254.169.254/metadata/identity/oauth2/token , a direct request to a cloud instance’s metadata endpoint to steal OAuth2 tokens.

Ensure that your application treats 169.254.169.254 as a protected internal IP. Do not forward responses from this endpoint to external users, as this would leak sensitive identity tokens.

To the untrained eye, it looks like a standard API endpoint. To a security professional, it represents a potential vulnerability that could lead to a full cloud environment takeover. What is 169.254.169.254?