SSRF File Scheme Local File Read
AI agents that can fetch URLs sometimes accept the file:// scheme or raw file paths, letting an attacker trick the agent into reading files off the local disk instead of the web. This turns a URL-fetching feature into a tool for stealing secrets, credentials, or SSH keys from the machine the agent runs on.
How the attack works
An attacker supplies input to an agent's HTTP-fetch or URL-retrieval tool, but instead of a normal http:// or https:// address, they give a file:// URI or a bare absolute path like /etc/passwd. If the underlying HTTP client or tool does not restrict schemes, it treats this as a valid request and reads the file from disk. The attacker gets the contents returned as if it were fetched web content, exposing files such as /etc/shadow, SSH private keys, or config files with embedded secrets. This bypasses network-layer SSRF protections because no actual network request is made — the read happens locally.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 56813cd4-d089-4d49-8b12-136621d488bf
- Severity
- Critical
Why it matters
An organization can lose credentials, private keys, and configuration secrets stored on the host running the agent, giving the attacker a foothold for further compromise without ever touching the network.
What you can do
- →Restrict any URL-fetching tool to explicit allow-listed schemes (http/https only) and reject file://, ftp://, and other non-web schemes.
- →Reject or normalize inputs that look like absolute filesystem paths before passing them to fetch-style tools.
- →Run agents with least-privilege filesystem access so even a successful file read exposes little.
- →Review logs for fetch requests containing file:// or absolute paths, and confirm any legitimate local-file-reading agents are scoped to specific directories only.
Known benign look-alikes
- Local documentation agents explicitly permitted to read project files
- Filesystem agents with scoped read access to specific directories