Langchain Core
Approved changes feed: RSS · Atom
cpe:2.3:a:langchain:langchain_core:*:*:*:*:*:python:*:*
part: a version: * update: *
| Vendor | Langchain (3bec1db6-30f1-5f7c-8067-d161076b8e16) |
|---|---|
| Product | Langchain Core (449181ef-2d68-5a83-975a-1a2dd069e7bd) |
| Edition | * |
| Language | * |
| Software edition | * |
| Target software | python |
| Target hardware | * |
| Other | * |
| Notes | Imported from gcve-enriched-dumps CVE data |
PURL mappings
| PURL | Source | Last updated |
|---|---|---|
| No PURL mappings for this CPE yet. | ||
Vulnerability references
| Identifier | cpeApplicability | Submitted | db.gcve.eu details | Rationale |
|---|---|---|---|---|
CVE:CVE-2026-40087 |
vulnerable | 2026-06-08 08:01:19.875655 |
LangChain has incomplete f-string validation in prompt templates
MEDIUM (5.3)
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.
Published: 2026-04-09T19:34:55.198Z
Updated: 2026-04-14T14:48:03.160Z Reference links
|
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2026-26013 |
vulnerable | 2026-06-08 07:53:20.718699 |
LangChain affected by SSRF via image_url token counting in ChatOpenAI.get_num_tokens_from_messages
LOW (3.7)
LangChain is a framework for building agents and LLM-powered applications. Prior to 1.2.11, the ChatOpenAI.get_num_tokens_from_messages() method fetches arbitrary image_url values without validation when computing token counts for vision-enabled models. This allows attackers to trigger Server-Side Request Forgery (SSRF) attacks by providing malicious image URLs in user input. This vulnerability is fixed in 1.2.11.
Published: 2026-02-10T21:51:07.741Z
Updated: 2026-02-11T21:26:34.029Z |
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2025-68664 |
vulnerable | 2026-06-08 07:41:21.585975 |
LangChain serialization injection vulnerability enables secret extraction in dumps/loads APIs
CRITICAL (9.3)
LangChain is a framework for building agents and LLM-powered applications. Prior to versions 0.3.81 and 1.2.5, a serialization injection vulnerability exists in LangChain's dumps() and dumpd() functions. The functions do not escape dictionaries with 'lc' keys when serializing free-form dictionaries. The 'lc' key is used internally by LangChain to mark serialized objects. When user-controlled data contains this key structure, it is treated as a legitimate LangChain object during deserialization rather than plain user data. This issue has been patched in versions 0.3.81 and 1.2.5.
Published: 2025-12-23T22:47:44.084Z
Updated: 2025-12-24T14:40:58.427Z Reference links
|
Imported from gcve-enriched-dumps CVE data |
CVE:CVE-2024-58340 |
vulnerable | 2026-06-08 06:56:14.481382 |
LangChain <= 0.3.1 MRKLOutputParser ReDoS
LangChain versions up to and including 0.3.1 contain a regular expression denial-of-service (ReDoS) vulnerability in the MRKLOutputParser.parse() method (libs/langchain/langchain/agents/mrkl/output_parser.py). The parser applies a backtracking-prone regular expression when extracting tool actions from model output. An attacker who can supply or influence the parsed text (for example via prompt injection in downstream applications that pass LLM output directly into MRKLOutputParser.parse()) can trigger excessive CPU consumption by providing a crafted payload, causing significant parsing delays and a denial-of-service condition.
Published: 2026-01-12T23:05:00.801Z
Updated: 2026-03-05T01:29:48.307Z |
Imported from gcve-enriched-dumps CVE data |
Contribute
You can submit an edit proposal for this CPE entry or suggest a related product/vendor addition using the action button above.