LangChain Prompt Template Injection - CVE-2026-40087
CVE-2026-40087 is a LangChain prompt template injection in langchain-core, rated Moderate, where unsafe f-string handling lets a crafted template string leak internal object state and sensitive data into the prompt and into logs. This is not remote code execution - it is improper input validation (CWE-20) plus template-engine injection (CWE-1336) in the way LangChain assembles prompts. It affects langchain-core below 0.3.83 and the 1.x line from 1.0.0a1 up to 1.2.28, and is fixed in langchain-core 0.3.84 and 1.2.28. This advisory covers what happened, why prompt templates are an agentic-endpoint risk, and how Anomity surfaces and governs the agents built on this framework.
What happened
LangChain prompt templates are how an agent turns variables into the final text sent to a model. The default f-string templates interpolate named fields against a dictionary of values, and langchain-core validates those templates to reject expressions that do more than a simple field lookup. That validation failed to catch two unsafe patterns, so a template string that should have been rejected was formatted instead.
First, DictPromptTemplate and ImagePromptTemplate accepted templates using attribute access without proper validation. A field such as {message.additional_kwargs[secret]} was allowed through, so the expression executes during formatting and can reach into the internal state of whatever object was passed in. PromptTemplate is also in scope. Second, the validation missed nested replacement fields hidden inside a format specifier rather than the top-level field name - for example {name:{name.__class__.__name__}}, where the malicious expression hides in the specifier portion. When untrusted template strings are combined with richer Python objects during formatting, an attacker can traverse internal attributes and pull sensitive data into the prompt.
undefinedThe impact is data exposure, not code execution. The crafted expression walks object attributes and surfaces values the template author never intended, which then land in the prompt sent to the model and, in most deployments, in the application logs that record the rendered prompt. The fix in langchain-core 0.3.84 and 1.2.28 tightens f-string validation so both patterns are rejected before formatting runs.
| Detail | Value |
|---|---|
| Identifier | CVE-2026-40087 (GHSA-926x-3r5x-gfhw) |
| Type | Prompt-template injection via unsafe f-string handling (data leak, not RCE) |
| Weakness | CWE-20 improper input validation; CWE-1336 template-engine injection |
| Package | langchain-core (pip) |
| Severity | Moderate |
| Affected | < 0.3.83 and >= 1.0.0a1, < 1.2.28 |
| Fixed in | 0.3.84 and 1.2.28 |
Why this is an agentic-endpoint risk
Prompt templates are exactly where an agent joins untrusted input to the instructions it sends a model. A retrieval result, a tool output, a user message, or a file the agent read can all end up as a template variable, and in the vulnerable versions any of those values - or the template string itself - can carry an expression that traverses object state. That makes this a LangChain prompt template injection in the core of the agent framework, not a bug in one application's glue code.
The failure mode is a data-leak-to-prompt-and-logs problem rather than a crash or a shell. It sits squarely in the broader prompt-injection theme: untrusted content steering what the model sees. If you are mapping that theme across your agents, the mechanics here pair with indirect prompt injection, where poisoned content the agent reads becomes an instruction, and with the lethal trifecta of AI agent data exfiltration, where private data, untrusted input, and an outbound channel combine into a leak. This CVE supplies the first two of those ingredients inside the framework itself.
It is also one of several recent issues in the same stack. See the sibling advisories on LangChain unsafe deserialization - CVE-2026-44843, the LangSmith SDK file read - GHSA-f4xh-w4cj-qxq8, and the Flowise Airtable agent code injection - CVE-2026-41265. Network and DLP controls may see the model call or a suspicious log line, but they cannot tell you which endpoints run an affected langchain-core, which agents build prompts from untrusted input, or whether a coding agent on a developer laptop pulled the vulnerable version transitively - the same blind spot we cover in securing AI coding agents and CLIs. You can't govern what you can't see, and fleet-wide inventory of every AI artifact is the precondition for scoping this.
How Anomity surfaces and governs it
Anomity inventories eight AI artifact types on every managed endpoint: AI agents, MCP servers, extensions, skills, plugins, secrets, hooks, and CLIs. For CVE-2026-40087 that means the agents built on LangChain, and the CLIs and hooks around them, are catalogued from the fleet inventory, so you can answer "which endpoints run agents on an affected framework build, and what feeds their prompts" instead of guessing from a top-level dependency file.
On agents that expose a hook, such as Claude Code PreToolUse, Anomity returns allow, deny, or log on each tool call before it runs. That is the enforcement point in runtime governance: a tool call that would feed untrusted content into a prompt-building path can be denied or logged in line rather than discovered after sensitive object state has already been rendered into a prompt and a log. Anomity collects metadata only and redacts secrets on the endpoint, so the values an injection tries to surface never pass through Anomity.
Every decision is written to a queryable 90-day audit trail. After a disclosure like this, that trail is what lets responders scope the event: which agents built prompts from untrusted input, when, and on which endpoints. Anomity routes those decisions to SIEM, Slack, email, or Jira so the right team sees them in the tool they already use, which is the timeline and enforcement record described under outcomes. Anomity complements your existing Network, EDR, DLP, and GRC controls rather than replacing them - see how it works and how Anomity compares for where it fits.
What to check across your fleet
- Resolve the actually-installed langchain-core version on every endpoint and service; treat anything below 0.3.83, or from 1.0.0a1 up to but not including 1.2.28, as affected, including transitive installs.
- Upgrade to langchain-core 0.3.84 or 1.2.28 and confirm the running interpreter loads the fixed version rather than a cached older one.
- Find every place your agents build a PromptTemplate, DictPromptTemplate, or ImagePromptTemplate from untrusted input, and stop untrusted strings from being used as template text.
- Prefer passing untrusted content as template values rather than as the template itself, and format templates against plain data instead of rich objects that expose internal attributes.
- Review application and agent logs that capture rendered prompts for leaked object state or sensitive values, and tighten what gets logged around prompt assembly.
- Enumerate which AI agents, CLIs, and MCP servers construct prompts from retrieval results, tool output, or user input, using a fleet-wide AI artifact inventory.
- Confirm hook-based allow/deny/log enforcement is active on agents that expose a hook, so a tool call feeding untrusted content into a vulnerable prompt path can be blocked before it runs.
CVE-2026-40087 turns a prompt template into a channel for leaking internal object state into prompts and logs, which is exactly why the AI artifact layer needs its own inventory and enforcement. For the full cluster context, see the pillar on securing AI agent frameworks. To see Anomity inventory your agents, govern tool calls at the hook, and keep a 90-day audit trail, request early access.
Frequently asked questions
Is CVE-2026-40087 a remote code execution flaw?
No. This is prompt-template injection through unsafe f-string handling, not remote code execution. The flaw lets a crafted template string traverse the attributes of Python objects passed into formatting, which can expose internal object state and sensitive data into the assembled prompt and into any logs that capture it. It does not, on its own, give an attacker arbitrary command execution on the host. Treating it as data exposure rather than RCE keeps your triage accurate: the priority is to stop untrusted template strings from reaching langchain-core formatting and to upgrade to a fixed release, langchain-core 0.3.84 or 1.2.28, so the validation rejects these expressions.
Which versions of langchain-core are affected?
Two ranges are affected: langchain-core below 0.3.83, and the 1.x pre-release and release line from 1.0.0a1 up to but not including 1.2.28. The issue is fixed in langchain-core 0.3.84 and in 1.2.28. Because langchain-core is a transitive dependency pulled in by many agent stacks, the affected version can be present even where a team never installed LangChain directly. Resolve the actually-installed version on each endpoint rather than trusting a top-level requirements file, then upgrade to a fixed release and confirm the running interpreter picked it up.
How would an attacker exploit a LangChain prompt template?
The template string is the injection point. LangChain f-string validation failed to reject two unsafe patterns: attribute access such as a field that reads additional_kwargs on a message object, and nested replacement fields hidden inside a format specifier rather than the top-level field name. When an application builds a PromptTemplate, DictPromptTemplate, or ImagePromptTemplate from untrusted input and formats it against richer Python objects, the crafted expression executes during formatting and can walk internal attributes to pull out sensitive values. The result lands in the prompt sent to the model and often in application logs, which is where the data leak actually happens.
How does Anomity help when an agent framework like LangChain is vulnerable?
Anomity treats the agent and the framework it runs on as AI artifacts on the endpoint, so it inventories which agents are present, what drives them, and the CLIs and hooks around them. On agents that expose a hook, such as Claude Code PreToolUse, Anomity returns allow, deny, or log on each tool call before it runs, so a tool call that would feed untrusted content into a vulnerable prompt path can be denied or logged in line. Every decision lands in a queryable 90-day audit trail, and Anomity collects metadata only and redacts secrets on the endpoint, so the sensitive values an injection tries to surface never pass through Anomity.
