SSRF to Cloud Metadata Endpoint via Wildcard-DNS Hostname-Encoded IP (nip.io/sslip.io/xip.io/traefik.me)
An AI agent's web-fetching tool can be tricked into contacting the cloud metadata service (169.254.169.254) by hiding that address inside a hostname from a wildcard-DNS service like nip.io. The tool's security check only looks at the hostname text, sees a normal-looking public domain, and lets the request through—never noticing that the domain actually resolves to the forbidden metadata address.
How the attack works
An attacker gives an agent's fetch/browse tool a URL such as 169-254-169-254.nip.io instead of the raw IP address. The tool's SSRF guard checks the hostname string against a blocklist of known private or metadata addresses, and since '169-254-169-254.nip.io' isn't on that list, the check passes. The tool then performs the actual HTTP request, and DNS resolves that hostname to 169.254.169.254 exactly as the wildcard-DNS service is designed to do. The request reaches the real cloud metadata endpoint, letting the attacker pull cloud credentials or instance data that should never be reachable from that tool.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- f704492d-0731-49a1-bf85-ba8aec5cef75
- Severity
- High
Why it matters
Successful use of this bypass can expose cloud instance credentials, identity tokens, or configuration data from AWS/GCP/Azure/DigitalOcean metadata services, giving an attacker a path to further compromise of the cloud account or infrastructure.
What you can do
- →Make any SSRF/URL-allowlist check resolve DNS and validate the resulting IP address, not just the hostname string, before the tool makes its request.
- →Block outbound requests to 169.254.169.254 (and equivalent metadata addresses) at the network or proxy layer for any process running agent tools.
- →Where cloud metadata access is legitimately needed, use provider-specific mechanisms (IMDSv2 hop-limit, metadata firewall rules) instead of relying on application-level hostname filtering.
- →Review logs of fetch/browse tool calls for hostnames from nip.io, sslip.io, xip.io, traefik.me, or similar services, especially ones encoding 169.254.169.254.
Known benign look-alikes
- A nip.io/sslip.io/xip.io/traefik.me hostname encoding the requester's own loopback address (127.0.0.1) or an RFC1918 private-network IP (10.x/172.16-31.x/192.168.x) -- deliberately excluded from this rule's scope after adversarial testing showed private-range-via-wildcard-DNS is a common, legitimate local Kubernetes/Vagrant/Docker dev-cluster TLS-testing pattern, not a reliable attack signal on its own
- A nip.io/sslip.io/xip.io/traefik.me hostname encoding a public (non-169.254.169.254) IP address, e.g. a public demo/staging server -- the documented, intended use of these services
- Documentation or tutorials explaining how wildcard-DNS services work using the metadata IP purely as a textbook example, without an actual tool fetching the URL