Cloudanix VulnDB

CVE-2026-40087

Medium · 5.3

CVSS

5.3

EPSS

0.5%

Published

Apr 9, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

Some LangChain applications may let a crafted prompt template reveal information from the application that users were not supposed to access.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Data Exposure
Component
Library
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

LangChain versions before 0.3.84 and before 1.2.28 incompletely validate f-string prompt templates. Certain template classes, notably DictPromptTemplate and ImagePromptTemplate, could accept templates containing attribute-access or indexing expressions that PromptTemplate would normally reject, and nested replacement fields inside format specifiers could bypass validation because only top-level parsed field names were checked. When these templates are later formatted, Python formatting may resolve object attributes, dictionary keys, list indexes, or nested format-specifier fields at runtime. The primary technical impact is unintended read access to data reachable from objects supplied to prompt formatting, such as object internals, configuration values, secrets present in dictionaries, or application state exposed through template variables. The published CVSS indicates low confidentiality impact with no direct integrity or availability impact, and there is no public exploit maturity indicated in the provided data.

Why it matters to the business

Applications that allow users, integrations, agents, plugins, or stored content to influence LangChain prompt templates may unintentionally expose sensitive application data to an attacker or to an LLM response. This can lead to leakage of configuration details, internal object state, credentials embedded in prompt variables, customer or workflow data, or other information that developers assumed was not addressable by a prompt template. The risk is highest in LLM applications that support user-created templates, dynamic prompt composition, retrieval-augmented workflows, agent tool outputs, or multi-tenant prompt customization. Although this is not currently listed in CISA KEV, has low EPSS, and no known exploit maturity in the supplied data, LangChain is widely used in LLM application stacks, so affected dependencies may be pulled in transitively through many downstream projects.

How an attack unfolds

An attacker first needs a path to supply or modify an f-string prompt template that is later processed by an affected LangChain component. This could be through a prompt-authoring feature, workflow builder, chatbot configuration, agent instruction store, plugin integration, API parameter, or any application logic that treats external content as a LangChain prompt template. The attacker crafts a template that uses attribute access, indexing, or a nested replacement field inside a format specifier rather than a simple variable reference. Because vulnerable validation does not consistently reject these constructs in DictPromptTemplate, ImagePromptTemplate, or nested format-specifier cases, the malicious template can be accepted. When the application formats the prompt, Python’s formatting machinery resolves the referenced attribute or indexed value from objects provided to the template. If those objects contain sensitive fields or references to configuration/state, the resulting prompt may include data the attacker was not intended to see. The attacker then retrieves the leaked value from the application response, model output, logs, generated image prompt content, or another downstream artifact that contains the rendered prompt.

How to fix it

Upgrade LangChain to a fixed release: use version 0.3.84 or later on the 0.3.x line, or version 1.2.28 or later on the 1.x line. Ensure all dependency manifests, lockfiles, container images, notebooks, serverless packages, and agent/runtime images are rebuilt so the fixed LangChain package is actually deployed. If immediate upgrade is not possible, do not allow untrusted users or external integrations to provide f-string prompt templates; restrict prompt templates to a vetted allowlist; reject templates containing attribute access, indexing, conversion flags, or nested replacement fields; and prefer safer template formats that only support explicit variable substitution. Avoid passing rich objects, application clients, configuration objects, secrets, request objects, or environment-derived dictionaries into prompt-formatting contexts; pass only minimal primitive values required for the prompt. Review custom prompt-template wrappers and subclasses to ensure they apply the same validation rules as the fixed LangChain implementation.

How to confirm the fix worked

Confirm the running package version with package inventory tooling, lockfile review, container image inspection, or runtime checks such as `python -c "import langchain; print(langchain.__version__)"` where applicable. Validate that deployed versions are 0.3.84 or later, or 1.2.28 or later. Review dependency trees for transitive LangChain installations and ensure no older copy is bundled in application images or notebooks. Functionally test prompt-template handling by attempting to submit templates with attribute access, indexing, and nested replacement fields in format specifiers; fixed or mitigated systems should reject or safely handle these constructs before formatting. Also confirm that prompt-rendering contexts no longer contain secrets, configuration objects, API clients, request/session objects, or other rich objects that could disclose sensitive state if referenced.

