Bug 2457024 (CVE-2026-40087)

Summary:	CVE-2026-40087 langchain: incomplete f-string validation in prompt templates
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security DevOps Team <prodsec-dev>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	anpicker, bbrownin, dfreiber, drow, dschmidt, erezende, hasun, jburrell, jfula, jkoehler, jlanda, jowilson, jwong, kshier, lphiri, mbarnett, nyancey, omaciel, ometelka, ptisnovs, rjohnson, simaishi, smcdonal, stcannon, syedriko, teagle, ttakamiy, vkumar, xdharmai, yguenane
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	A flaw was found in LangChain. A missing validation of f-string prompt templates in some classes, specifically in `DictPromptTemplate` and `ImagePromptTemplate`, can cause the evaluation of attribute access or indexing expressions during template formatting. Also, f-string validation based on parsed top-level field names did not reject nested replacement fields inside format specifiers. A remote attacker can exploit this issue by providing a specially crafted prompt template, potentially leading to information disclosure.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-04-09 20:01:39 UTC

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.