# CVE-2026-40087: langchain-core — Fixed in 0.3.84 🐍 🐍 PyPI Not in CISA KEV MEDIUM severity # CVE-2026-40087 — langchain-core MEDIUM [Fix: langchain-ai/langchain@6bab0ba](https://github.com/langchain-ai/langchain/commit/6bab0ba3c12328008ddca3e0d54ff5a6151cd27b) CVE-2026-40087 is a medium-severity (CVSS 5.3) CWE-1336 vulnerability in langchain-core. A fix is available for langchain-core — see the affected versions and patch details below. LangChain has incomplete f-string validation in prompt templates Also known as[GHSA-926x-3r5x-gfhw](/vulnerability/GHSA-926x-3r5x-gfhw)PYSEC-2026-2563 Published Apr 9, 2026 Updated Oct 28, 2026 Affected 2 pkgs Patched 2 / 2 Exploits None indexed Exploitation data as of Nov 10, 2026 · OSV.dev, NVD, FIRST.org (EPSS) ## Exploitation Status ### No confirmed exploitation observed yet - CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks. - CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment. Exploitation and automatability from CISA’s SSVC triage for CVE-2026-40087. ## EPSS Exploitation Probability [via FIRST.org ↗](https://www.first.org/epss/) 0.3%probability of exploitation in next 30 days Lower Risk+0.01% Lower risk than most CVEs20th percentile — riskier than 20% of all scored CVEsHighest risk 0.00%0.32%0.64%0.95%0.1%0.3%May 26Sep 26Nov 26 Probability of exploitation in the next 30 days, from [FIRST.org EPSS](https://www.first.org/epss/). ## How urgent is this, really ## Where this sits among everything scored ## Real-World Exposure 2 pkgs affected 🐍`langchain-core`🐍`langchain-core` Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems. ## Description LangChain's f-string prompt-template validation was incomplete in two respects. First, some prompt template classes accepted f-string templates and formatted them without enforcing the same attribute-access validation as `PromptTemplate`. In particular, `DictPromptTemplate` and `ImagePromptTemplate` could accept templates containing attribute access or indexing expressions and subsequently evaluate those expressions during formatting. Examples of the affected shape include: ``` "{message.additional_kwargs[secret]}" "https://example.com/{image.__class__.__name__}.png" ``` Second, f-string validation based on parsed top-level field names did not reject nested replacement fields inside format specifiers. For example: ``` "{name:{name.__class__.__name__}}" ``` In this pattern, the nested replacement field appears in the format specifier rather than in the top-level field name. As a result, earlier validation based on parsed field names did not reject the template even though Python formatting would still attempt to resolve the nested expression at runtime. ### Affected usage This issue is only relevant for applications that accept untrusted template strings, rather than only untrusted template variable values. In addition, practical impact depends on what objects are passed into template formatting: - If applications only format simple values such as strings and numbers, impact is limited and may only result in formatting errors. - If applications format richer Python objects, attribute access and indexing may interact with internal object state during formatting. In many deployments, these conditions are not commonly present together. Applications that allow end users to author arbitrary templates often expose only a narrow set of simple template variables, while applications that work with richer internal Python objects often keep template structure under developer control. As a result, the highest-impact scenario is plausible but is not representative of all LangChain applications. Applications that use hardcoded templates or that only allow users to provide variable values are not affected by this issue. ### Impact The direct issue in `DictPromptTemplate` and `ImagePromptTemplate` allowed attribute access and indexing expressions to survive template construction and then be evaluated during formatting. When richer Python objects were passed into formatting, this could expose internal fields or nested data to prompt output, model context, or logs. The nested format-spec issue is narrower in scope. It bypassed the intended validation rules for f-string templates, but in simple cases it results in an invalid format specifier error rather than direct disclosure. Accordingly, its practical impact is lower than that of direct top-level attribute traversal. Overall, the practical severity depends on deployment. Meaningful confidentiality impact requires attacker control over the template structure itself, and higher impact further depends on the surrounding application passing richer internal Python objects into formatting. ### Fix The fix consists of two changes. First, LangChain now applies f-string safety validation consistently to `DictPromptTemplate` and `ImagePromptTemplate`, so templates containing attribute access or indexing expressions are rejected during construction and deserialization. Second, LangChain now rejects nested replacement fields inside f-string format specifiers. Concretely, LangChain validates parsed f-string fields and raises an error for: - variable names containing attribute access or indexing syntax such as `.` or `[]` - format specifiers containing `{` or `}` This blocks templates such as: ``` "{message.additional_kwargs[secret]}" "https://example.com/{image.__class__.__name__}.png" "{name:{name.__class__.__name__}}" ``` The fix preserves ordinary f-string formatting features such as standard format specifiers and conversions, including examples like: ``` "{value:.2f}" "{value:>10}" "{value!r}" ``` In addition, the explicit template-validation path now applies the same structural f-string checks before performing placeholder validation, ensuring that the security checks and validation checks remain aligned. ## Affected Packages 2 total 2 fixed Ecosystem Package Vulnerable range Fix 🐍PyPI `langchain-core` all versions 0.3.84`pip install --upgrade 'langchain-core==0.3.84'` 🐍PyPI `langchain-core` ≥ 1.0.0a1&&< 1.2.28 1.2.28`pip install --upgrade 'langchain-core==1.2.28'` ## Affected Products 1 product · 2 configurations Application `langchain core`langchain ≥ 1.0.0 && < 1.2.28 range ## Detection & mitigation playbook Open-source dependency 1. ### Detect Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for langchain-core, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version. 2. ### Fix Update langchain-core to 0.3.84 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-40087 is resolved across your whole dependency graph. 3. ### Workarounds Do not deserialise data from untrusted sources: where the format allows it, restrict deserialisation to an explicit allowlist of expected types, and prefer a data-only format (JSON, Protobuf) over one that can reconstruct arbitrary objects until you can upgrade. ## Fixing This On Your OS If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project. Red HatModerate To exploit this vulnerability, an attacker needs to supply a specially crafted input to the \`DictPromptTemplate\` or \`ImagePromptTemplate\` classes. The payload must contain Python attribute access expressions (e.g., accessing internal object classes), which bypass the template validator and get executed by the… Workaround published by Red Hat > To mitigate this vulnerability, validate and sanitize any user-supplied input before it is passed into a DictPromptTemplate or ImagePromptTemplate. Reject any input containing curly braces unless they are strictly necessary and controlled. Furthermore, strip or reject input strings that attempt to use nested replacement fields (e.g., fields hidden within format specifiers like {value:{nested\_format}}). Source: [Red Hat security advisory for CVE-2026-40087](https://access.redhat.com/security/cve/cve-2026-40087) (CC BY 4.0) ## Frequently Asked Questions LangChain's f-string prompt-template validation was incomplete in two respects. First, some prompt template classes accepted f-string templates and formatted them without enforcing the same attribute-access validation as \`PromptTemplate\`. In particular, \`DictPromptTemplate\` and \`ImagePromptTemplate\` could accept templates containing attribute access or indexing expressions and subsequently evaluate those expressions during formatting. Examples of the affected shape include: \`\`\`python "{message.additional\_kwargs\[secret\]}" "https://example.com/{image.\_\_class\_\_.\_\_name\_\_}.png" \`\`\` Second, f-st O3 Security · Impact-Aware SCA ### Is CVE-2026-40087 in your dependencies? Find it across PyPI, including transitive dependencies. [Scan my dependencies](/book-demo) [How O3 SCA works](/impact-aware-sca)