CVE-2026-14630: AI-fundermentals weak hash exposes

CISO Take

A LangChain-based agentic customer-service reference implementation (ForceInjection/AI-fundermentals) generates its session-ownership identifier using a weak hash, and the get_conversation_history function in the Memory Recall Handler doesn't independently verify that a caller actually owns the session it requests. In practice this lets an attacker who can predict or reverse the weak hash pull another user's stored conversation history out of agent memory. The CVSS score is low (3.1) and MITRE-rated attack complexity is high — there's no EPSS data, no CISA KEV listing, and no scanner template — but the exploit has already been publicly disclosed via a GitHub issue, so a working PoC likely exists. Blast radius is limited: this is a demo/reference codebase rather than a widely-depended-on package, so exposure is confined to teams that deployed this specific example (or a close fork) into production. Action: apply patch f57277f, which changes sessionowner generation to require verified user identity and security-context metadata, and audit any internal agent-memory code that copied this session-derivation pattern.

Sources: NVD GitHub Advisory ATLAS vuldb.com

What is the risk?

Low overall risk. CVSS 3.1 (AV:N/AC:H/PR:L/UI:N/C:L/I:N/A:N) reflects a confidentiality-only impact that requires meaningful attacker effort to reverse or predict the weak hash — there's no trivial mass-exploitation path, no EPSS score, and it's not in CISA KEV. The main risk driver is that a public exploit/issue exists, so opportunistic attackers targeting known forks of this codebase could attempt it. Because the vulnerable code lives in a tutorial/reference project rather than a widely-distributed package, real-world exposure depends entirely on whether an organization deployed this exact sample (or an unpatched derivative) as production agent infrastructure.

How does the attack unfold?

Reconnaissance

Attacker identifies a publicly reachable agentic customer-service endpoint exposing session-based conversation history retrieval.

AML.T0006

Session forgery

Attacker reverse-engineers or predicts the weak hash used to generate the sessionowner value, forging an identifier for a target user's session.

AML.T0080.000

Unauthorized memory access

Attacker calls get_conversation_history with the forged sessionowner; the Memory Recall Handler fails to independently verify true ownership and returns the victim's stored chat history.

AML.T0057

Data exposure

Attacker harvests sensitive content (PII, account/business details) from the leaked conversation history for further abuse or sale.

AML.T0048.003

Reconnaissance

Attacker identifies a publicly reachable agentic customer-service endpoint exposing session-based conversation history retrieval.

AML.T0006

Session forgery

Attacker reverse-engineers or predicts the weak hash used to generate the sessionowner value, forging an identifier for a target user's session.

AML.T0080.000

Unauthorized memory access

Attacker calls get_conversation_history with the forged sessionowner; the Memory Recall Handler fails to independently verify true ownership and returns the victim's stored chat history.

AML.T0057

Data exposure

Attacker harvests sensitive content (PII, account/business details) from the leaked conversation history for further abuse or sale.

AML.T0048.003

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
AI-fundermentals	—	—	No patch

Do you use AI-fundermentals? You're affected.

How severe is it?

CVSS 3.1

3.1 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 6% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

○ Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Network

AC High

PR Low

UI None

S Unchanged

C Low

I None

A None

What should I do?

1 step

Apply upstream patch f57277fdd9ba373ace72d83c272023ec67f720d6, which requires verified session ownership (identity + security-context metadata) in username/sessionowner handling. Audit any internal or forked agentic-memory code for the same weak-hash session-derivation anti-pattern and replace it with HMAC-signed, per-user-keyed session tokens rather than a bare hash. Add explicit authorization checks on get_conversation_history (and equivalent memory-recall endpoints) so session ownership is verified server-side rather than inferred from a guessable token. Add rate-limiting/anomaly detection on conversation-history retrieval endpoints to catch enumeration attempts against session identifiers.

What does CISA's SSVC say?

Decision Track*

Exploitation poc

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth Bypass Data Leakage Agent Framework AML.T0057 - LLM Data Leakage AML.T0080.000 - Memory AML.T0091 - Use Alternate Authentication Material

Which compliance frameworks are affected?

This CVE is relevant to:

NIST AI RMF

MEASURE 2.7 - AI system security and resilience are evaluated and documented

OWASP LLM Top 10

LLM02:2025 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-14630?

A LangChain-based agentic customer-service reference implementation (ForceInjection/AI-fundermentals) generates its session-ownership identifier using a weak hash, and the get_conversation_history function in the Memory Recall Handler doesn't independently verify that a caller actually owns the session it requests. In practice this lets an attacker who can predict or reverse the weak hash pull another user's stored conversation history out of agent memory. The CVSS score is low (3.1) and MITRE-rated attack complexity is high — there's no EPSS data, no CISA KEV listing, and no scanner template — but the exploit has already been publicly disclosed via a GitHub issue, so a working PoC likely exists. Blast radius is limited: this is a demo/reference codebase rather than a widely-depended-on package, so exposure is confined to teams that deployed this specific example (or a close fork) into production. Action: apply patch f57277f, which changes sessionowner generation to require verified user identity and security-context metadata, and audit any internal agent-memory code that copied this session-derivation pattern.

Is CVE-2026-14630 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-14630, increasing the risk of exploitation.

How to fix CVE-2026-14630?

Apply upstream patch f57277fdd9ba373ace72d83c272023ec67f720d6, which requires verified session ownership (identity + security-context metadata) in username/sessionowner handling. Audit any internal or forked agentic-memory code for the same weak-hash session-derivation anti-pattern and replace it with HMAC-signed, per-user-keyed session tokens rather than a bare hash. Add explicit authorization checks on get_conversation_history (and equivalent memory-recall endpoints) so session ownership is verified server-side rather than inferred from a guessable token. Add rate-limiting/anomaly detection on conversation-history retrieval endpoints to catch enumeration attempts against session identifiers.

What systems are affected by CVE-2026-14630?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, conversation memory / session stores.

What is the CVSS score for CVE-2026-14630?

CVE-2026-14630 has a CVSS v3.1 base score of 3.1 (LOW). The EPSS exploitation probability is 0.16%.

What is the AI security impact?

Affected AI Architectures

agent frameworksconversation memory / session stores

MITRE ATLAS Techniques

AML.T0057 LLM Data Leakage

AML.T0080.000 Memory

AML.T0091 Use Alternate Authentication Material

Compliance Controls Affected

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM02:2025

What are the technical details?

Original Advisory

A vulnerability has been found in ForceInjection AI-fundermentals 2.0/3.0. Affected by this vulnerability is the function get_conversation_history of the file 08_agentic_system/memory/langchain/code/smart_customer_service.py of the component Memory Recall Handler. The manipulation leads to use of weak hash. Remote exploitation of the attack is possible. A high degree of complexity is needed for the attack. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The identifier of the patch is f57277fdd9ba373ace72d83c272023ec67f720d6. It is suggested to install a patch to address this issue. The project confirms (translated from Chinese): "We now require session ownership verification in methods such as `username`, `sessionowner`, etc., and we've chat()changed the generation of `sessionowner` to include verified user identity and security context metadata."

Exploitation Scenario

An attacker with network access to the customer-service agent's API reverse-engineers or brute-forces the weak hash used to derive sessionowner values (high complexity, since it requires understanding the hash construction and there's no simple guessing shortcut). Once a valid-looking sessionowner is forged or predicted for a target user, the attacker calls get_conversation_history with that value; because the Memory Recall Handler doesn't independently verify true ownership, it returns the victim's stored conversation history, exposing whatever the victim discussed with the agent — potentially account data, order details, or other sensitive context captured in agent memory.

Weaknesses (CWE)

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.