AI Threat Alert
CVE-2026-14742: LangGraph: weak hash in task cache risks poisoning
LOWLangGraph's Task Result Cache generates cache keys using the _freeze function, and the underlying default_cache_key argument relies on a cryptographically weak hash algorithm (CWE-327/328) rather than a collision-resistant one. In practice this means two distinct task inputs could hash to the same cache key, causing the wrong cached result to be served for a request — a low-severity but real integrity/confidentiality gap (CVSS 3.1, C:L) in any LangGraph-based agent or workflow deployment that shares a cache across users or sessions. No EPSS data or CISA KEV listing exists for this CVE, and CVSS marks attack complexity as high with an exploit described as difficult, so mass exploitation is unlikely — but a public PoC has already been disclosed and the fix (PR #8069) is still awaiting merge, meaning the weakness is documented and unpatched today. CISOs running LangGraph in multi-tenant or shared-cache configurations should track PR #8069 for merge, avoid relying on default_cache_key for security-sensitive memoization, and consider a custom cache key function backed by SHA-256 until an official patched release ships.
What is the risk?
Overall risk is low per CVSS (3.1, AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N) — confidentiality impact only, no integrity or availability loss, and attack complexity is high with authenticated (low-privilege) access required. There is no EPSS score, no CISA KEV listing, and no nuclei template, indicating low observed/predicted exploitation activity. However, a public exploit/PoC has been disclosed and the upstream fix is still an open pull request, so the weakness is a known, unpatched gap. The realistic risk window is narrow: it matters most for deployments where LangGraph's task cache is shared across tenants, users, or sessions, since a hash collision could surface one party's cached task output to another.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| LangGraph | pip | — | No patch |
Do you use LangGraph? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step-
1) Track upstream PR #8069 and GitHub issue #8009 in langchain-ai/langgraph and upgrade as soon as an official fix lands (currently unmerged as of this CVE's publication). 2) Until patched, avoid relying on the default cache key generator for any deployment where cache entries could be shared across trust boundaries (multi-tenant SaaS, shared sessions); supply a custom, collision-resistant cache key function (e.g., SHA-256-based) via LangGraph's caching configuration instead of default_cache_key. 3) Where feasible, disable or scope the Task Result Cache to per-user/per-session boundaries so a collision cannot cross trust boundaries. 4) Detection: audit logs for anomalous cache hits — i.e., a task returning a result inconsistent with its actual input — though this requires custom instrumentation since LangGraph does not natively flag key collisions.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-14742?
LangGraph's Task Result Cache generates cache keys using the _freeze function, and the underlying default_cache_key argument relies on a cryptographically weak hash algorithm (CWE-327/328) rather than a collision-resistant one. In practice this means two distinct task inputs could hash to the same cache key, causing the wrong cached result to be served for a request — a low-severity but real integrity/confidentiality gap (CVSS 3.1, C:L) in any LangGraph-based agent or workflow deployment that shares a cache across users or sessions. No EPSS data or CISA KEV listing exists for this CVE, and CVSS marks attack complexity as high with an exploit described as difficult, so mass exploitation is unlikely — but a public PoC has already been disclosed and the fix (PR #8069) is still awaiting merge, meaning the weakness is documented and unpatched today. CISOs running LangGraph in multi-tenant or shared-cache configurations should track PR #8069 for merge, avoid relying on default_cache_key for security-sensitive memoization, and consider a custom cache key function backed by SHA-256 until an official patched release ships.
Is CVE-2026-14742 actively exploited?
No confirmed active exploitation of CVE-2026-14742 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-14742?
1) Track upstream PR #8069 and GitHub issue #8009 in langchain-ai/langgraph and upgrade as soon as an official fix lands (currently unmerged as of this CVE's publication). 2) Until patched, avoid relying on the default cache key generator for any deployment where cache entries could be shared across trust boundaries (multi-tenant SaaS, shared sessions); supply a custom, collision-resistant cache key function (e.g., SHA-256-based) via LangGraph's caching configuration instead of default_cache_key. 3) Where feasible, disable or scope the Task Result Cache to per-user/per-session boundaries so a collision cannot cross trust boundaries. 4) Detection: audit logs for anomalous cache hits — i.e., a task returning a result inconsistent with its actual input — though this requires custom instrumentation since LangGraph does not natively flag key collisions.
What systems are affected by CVE-2026-14742?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow orchestration, multi-agent systems.
What is the CVSS score for CVE-2026-14742?
CVE-2026-14742 has a CVSS v3.1 base score of 3.1 (LOW).
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0049 Exploit Public-Facing Application AML.T0080 AI Agent Context Poisoning Compliance Controls Affected
What are the technical details?
Original Advisory
A vulnerability was determined in langchain-ai langgraph up to 1.2.4. The affected element is the function _freeze of the file libs/langgraph/langgraph/_internal/_cache.py of the component Task Result Cache. This manipulation of the argument default_cache_key causes use of weak hash. The attack is possible to be carried out remotely. The complexity of an attack is rather high. The exploitability is described as difficult. The exploit has been publicly disclosed and may be utilized. The pull request to fix this issue awaits acceptance.
Exploitation Scenario
An authenticated low-privilege user of a LangGraph-based multi-tenant agent application crafts a sequence of task inputs specifically designed to trigger a hash collision in the weak default_cache_key algorithm used by the Task Result Cache. When another user's (or the same user's later) task hits the same weak hash, the cache returns the attacker-influenced or unrelated cached result instead of recomputing the correct one. Given the high attack complexity and difficulty rating, exploitation would require deliberate crafting of inputs and knowledge of the hashing scheme — but with the exploit already publicly disclosed, that barrier is lowered for a motivated actor targeting shared-cache LangGraph deployments to cause data confusion or minor confidentiality leakage between cache entries.
Weaknesses (CWE)
CWE-327 Use of a Broken or Risky Cryptographic Algorithm
Primary
CWE-328 Use of Weak Hash
Primary
CWE-327 Use of a Broken or Risky Cryptographic Algorithm CWE-328 Use of Weak Hash CWE-327 — Use of a Broken or Risky Cryptographic Algorithm: The product uses a broken or risky cryptographic algorithm or protocol.
- [Architecture and Design] When there is a need to store or transmit sensitive data, use strong, up-to-date cryptographic algorithms to encrypt that data. Select a well-vetted algorithm that is currently considered to be strong by experts in the field, and use well-tested implementations. As with all cryptographic mechanisms, the source code should be available for analysis. For example, US government systems require FIPS 140-2 certification [REF-1192]. Do not develop custom or private cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. Reverse engineering techniques are mature. If the algorithm can be compromised if attackers find out how it works, then it is especially weak. Periodically ensure that the cryptography has not become obsolete. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong. [REF-267
- [Architecture and Design] Ensure that the design allows one cryptographic algorithm to be replaced with another in the next generation or version. Where possible, use wrappers to make the interfaces uniform. This will make it easier to upgrade to stronger algorithms. With hardware, design the product at the Intellectual Property (IP) level so that one cryptographic algorithm can be replaced with another in the next generation of the hardware product.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N References
Timeline
Related Vulnerabilities
CVE-2025-64104 7.3 langgraph-checkpoint-sqlite: SQL Injection exposes database
Same package: langgraph CVE-2025-8709 7.3 langgraph-checkpoint-sqlite: SQL Injection exposes database
Same package: langgraph CVE-2025-67644 7.3 langgraph-checkpoint-sqlite: SQL Injection exposes database
Same package: langgraph CVE-2026-28277 6.8 langgraph: Deserialization enables RCE
Same package: langgraph CVE-2026-48775 6.8 LangGraph SQLite: deserialization RCE at checkpoint load
Same package: langgraph