https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 01 Oct 2026 02:07:49 +0000 https://vulnerability.circl.lu/vuln/cve-2025-68664 <p><strong>Affected:</strong> langchain-ai langchain</p> <p>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&#39;s dumps() and dumpd() functions. The functions do not escape dictionaries with &#39;lc&#39; keys when serializing free-form dictionaries. The &#39;lc&#39; 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.</p> <p><strong>Affected:</strong> langchain-ai langchain</p> <p>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&#39;s dumps() and dumpd() functions. The functions do not escape dictionaries with &#39;lc&#39; keys when serializing free-form dictionaries. The &#39;lc&#39; 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.</p> https://vulnerability.circl.lu/vuln/cve-2025-68664 https://vulnerability.circl.lu/vuln/ghsa-c67j-w6g6-q2cm <p><strong>Affected:</strong> PyPI: langchain-core</p> <p>## Summary</p> <p>A serialization injection vulnerability exists in LangChain&#39;s `dumps()` and `dumpd()` functions. The functions do not escape dictionaries with `&#39;lc&#39;` keys when serializing free-form dictionaries. The `&#39;lc&#39;` 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.</p> <p>### Attack surface</p> <p>The core vulnerability was in `dumps()` and `dumpd()`: these functions failed to escape user-controlled dictionaries containing `&#39;lc&#39;` keys. When this unescaped data was later deserialized via `load()` or `loads()`, the injected structures were treated as legitimate LangChain objects rather than plain user data.</p> <p>This escaping bug enabled several attack vectors:</p> <p>1. **Injection via user data**: Malicious LangChain object structures could be injected through user-controlled fields like `metadata`, `additional_kwargs`, or `response_metadata` 2. **Class instantiation within trusted namespaces**: Injected manifests could instantiate any `Serializable` subclass, but only within the pre-approved trusted namespaces (`langchain_core`, `langchain`, `langchain_community`). This includes classes with side effects in `__init__` (network calls, file operations, etc.). Note that namespace validation was already enforced before this patch, so arbitrary classes outside these trusted namespaces could not be instantiated.</p> <p>### Security hardeni…</p> <p><strong>Affected:</strong> PyPI: langchain-core</p> <p>## Summary</p> <p>A serialization injection vulnerability exists in LangChain&#39;s `dumps()` and `dumpd()` functions. The functions do not escape dictionaries with `&#39;lc&#39;` keys when serializing free-form dictionaries. The `&#39;lc&#39;` 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.</p> <p>### Attack surface</p> <p>The core vulnerability was in `dumps()` and `dumpd()`: these functions failed to escape user-controlled dictionaries containing `&#39;lc&#39;` keys. When this unescaped data was later deserialized via `load()` or `loads()`, the injected structures were treated as legitimate LangChain objects rather than plain user data.</p> <p>This escaping bug enabled several attack vectors:</p> <p>1. **Injection via user data**: Malicious LangChain object structures could be injected through user-controlled fields like `metadata`, `additional_kwargs`, or `response_metadata` 2. **Class instantiation within trusted namespaces**: Injected manifests could instantiate any `Serializable` subclass, but only within the pre-approved trusted namespaces (`langchain_core`, `langchain`, `langchain_community`). This includes classes with side effects in `__init__` (network calls, file operations, etc.). Note that namespace validation was already enforced before this patch, so arbitrary classes outside these trusted namespaces could not be instantiated.</p> <p>### Security hardeni…</p> https://vulnerability.circl.lu/vuln/ghsa-c67j-w6g6-q2cm https://vulnerability.circl.lu/vuln/pysec-2026-373 <p><strong>Affected:</strong> PyPI: langchain-core</p> <p>## Summary</p> <p>A serialization injection vulnerability exists in LangChain&#39;s `dumps()` and `dumpd()` functions. The functions do not escape dictionaries with `&#39;lc&#39;` keys when serializing free-form dictionaries. The `&#39;lc&#39;` 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.</p> <p>### Attack surface</p> <p>The core vulnerability was in `dumps()` and `dumpd()`: these functions failed to escape user-controlled dictionaries containing `&#39;lc&#39;` keys. When this unescaped data was later deserialized via `load()` or `loads()`, the injected structures were treated as legitimate LangChain objects rather than plain user data.</p> <p>This escaping bug enabled several attack vectors: 1. **Injection via user data**: Malicious LangChain object structures could be injected through user-controlled fields like `metadata`, `additional_kwargs`, or `response_metadata` 2. **Class instantiation within trusted namespaces**: Injected manifests could instantiate any `Serializable` subclass, but only within the pre-approved trusted namespaces (`langchain_core`, `langchain`, `langchain_community`). This includes classes with side effects in `__init__` (network calls, file operations, etc.). Note that namespace validation was already enforced before this patch, so arbitrary classes outside these trusted namespaces could not be instantiated.</p> <p>### Security harde…</p> <p><strong>Affected:</strong> PyPI: langchain-core</p> <p>## Summary</p> <p>A serialization injection vulnerability exists in LangChain&#39;s `dumps()` and `dumpd()` functions. The functions do not escape dictionaries with `&#39;lc&#39;` keys when serializing free-form dictionaries. The `&#39;lc&#39;` 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.</p> <p>### Attack surface</p> <p>The core vulnerability was in `dumps()` and `dumpd()`: these functions failed to escape user-controlled dictionaries containing `&#39;lc&#39;` keys. When this unescaped data was later deserialized via `load()` or `loads()`, the injected structures were treated as legitimate LangChain objects rather than plain user data.</p> <p>This escaping bug enabled several attack vectors: 1. **Injection via user data**: Malicious LangChain object structures could be injected through user-controlled fields like `metadata`, `additional_kwargs`, or `response_metadata` 2. **Class instantiation within trusted namespaces**: Injected manifests could instantiate any `Serializable` subclass, but only within the pre-approved trusted namespaces (`langchain_core`, `langchain`, `langchain_community`). This includes classes with side effects in `__init__` (network calls, file operations, etc.). Note that namespace validation was already enforced before this patch, so arbitrary classes outside these trusted namespaces could not be instantiated.</p> <p>### Security harde…</p> https://vulnerability.circl.lu/vuln/pysec-2026-373