CVE-2026-106119: LangChain MongoDB Information Disclosure

CVE-2026-106119 Overview

CVE-2026-106119 is a NoSQL injection vulnerability in LangChain.js MongoDBChatMessageHistory affecting versions prior to 1.3.1. The component does not enforce the documented string type for session identifiers at runtime. An attacker who supplies a structured object as a session identifier can have it interpreted as a MongoDB query condition instead of a literal value. In shared MongoDB collections storing multiple users' chat histories, this allows reading, modifying, or deleting another user's conversation data. Applications that use authenticated, server-controlled string identifiers are not affected. The flaw is tracked under [CWE-943] (Improper Neutralization of Special Elements in Data Query Logic).

Critical Impact

Attackers can access, alter, or delete other users' stored LLM chat histories by injecting MongoDB query operators through unvalidated session identifiers.

Affected Products

• LangChain.js @langchain/mongodb package versions prior to 1.3.1
• Applications using MongoDBChatMessageHistory with user-supplied session identifiers
• Multi-tenant LLM applications sharing a single MongoDB collection for chat history storage

Discovery Timeline

• 2026-10-06 - CVE-2026-106119 published to NVD
• 2026-10-06 - Last updated in NVD database

Technical Details for CVE-2026-106119

Vulnerability Analysis

The vulnerability affects MongoDBChatMessageHistory in the @langchain/mongodb provider package. The class documents sessionId as a string but performs no runtime type enforcement before using the value inside MongoDB query filters. When developers pass user-controlled JSON directly to the constructor or operation methods, an attacker can supply an object such as { "$ne": null } instead of a string. MongoDB then interprets the object as a query operator rather than a literal match. In a shared collection storing many users' histories, this expands the filter scope beyond the attacker's own session. The result is cross-tenant disclosure, tampering, or deletion of chat messages belonging to other users.

Root Cause

The root cause is missing input validation combined with unparameterized query construction. Session identifiers were embedded directly into filter documents without an $eq wrapper or type check. MongoDB treats embedded objects as operator expressions, which turns a trusted field into an attacker-controlled query clause.

Attack Vector

The attack requires network access and low privileges. An attacker must be able to invoke chat-history operations and control the value passed as the session identifier. Supplying a crafted object instead of a string causes the backend to match documents owned by other users. No authentication bypass is required beyond the attacker's own authenticated session.

// Security patch in libs/providers/langchain-mongodb/src/cache.ts
// fix(mongodb): reject non-string sessionId and wrap chat history filters with $eq
       generations.map((g) => JSON.stringify(serializeGeneration(g)))
     );
     await this.collection.updateOne(
-      { [this.PROMPT]: prompt, [this.LLM]: llmKey },
+      { [this.PROMPT]: { $eq: prompt }, [this.LLM]: { $eq: llmKey } },
       { $set: { [this.RETURN_VAL]: serialized } },
       { upsert: true }
     );

Source: GitHub Commit 946e3d8

The fix wraps filter values with the $eq operator, forcing MongoDB to perform literal equality comparisons even if an object is passed. A second patch in chat_history.ts adds documentation and runtime rejection of non-string session identifiers.

Detection Methods for CVE-2026-106119

Indicators of Compromise

• MongoDB query logs showing chat-history filter documents containing operator keys such as $ne, $gt, $regex, or $exists in the sessionId field
• Application logs where incoming request bodies contain non-string values in fields mapped to sessionId
• Unexpected read, update, or delete operations on chat-history documents outside a user's known session scope

Detection Strategies

• Inspect application code paths that instantiate MongoDBChatMessageHistory and confirm sessionId is validated as a string before use
• Enable MongoDB profiling or query auditing to surface filter documents containing embedded operator objects on chat-history collections
• Review request validation middleware to ensure JSON payloads deserialize sessionId strictly as a string type

Monitoring Recommendations

• Alert on MongoDB operations against chat-history collections where filter values are objects rather than scalars
• Monitor dependency manifests (package.json, package-lock.json) for @langchain/mongodb versions below 1.3.1
• Track anomalous access patterns such as a single authenticated user reading or deleting an unusually high number of chat-history documents

How to Mitigate CVE-2026-106119

Immediate Actions Required

• Upgrade @langchain/mongodb to version 1.3.1 or later across all deployments
• Audit application code to confirm no user-supplied JSON is passed directly as sessionId without string-type enforcement
• Rotate or invalidate chat-history records if logs show evidence of operator injection in prior queries

Patch Information

The fix is included in @langchain/mongodb@1.3.1. See the LangchainJS MongoDB Release, GitHub Pull Request #11672, and GitHub Security Advisory GHSA-m6rx-h84q-8r95 for details. The patch wraps filter values with $eq and rejects non-string sessionId inputs at runtime.

Workarounds

• Derive sessionId from a server-controlled, authenticated value such as a session token or user ID, never from a raw request field
• Add explicit typeof sessionId === 'string' validation at the application layer before invoking chat-history methods
• Isolate per-tenant chat histories into separate MongoDB collections to reduce cross-user blast radius

# Upgrade the vulnerable package
npm install @langchain/mongodb@^1.3.1

# Verify installed version
npm ls @langchain/mongodb