Typical attack path

  1. Identify an application feature or API that accepts, stores, imports, or composes LangChain f-string prompt templates.
  2. Determine whether the application uses affected LangChain versions before 0.3.84 or before 1.2.28 and whether DictPromptTemplate, ImagePromptTemplate, or similar f-string formatting paths are reachable.
  3. Submit a crafted template containing attribute access, indexing, or a nested replacement field in a format specifier.
  4. Cause the application to render or execute the prompt with objects, dictionaries, or context variables that contain sensitive data.
  5. Observe the rendered prompt, LLM response, logs, trace output, image prompt, or workflow result for leaked values.
  6. Iterate on field names and object paths to discover additional accessible data.

How to detect it

There are no supplied reports of known exploitation, but prior exploitation can be investigated by reviewing places where prompt templates are accepted, stored, logged, or rendered. Examine application logs, API request logs, prompt-management audit logs, LangChain callback traces, LLM observability platforms, workflow-builder history, database-backed prompt repositories, and error logs for templates containing Python format syntax beyond simple variable names. Focus on suspicious use of dots, square brackets, double-underscore attributes, nested braces in format specifiers, and references to common sensitive names such as secret, token, key, password, config, env, credentials, request, session, headers, or cookies. Review rendered prompts, model transcripts, image-generation prompts, and trace payloads for unexpected leakage of configuration values, environment-derived data, API keys, internal URLs, authorization headers, or object representations. Correlate suspicious template submissions with subsequent responses containing sensitive values and with the account, IP address, integration, plugin, or workflow that supplied the template. For forensic review, compare prompt-template changes before and after upgrade, inspect stored templates for unsafe syntax, and check whether any rendered prompts containing sensitive data were exported to observability tools, logs, tickets, or analytics pipelines.

  • DictPromptTemplate
  • ImagePromptTemplate
  • {.__dict__}
  • {config.__dict__}
  • {settings.__dict__}
  • {request.__dict__}
  • {session.__dict__}
  • {headers[Authorization]}
  • {headers[authorization]}
  • {cookies[session]}
  • {env[
  • {os.environ[
  • {config[
  • {settings[
  • {secrets[
  • {credentials[
  • {token
  • {api_key
  • {password
  • {secret
  • .__class__
  • .__mro__
  • .__subclasses__
  • .__globals__
  • .__dict__
  • [{
  • }:

What your security team should do

  • Inventory all applications, agents, notebooks, workflow builders, and services that use LangChain or LangChain Core, including transitive dependencies.
  • Prioritize upgrades for externally reachable applications and systems that allow user-defined, tenant-defined, plugin-provided, or database-stored prompt templates.
  • Upgrade to LangChain 0.3.84 or later, or 1.2.28 or later, and rebuild/redeploy all runtime artifacts that package LangChain.
  • Search code and configuration for DictPromptTemplate, ImagePromptTemplate, custom prompt-template classes, and dynamic f-string template construction from untrusted input.
  • Add validation or allowlisting at application boundaries so untrusted prompt templates cannot contain attribute access, indexing, or nested replacement fields.
  • Reduce the data exposed to prompt formatting by passing only explicit primitive variables and removing secrets or rich objects from template contexts.
  • Review prompt logs, LLM traces, and application telemetry for suspicious template syntax and unexpected disclosure of configuration, tokens, credentials, or internal object data.
  • Add regression tests that verify unsafe f-string constructs are rejected across all prompt-template classes used by the application.

The record

LangChain is a framework for building agents and LLM-powered applications. Prior to 0.3.84 and 1.2.28, 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. Second, f-string validation based on parsed top-level field names did not reject nested replacement fields inside format specifiers. 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. This vulnerability is fixed in 0.3.84 and 1.2.28.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities