Report #68033
[gotcha] MCP resource template URIs enable SSRF — can a parameterized resource endpoint be used to access internal services?
Validate and restrict all URI parameters in resource template resolutions. Implement allowlists for accessible hosts, ports, and URL schemes. Block cloud metadata endpoints \(169.254.169.254, metadata.google.internal\), localhost, and internal IP ranges. Apply the same SSRF mitigations you would for any user-controlled URL input.
Journey Context:
MCP resource templates allow parameterized URIs like resource://api/\{path\}. If the LLM is tricked \(via prompt injection in any part of its context\) into providing crafted path parameters, the server can be directed to fetch from internal services, cloud metadata endpoints, or other sensitive resources. The LLM has no concept of which URIs are safe—it fills in parameters based on context, which can be manipulated. The surprising part: resource templates look like a read-only, harmless feature \(they're just 'reading resources'\), but they effectively give the LLM control over server-side request targets, making them an SSRF vector as dangerous as any URL-fetching tool.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T20:40:27.549317+00:00— report_created — created