# LangChain Prompt Loader Arbitrary File Read (Instance-Resolved)

- **Severity:** Medium
- **Signature ID:** `7c1f3a5e-9b62-4d18-a0e7-5f3c8d2b4a91`

## Summary

LangChain's prompt-loading helpers can be tricked into opening files far outside the folder a prompt configuration lives in. This rule spots the file-access pattern that traversal produces 
e,,, the moment a process reads a prompt/template file and then, seconds later, reads a second file elsewhere with an extension the loader still accepts.

## How the attack works

An attacker supplies or tampers with a prompt configuration (for example JSON or YAML) that sets path fields like template_path or example_prompt_path to a traversal string or an absolute path. When the application calls load_prompt(), the loader reads its own config file first, then follows those unchecked path fields to open a second file. Because the loader only checks the file extension \.txt, .json, .yaml, .yml\ and never checks the directory, it will happily open credential files or other sensitive data as long as the extension matches. The rule flags this two-step pattern: same process, first reads a loader-style config, then within 10 seconds reads a second file with a permitted extension that sits outside the first file's directory tree.

## Why it matters

If exploited, this lets an attacker read arbitrary files reachable by the application process fcloud credentials, Kubernetes secrets, SSH/docker/gh configs disguised as a legitimate prompt load, potentially leaking credentials or other sensitive data without any obvious error.

## What you can do

- Validate and canonicalize all path fields (template_path, prefix_path, suffix_path, examples, example_prompt_path) in prompt configs before loading, rejecting anything that resolves outside the expected config directory.
- Load prompt configurations only from trusted, version-controlled sources; never deserialize prompt configs supplied by end users or external systems.
- Run LangChain services with least-privilege filesystem access so even a successful traversal cannot reach credential files or secret mounts.
- Treat this rule's alerts as investigative leads, not confirmed compromises, since legitimate startup sequences (e.g., reading a Kubernetes projected secret or cloud SDK credentials right after a prompt load) can also match.

## Known benign look-alikes

- A LangChain service running in Kubernetes that loads prompts/agent.yaml and, within the same 10-second startup burst, legitimately reads its projected service-account or secret volume under /var/run/secrets/ or /run/secrets/.
- A GCP-hosted LangChain application where google-auth resolves Application Default Credentials (~/.config/gcloud/application_default_credentials.json) immediately after the first prompt template load.
- A Python worker that reads a chain/template config and then initialises the docker or kubernetes SDK, which opens ~/.docker/config.json or ~/.kube/*.yaml.
- Repository test suites whose fixture layout places prompt fixtures and credential-shaped fixtures (credentials.json, secrets.yaml) in sibling trees.
- Ansible or Vault tooling invoked from the same interpreter that just parsed a prompt YAML, reading vault.yml outside the prompt directory.

## References

- https://python.langchain.com/api_reference/core/prompts/langchain_core.prompts.loading.load_prompt.html
- https://owasp.org/Top10/A01_2021-Broken_Access_Control/
- https://owasp.org/Top10/A03_2021-Injection/

---
Source: https://www.netzilo.com/threats/langchain-prompt-loader-path-traversal