{"schema_version":"1.7.5","id":"PYSEC-2026-373","published":"2026-06-29T11:50:38.732432Z","modified":"2026-07-02T13:00:05.018724776Z","aliases":["CVE-2025-68664","GHSA-c67j-w6g6-q2cm"],"summary":"LangChain serialization injection vulnerability enables secret extraction in dumps/loads APIs","details":"## Summary\n\nA 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.\n\n### Attack surface\n\nThe core vulnerability was in `dumps()` and `dumpd()`: these functions failed to escape user-controlled dictionaries containing `'lc'` 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.\n\nThis escaping bug enabled several attack vectors:\n \n1. **Injection via user data**: Malicious LangChain object structures could be injected through user-controlled fields like `metadata`, `additional_kwargs`, or `response_metadata`\n2. **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.\n\n ### Security hardening\n\nThis patch fixes the escaping bug in `dumps()` and `dumpd()` and introduces new restrictive defaults in `load()` and `loads()`: allowlist enforcement via `allowed_objects=\"core\"` (restricted to [serialization mappings](https://github.com/langchain-ai/langchain/blob/master/libs/core/langchain_core/load/mapping.py)), `secrets_from_env` changed from `True` to `False`, and default Jinja2 template blocking via `init_validator`. These are breaking changes for some use cases.\n\n## Who is affected?\n\nApplications are vulnerable if they:\n\n1. **Use `astream_events(version=\"v1\")`** — The v1 implementation internally uses vulnerable serialization. Note: `astream_events(version=\"v2\")` is not vulnerable.\n2. **Use `Runnable.astream_log()`** — This method internally uses vulnerable serialization for streaming outputs.\n 3. **Call `dumps()` or `dumpd()` on untrusted data, then deserialize with `load()` or `loads()`** — Trusting your own serialization output makes you vulnerable if user-controlled data (e.g., from LLM responses, metadata fields, or user inputs) contains `'lc'` key structures.\n4. **Deserialize untrusted data with `load()` or `loads()`** — Directly deserializing untrusted data that may contain injected `'lc'` structures.\n5. **Use `RunnableWithMessageHistory`** — Internal serialization in message history handling.\n6. **Use `InMemoryVectorStore.load()`** to deserialize untrusted documents.\n7. Load untrusted generations from cache using **`langchain-community` caches**.\n8. Load untrusted manifests from the LangChain Hub via **`hub.pull`**.\n 9. Use **`StringRunEvaluatorChain`** on untrusted runs.\n10. Use **`create_lc_store`** or **`create_kv_docstore`** with untrusted documents.\n11. Use **`MultiVectorRetriever`** with byte stores containing untrusted documents.\n12. Use **`LangSmithRunChatLoader`** with runs containing untrusted messages.\n\nThe most common attack vector is through **LLM response fields** like `additional_kwargs` or `response_metadata`, which can be controlled via prompt injection and then serialized/deserialized in streaming operations.\n\n## Impact\n\nAttackers who control serialized data can extract environment variable secrets by injecting `{\"lc\": 1, \"type\": \"secret\", \"id\": [\"ENV_VAR\"]}` to load environment variables during deserialization (when `secrets_from_env=True`, which was the old default). They can also instantiate classes with controlled parameters by injecting constructor structures to instantiate any class within trusted namespaces with attacker-controlled parameters, potentially triggering side effects such as network calls or file operations.\n\nKey severity factors:\n\n- Affects the serialization path - applications trusting their own serialization output are vulnerable\n- Enables secret extraction when combined with `secrets_from_env=True` (the old default)\n - LLM responses in `additional_kwargs` can be controlled via prompt injection\n\n ## Exploit example\n\n```python\nfrom langchain_core.load import dumps, load\nimport os\n\n# Attacker injects secret structure into user-controlled data\nattacker_dict = {\n    \"user_data\": {\n        \"lc\": 1,\n        \"type\": \"secret\",\n        \"id\": [\"OPENAI_API_KEY\"]\n    }\n}\n\nserialized = dumps(attacker_dict)  # Bug: does NOT escape the 'lc' key\n\nos.environ[\"OPENAI_API_KEY\"] = \"sk-secret-key-12345\"\ndeserialized = load(serialized, secrets_from_env=True)\n\nprint(deserialized[\"user_data\"])  # \"sk-secret-key-12345\" - SECRET LEAKED!\n\n```\n\n## Security hardening changes (breaking changes)\n\nThis patch introduces three breaking changes to `load()` and `loads()`:\n\n1. **New `allowed_objects` parameter** (defaults to `'core'`): Enforces allowlist of classes that can be deserialized. The `'all'` option corresponds to the list of objects [specified in `mappings.py`](https://github.com/langchain-ai/langchain/blob/master/libs/core/langchain_core/load/mapping.py) while the `'core'` option limits to objects within `langchain_core`. We recommend that users explicitly specify which objects they want to allow for serialization/deserialization.\n 2. **`secrets_from_env` default changed from `True` to `False`**: Disables automatic secret loading from environment\n3. **New `init_validator` parameter** (defaults to `default_init_validator`): Blocks Jinja2 templates by default\n\n## Migration guide\n\n### No changes needed for most users\n\nIf you're deserializing standard LangChain types (messages, documents, prompts, trusted partner integrations like `ChatOpenAI`, `ChatAnthropic`, etc.), your code will work without changes:\n\n```python\n from langchain_core.load import load\n\n# Uses default allowlist from serialization mappings\nobj = load(serialized_data)\n\n```\n\n### For custom classes\n\nIf you're deserializing custom classes not in the serialization mappings, add them to the allowlist:\n\n```python\nfrom langchain_core.load import load\nfrom my_package import MyCustomClass\n\n# Specify the classes you need\nobj = load(serialized_data, allowed_objects=[MyCustomClass])\n ```\n\n### For Jinja2 templates\n\nJinja2 templates are now blocked by default because they can execute arbitrary code. If you need Jinja2 templates, pass `init_validator=None`:\n \n```python\nfrom langchain_core.load import load\nfrom langchain_core.prompts import PromptTemplate\n\nobj = load(\n    serialized_data,\n    allowed_objects=[PromptTemplate],\n    init_validator=None\n)\n\n```\n\n> [!WARNING]\n> Only disable `init_validator` if you trust the serialized data. Jinja2 templates can execute arbitrary Python code.\n\n### For secrets from environment\n\n`secrets_from_env` now defaults to `False`. If you need to load secrets from environment variables:\n\n```python\n from langchain_core.load import load\n\nobj = load(serialized_data, secrets_from_env=True)\n ```\n\n\n## Credits\n\n* Dumps bug was reported by @yardenporat\n* Changes for security hardening due to findings from @0xn3va and @VladimirEliTokarev","affected":[{"package":{"name":"langchain-core","ecosystem":"PyPI","purl":"pkg:pypi/langchain-core"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.3.81"},{"introduced":"1.0.0"},{"fixed":"1.2.5"}]}],"versions":["0.0.1","0.0.10","0.0.11","0.0.12","0.0.13","0.0.13rc1","0.0.13rc2","0.0.2","0.0.3","0.0.4","0.0.5","0.0.6","0.0.7","0.0.8","0.0.9","0.1.0","0.1.1","0.1.10","0.1.11","0.1.12","0.1.12rc1","0.1.13","0.1.14","0.1.15","0.1.15rc1","0.1.15rc2","0.1.16","0.1.17","0.1.18","0.1.19","0.1.2","0.1.20","0.1.21","0.1.22","0.1.23","0.1.24","0.1.25","0.1.26","0.1.27","0.1.28","0.1.29","0.1.3","0.1.30","0.1.31","0.1.32","0.1.33","0.1.33rc1","0.1.34","0.1.35","0.1.36","0.1.37","0.1.38","0.1.39","0.1.4","0.1.40","0.1.41","0.1.42","0.1.42rc1","0.1.43","0.1.44","0.1.45","0.1.46","0.1.47","0.1.47rc1","0.1.48","0.1.49","0.1.5","0.1.50","0.1.51","0.1.52","0.1.53","0.1.6","0.1.7","0.1.8","0.1.9","0.2.0","0.2.0rc1","0.2.1","0.2.10","0.2.11","0.2.12","0.2.13","0.2.15","0.2.16","0.2.17","0.2.18","0.2.19","0.2.2","0.2.20","0.2.21","0.2.22","0.2.23","0.2.24","0.2.25","0.2.26","0.2.27","0.2.28","0.2.29","0.2.29rc1","0.2.2rc1","0.2.3","0.2.30","0.2.31","0.2.32","0.2.33","0.2.34","0.2.35","0.2.36","0.2.37","0.2.38","0.2.39","0.2.4","0.2.40","0.2.41","0.2.42","0.2.43","0.2.5","0.2.6","0.2.7","0.2.8","0.2.9","0.3.0","0.3.0.dev0","0.3.0.dev1","0.3.0.dev2","0.3.0.dev3","0.3.0.dev4","0.3.0.dev5","0.3.1","0.3.10","0.3.11","0.3.12","0.3.13","0.3.14","0.3.15","0.3.16","0.3.17","0.3.18","0.3.19","0.3.2","0.3.20","0.3.21","0.3.22","0.3.23","0.3.24","0.3.25","0.3.26","0.3.27","0.3.28","0.3.29","0.3.3","0.3.30","0.3.31","0.3.32","0.3.33","0.3.34","0.3.34rc1","0.3.34rc2","0.3.35","0.3.36","0.3.37","0.3.38","0.3.39","0.3.4","0.3.40","0.3.41","0.3.42","0.3.43","0.3.44","0.3.45","0.3.45rc1","0.3.46","0.3.47","0.3.48","0.3.49","0.3.5","0.3.50","0.3.51","0.3.52","0.3.53","0.3.54","0.3.55","0.3.56","0.3.56rc1","0.3.57","0.3.58","0.3.59","0.3.6","0.3.60","0.3.61","0.3.62","0.3.63","0.3.64","0.3.65","0.3.66","0.3.67","0.3.68","0.3.69","0.3.7","0.3.70","0.3.71","0.3.72","0.3.73","0.3.74","0.3.75","0.3.76","0.3.77","0.3.78","0.3.79","0.3.8","0.3.80","0.3.9","1.0.0","1.0.1","1.0.2","1.0.3","1.0.4","1.0.5","1.0.6","1.0.7","1.1.0","1.1.1","1.1.2","1.1.3","1.2.0","1.2.1","1.2.2","1.2.3","1.2.4"],"database_specific":{"source":"https://github.com/pypa/advisory-database/blob/main/vulns/langchain-core/PYSEC-2026-373.yaml"}}],"references":[{"type":"WEB","url":"https://github.com/langchain-ai/langchain/security/advisories/GHSA-c67j-w6g6-q2cm"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-68664"},{"type":"WEB","url":"https://github.com/langchain-ai/langchain/pull/34455"},{"type":"WEB","url":"https://github.com/langchain-ai/langchain/pull/34458"},{"type":"WEB","url":"https://github.com/langchain-ai/langchain/commit/5ec0fa69de31bbe3d76e4cf9cd65a6accb8466c8"},{"type":"WEB","url":"https://github.com/langchain-ai/langchain/commit/d9ec4c5cc78960abd37da79b0250f5642e6f0ce6"},{"type":"PACKAGE","url":"https://github.com/langchain-ai/langchain"},{"type":"WEB","url":"https://github.com/langchain-ai/langchain/releases/tag/langchain-core%3D%3D0.3.81"},{"type":"WEB","url":"https://github.com/langchain-ai/langchain/releases/tag/langchain-core%3D%3D1.2.5"},{"type":"PACKAGE","url":"https://pypi.org/project/langchain-core"},{"type":"ADVISORY","url":"https://github.com/advisories/GHSA-c67j-w6g6-q2cm"}],"severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N"}]}