SSRF via Non-IP Internal Hostname or Domain-Allowlist Authority Bypass
Attackers can trick AI agents that fetch web content into sending requests to attacker-controlled or internal servers, without ever using a raw IP address. This bypasses security filters that only look for private IP patterns like 127.0.0.1 or 169.254.x.x.
How the attack works
An attacker crafts a URL that looks trustworthy but isn't, using two tricks: putting a real trusted domain before an '@' symbol so the actual destination is whatever follows (https://docs.apify.com@evil.com), or appending a trusted domain as a subdomain prefix of an attacker domain (https://docs.apify.com.evil.com). A naive allowlist check that only tests whether a URL starts with a trusted domain string is fooled by both. Separately, an attacker plants a fake 'BASE URL:' instruction inside content the AI agent reads (a prompt injection), pointing the agent's next HTTP request at an internal-only hostname like host.docker.internal, kubernetes.default.svc, or something ending in .internal/.corp/.local. Because these are hostnames, not IP addresses, IP-pattern-based SSRF defenses miss them entirely.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 3f4b51f1-7259-4de2-816c-b9120071f925
- Severity
- High
Why it matters
An AI agent can be redirected into leaking fetched content to an attacker server, or into probing/hitting internal services and infrastructure endpoints that should never be reachable from agent-driven requests.
What you can do
- →Replace startsWith()-style domain allowlist checks with proper URL parsing that validates the actual host component, not a string prefix.
- →Reject or flag URLs containing userinfo (an '@' before the host) unless explicitly required and validated.
- →Block or resolve-check hostnames matching internal naming conventions (host.docker.internal, kubernetes.default(.svc), *.internal, *.corp, *.local) before any agent-initiated fetch.
- →Treat any 'BASE URL:' or similar directive found inside fetched/untrusted content as data, not as an instruction the agent should act on.
Known benign look-alikes
- A legitimate basic-auth URL where the userinfo component is a plain username/token without two or more dots (this rule only fires when the pre-@ segment itself looks like a spoofed multi-label domain)
- Internal documentation or runbooks that mention host.docker.internal or *.internal hostnames in prose without an actual 'BASE URL:' directive being parsed by a live API-chain tool