Webhook-url-http-3a-2f-2f169.254.169.254-2fmetadata-2fidentity-2foauth2-2ftoken Link
The provided string webhook-url-http-3A-2F-2F169.254.169.254-2Fmetadata-2Fidentity-2Foauth2-2Ftoken decodes to a URL targeting the Azure Instance Metadata Service (IMDS). This is a high-severity security finding indicative of a Server-Side Request Forgery (SSRF) attack attempt, specifically aimed at cloud credential theft.
If you see strings like this in your ingress logs (incoming webhook requests), you are likely being actively scanned or attacked.
Here is how to lock it down:
1. Patch SSRF Vulnerabilities
2. Harden the Metadata Service
3. Network Controls
If your system accepts webhook URLs from users, you are vulnerable. Here is the fix: The provided string webhook-url-http-3A-2F-2F169
1. Implement an Allowlist
Do not allow arbitrary IPs. Only allow outbound requests to known SaaS vendor IPs (e.g., slack.com, github.com). Never allow 169.254.0.0/16.
2. Filter Private IPs (The Code Fix) Before making any webhook request, validate the URL:
# Dangerous: Do not do this.
# requests.get(user_provided_webhook_url)
The string you provided is an obfuscated representation of a sensitive internal URL. %2F = / )
When decoded from URL encoding (%3A = :, %2F = /), it becomes:
http://169.254.169.254/metadata/identity/oauth2/token
This is not a generic webhook URL. It is the Instance Metadata Service (IMDS) endpoint used exclusively by cloud providers like Microsoft Azure. 2. Harden the Metadata Service