Slide 13 · Attack Pattern 4 of 4
The LLM generates a URL or a file path. The server fetches it blindly.
SSRF and path traversal via LLM output — the internal-network edition.
SSRF via LLM-Generated URLs
Some LLM applications fetch URLs that the model generates or suggests. If the server makes those requests without validating the destination, an attacker can steer the LLM to produce an internal URL — like a cloud metadata endpoint. The server fetches it from inside the network. The attacker receives internal credentials.
"Summarize: http://169.254.169.254/latest/meta-data/iam/security-credentials/"
Path Traversal via LLM-Generated File Paths
If an LLM generates or suggests file paths that the application uses with open() or read(), an attacker can inject traversal sequences. The LLM produces a path like ../../../../etc/passwd and the application opens it, returning the OS password file.
OWASP Documented Scenario
Cloud Metadata Exfiltration via Prompt-Controlled Fetch
OWASP LLM05:2025 Official Scenario · Corroborated by AWS & GCP Security Research
OWASP documents this as a confirmed risk pattern: attacker crafts input that causes an LLM-powered summarization or retrieval feature to generate a request to http://169.254.169.254/ (AWS) or http://metadata.google.internal/ (GCP). The server, running inside the cloud environment, fetches its own metadata and returns temporary IAM credentials. The attacker now has cloud API access with whatever permissions the service role holds. Impact: full cloud account compromise if the role has broad permissions.
Takeaway: Blocklist or allowlist every URL your application fetches — whether it came from a user or an LLM. The source doesn’t make it safe.