GHSA-m6rx-h84q-8r95: Npm/@langchain/mongodb vulnerability
Impact
MongoDBChatMessageHistory did not enforce the documented string type for session identifiers at runtime. In affected applications, a structured session identifier could be interpreted as a MongoDB query condition rather than as a literal identifier.
Applications are affected when they pass untrusted session identifier input to MongoDBChatMessageHistory and store multiple users’ histories in the same collection. An attacker who can invoke chat-history operations may be able to read, modify, or delete another user’s stored conversation.
Applications that derive the session identifier from an authenticated, server-controlled value and enforce its type are not affected by this path.
Patches
The issue is fixed in @langchain/mongodb version 1.3.1.
Users of affected versions should upgrade to version 1.3.1 or later. The patched version validates session identifiers at runtime and ensures they are compared as literal values in MongoDB queries.
Workarounds
If an immediate upgrade is not possible, applications must reject session identifiers that are not non-empty strings. Session identifiers should be derived from an authenticated, server-controlled value and must not be passed directly from an untrusted request field.
Upgrading remains the recommended remediation.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/@langchain/mongodbto a version that resolves this vulnerability.Fixed in 1.3.1 - Upgrade
Upgrade
@langchain/mongodbto a version that resolves this vulnerability.Fixed in 1.3.1 - Configuration
Reject session identifiers that are not non-empty strings.
MongoDBChatMessageHistory session identifier validation = non-empty strings - Compensating control
Derive session identifiers from an authenticated, server-controlled value and do not pass them directly from an untrusted request field.
Event History
Frequently Asked Questions
Which applications are exposed to this issue?
Applications are exposed when they pass untrusted session identifier input to MongoDBChatMessageHistory and store multiple users' histories in the same MongoDB collection. Applications that derive identifiers from an authenticated, server-controlled value and enforce that they are strings are not affected through this path.
What access does an attacker need to exploit it?
An attacker needs to be able to invoke chat-history operations and influence the session identifier supplied to MongoDBChatMessageHistory. A structured identifier may then be interpreted as a MongoDB query condition, potentially targeting another user's history.
What is the impact of successful exploitation?
An attacker may be able to read, modify, or delete another user's stored conversation history when multiple users' histories share a collection.
What should be done if an upgrade cannot be applied immediately?
Reject any session identifier that is not a non-empty string. Derive session identifiers from an authenticated, server-controlled value rather than accepting them from untrusted input.
What version contains the fix?
Upgrade @langchain/mongodb to version 1.3.1 or later. The patched version validates session identifiers at runtime and compares them as literal MongoDB values.