<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-01T02:08:41.615544+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/cve-2026-40087</id>
    <title>CVE-2026-40087 — LangChain has incomplete f-string validation in prompt templates</title>
    <updated>2026-10-01T02:08:41.618325+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> langchain-ai langchain</p>
<p>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.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-40087"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-926x-3r5x-gfhw</id>
    <title>GHSA-926x-3r5x-gfhw — LangChain has incomplete f-string validation in prompt templates</title>
    <updated>2026-10-01T02:08:41.618442+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: langchain-core</p>
<p>LangChain's f-string prompt-template validation was incomplete in two respects.</p>
<p>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.</p>
<p>Examples of the affected shape include:</p>
<p>```python
"{message.additional_kwargs[secret]}"
"https://example.com/{image.__class__.__name__}.png"
```</p>
<p>Second, f-string validation based on parsed top-level field names did not reject nested replacement fields inside format specifiers. For example:</p>
<p>```python
"{name:{name.__class__.__name__}}"
```</p>
<p>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.</p>
<p>## Affected usage</p>
<p>This issue is only relevant for applications that accept untrusted template strings, rather than only untrusted template variable values.</p>
<p>In addition, practical impact depends on what objects are passed into template formatting:</p>
<p>- If applications only format simple values such as strings and numbers, impact is limited and may only result in formatting errors.
- If applications format ric…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-926x-3r5x-gfhw"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/pysec-2026-2563</id>
    <title>PYSEC-2026-2563 — LangChain has incomplete f-string validation in prompt templates</title>
    <updated>2026-10-01T02:08:41.618562+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> PyPI: langchain-core</p>
<p>LangChain's f-string prompt-template validation was incomplete in two respects.</p>
<p>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.</p>
<p>Examples of the affected shape include:</p>
<p>```python
"{message.additional_kwargs[secret]}"
"https://example.com/{image.__class__.__name__}.png"
```</p>
<p>Second, f-string validation based on parsed top-level field names did not reject nested replacement fields inside format specifiers. For example:</p>
<p>```python
"{name:{name.__class__.__name__}}"
```</p>
<p>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.</p>
<p>## Affected usage</p>
<p>This issue is only relevant for applications that accept untrusted template strings, rather than only untrusted template variable values.</p>
<p>In addition, practical impact depends on what objects are passed into template formatting:</p>
<p>- If applications only format simple values such as strings and numbers, impact is limited and may only result in formatting errors.
- If applications format ric…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/pysec-2026-2563"/>
  </entry>
</feed>
