CVE-2026-106119 in Langchainjs MongoDB
Summary
by MITRE • 10/06/2026
LangChain is a framework for building LLM-powered applications. Prior to 1.3.1, MongoDBChatMessageHistory does not enforce the documented string type for an untrusted structured session identifier at runtime, allowing the identifier to be interpreted as a MongoDB query condition rather than as a literal value when multiple users' histories are stored in a shared MongoDB collection. An attacker able to invoke chat-history operations can read, modify, or delete another user's stored conversation. Applications using authenticated, server-controlled string identifiers are not affected. This issue is fixed in version 1.3.1.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified within the LangChain framework prior to version 1.3.1 represents a critical security flaw rooted in improper input validation and type enforcement for session identifiers used with MongoDBChatMessageHistory. LangChain serves as a foundational framework for developing applications powered by large language models, facilitating interactions between users and AI systems through persistent conversation histories. In this specific implementation, the system is designed to store chat history in a shared MongoDB collection where multiple user sessions may coexist. The core technical flaw lies in the failure of the MongoDBChatMessageHistory component to strictly enforce that session identifiers are treated as literal string values during database query construction. Instead, when an untrusted or externally provided structured identifier is passed without rigorous type checking at runtime, the system inadvertently allows this input to be interpreted directly as a MongoDB query condition object rather than a simple lookup key.
This architectural oversight creates a severe injection vulnerability that fundamentally alters how data retrieval and modification operations are executed against the database backend. When an attacker can invoke chat-history operations with a crafted session identifier containing special characters or structured JSON-like syntax, they effectively bypass standard equality checks. By injecting query operators such as $gt, $lt, or regex patterns into the session ID field, the attacker manipulates the underlying MongoDB find operation to match documents beyond their intended scope. This behavior mirrors classic NoSQL injection attacks where unvalidated input is interpolated directly into database queries without proper sanitization or parameterized binding mechanisms that enforce strict data types for identifier fields.
The operational impact of this vulnerability is profound and affects the confidentiality, integrity, and availability of user conversation data within affected applications. An attacker who successfully exploits this flaw can read sensitive information from other users' chat histories by crafting identifiers that match broader document sets or specific target records outside their authorized session. Furthermore, the ability to modify stored conversations allows for tampering with historical context, potentially poisoning future model responses if the application relies on these histories for continuity. In more severe scenarios, an attacker could delete another user's conversation history entirely, leading to data loss and disruption of service. This risk is particularly acute in multi-tenant environments or applications where session identifiers are derived from untrusted sources such as URL parameters, form inputs, or API payloads without sufficient server-side validation.
It is important to note that the vulnerability specifically impacts scenarios involving shared MongoDB collections with multiple users' histories stored under potentially uncontrolled identifier schemes. Applications that utilize authenticated, server-controlled string identifiers which are generated internally and not derived from user input remain unaffected by this specific flaw because they inherently possess trusted values that do not require external validation against injection patterns. However, any application relying on client-supplied or dynamically generated session IDs for MongoDB-based history storage is at significant risk until the underlying framework logic is corrected to enforce strict string typing regardless of source trustworthiness.
To mitigate this vulnerability and prevent similar issues in future developments, organizations must ensure they upgrade LangChain to version 1.3.1 or later where the type enforcement mechanism has been implemented correctly. For applications unable to immediately update dependencies, implementing a defensive coding strategy is essential. This includes validating all session identifiers against a strict regular expression pattern that permits only alphanumeric characters and safe delimiters before passing them to database operations. Additionally, developers should avoid using user-supplied data directly as query keys in NoSQL databases without explicit type casting or parameterization support provided by the driver library. Adhering to these practices aligns with industry standards such as CWE-94 for Improper Control of Generation of Code and CWE-20 for Improper Input Validation, while also addressing techniques associated with ATT&CK tactic TA0001 Initial Access through injection-based exploitation methods.