LangChain Vulnerabilities: When Your Agent Framework Leaks Your API Keys

LangChain is the most widely-used framework for building AI agents. With over 100,000 GitHub stars and adoption across thousands of production applications, it's the foundation of the agent ecosystem. That makes its security vulnerabilities everyone's problem.

In 2024 and 2025, two critical CVEs demonstrated that LangChain's architecture could be exploited to extract API keys, environment variables, and other secrets from the host system. Both vulnerabilities were enabled by the same attack pattern: prompt injection targeting credential access.

CVE-2024-28088: directory traversal to API key disclosure

Disclosed in March 2024, CVE-2024-28088 affected LangChain through version 0.1.10. The vulnerability exploited three core LangChain functions: load_chain, load_prompt, and load_agent.

These functions were designed to load chain, prompt, and agent configurations from the hwchase17/langchain-hub repository — a curated collection of reusable LangChain components. The intended security model was a sandbox: configurations could only be loaded from within the trusted hub directory.

The vulnerability was a classic directory traversal. By crafting paths with ../ sequences, attackers could bypass the sandbox and load arbitrary files from the file system. This enabled two attack vectors:

The vulnerability was patched in LangChain 0.1.11 by adding proper path validation to the loading functions. But the fix addressed the symptom, not the cause: LangChain applications still routinely hold API keys in environment variables that are accessible to the running process — and by extension, to any code the framework executes.

CVE-2025-68665: serialization injection for secret extraction

Disclosed in December 2025, CVE-2025-68665 targeted the LangChain JavaScript/TypeScript library with a more sophisticated attack: serialization injection via LLM responses. This vulnerability is particularly alarming because the attack vector is the LLM output itself — exactly the channel that agents process by design.

The attack exploits LangChain's serialization format. LangChain JS uses a structured serialization scheme for objects:

When LangChain encounters an object with "type": "secret", it interprets the id array as a reference to an environment variable and resolves it. The attack works by injecting this payload into the LLM's response through the additional_kwargs field — a pass-through property that LangChain uses to carry model-specific metadata alongside the main response.

The attack chain works as follows:

• 1.An attacker crafts a prompt injection — either in user input, a document being processed, or a tool response — that causes the LLM to include the serialized secret reference in its additional_kwargs
• 2.LangChain processes the LLM response and encounters the serialized object
• 3.The deserialization logic resolves {"type": "secret", "id": ["OPENAI_API_KEY"]} by reading the OPENAI_API_KEY environment variable
• 4.The resolved value is now in the application's data flow, where it can be exfiltrated through subsequent LLM calls, tool invocations, or logged outputs

The severity rating was HIGH, as documented in GitHub Security Advisory GHSA-r399-636x-v7f6. Any environment variable on the host system could be targeted — not just LangChain's own API keys, but database credentials, cloud provider secrets, OAuth tokens, and any other secret stored in the environment.

The common thread: prompt injection + credential access

Both CVE-2024-28088 and CVE-2025-68665 share a common attack pattern: an attacker uses prompt injection to reach credentials that are accessible to the agent framework. The specifics differ — directory traversal vs. serialization injection — but the root cause is identical: the agent process has access to secrets, and the LLM can be manipulated to exploit that access.

This pattern is not unique to LangChain. It's a fundamental property of any agent architecture where:

• a.The agent process can access credentials (environment variables, config files, secret stores)
• b.The LLM can influence what code or operations the framework executes
• c.The LLM processes untrusted input (user messages, documents, tool responses)

If all three conditions are true — and they are for virtually every production agent — prompt injection can be used to extract credentials. The only question is how creative the attack needs to be. These LangChain CVEs prove that it doesn't need to be very creative at all.

Why patching isn't enough

LangChain's team responded quickly to both vulnerabilities. CVE-2024-28088 was fixed in 0.1.11 with path validation. CVE-2025-68665 was addressed with stricter deserialization checks. But these are point fixes for a systemic problem.

The LangChain ecosystem has hundreds of integrations, each with its own credential handling patterns. Every integration is a potential attack surface for credential extraction. Fixing one path traversal or one deserialization flaw doesn't address the thousands of code paths where credentials are read from the environment and potentially exposed to LLM-influenced operations.

As long as agents run in processes that hold credentials, new attack vectors will continue to emerge. The cat-and-mouse game of patching individual vulnerabilities cannot keep pace with the creative potential of prompt injection attacks.

The architectural fix

The LangChain vulnerabilities demonstrate a clear principle: if the agent process can access a credential, a prompt injection attack can eventually extract it. The only defense that eliminates this class of vulnerability entirely is removing credentials from the agent's reach.

Lessons for the agent ecosystem

The LangChain CVEs are a microcosm of the broader agent security challenge. As agent frameworks become more powerful — with more integrations, more tools, and more autonomous decision-making — the attack surface for credential extraction grows proportionally.

Each new tool integration adds environment variables. Each new API connector adds credential handling code. Each new deserialization path adds potential for injection. The complexity is unbounded, and the security team's ability to audit every path is not.

The frameworks themselves are not to blame. LangChain, like every agent framework, operates under the same constraint: the current model requires agents to hold credentials. Until that constraint is removed, vulnerabilities like CVE-2024-28088 and CVE-2025-68665 will keep appearing — in LangChain, in competing frameworks, and in every custom agent implementation.

The safest credential is the one your agent never sees. Not in environment variables. Not in config files. Not in serialized objects. Nowhere in the process. That's not a workaround — it's the only architecture that scales.