Report #7943
[gotcha] MCP resource URIs allow path traversal to read arbitrary files on the server host
Validate and normalize all resource URIs before resolving them on the filesystem. Reject URIs containing '..' sequences, symbolic links that escape the allowed directory, or URL-encoded traversal patterns \(%2e%2e, %2f\). Implement an allowlist of permitted resource URI prefixes and chroot all file access to a sandboxed directory. Never pass raw URIs directly to filesystem read operations.
Journey Context:
MCP servers expose resources via URI schemes \(e.g., 'file:///path/to/resource'\). When an LLM requests a resource, it provides a URI that the server resolves. If the server does not properly validate the URI, an attacker — via prompt injection — can craft URIs like 'file:///etc/passwd' or 'file:///home/user/../../../etc/shadow' to read arbitrary files. The gotcha is that developers often implement resource handlers by directly mapping URIs to filesystem paths without sanitization, because the URIs 'come from the LLM' and feel like internal, trusted inputs. But the LLM is following instructions from potentially untrusted sources \(user messages, tool results, tool descriptions\), so the URIs it requests are effectively attacker-controlled. This is SSRF via the LLM: the agent is the confused deputy that makes the request on the attacker's behalf.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T04:12:29.255272+00:00— report_created — created