LangChain MongoDB chat history: query injection crosses sessions
A structured session identifier became a MongoDB query condition in @langchain/mongodb, reaching other users' stored conversations.
· LangChain · Research by iaohkut-from-NightWolf-Team
CVE-2026-106119 lets an attacker who controls a session identifier read, change or delete another user's chat history in @langchain/mongodb. The library passed the identifier into a MongoDB query without enforcing a string type.
01What happened
LangChain published advisory GHSA-m6rx-h84q-8r95 for the @langchain/mongodb package on October 5, 2026. Credit for the report goes to iaohkut-from-NightWolf-Team. The affected versions, the fixed release and the assigned identifiers are listed below.
02How it works
MongoDBChatMessageHistory did not enforce the string type for session identifiers at runtime, so a structured value was interpreted as a MongoDB query condition rather than a literal. An attacker who supplies such an identifier can match documents beyond the intended session and then read, modify or delete those messages. The patch rejects session identifiers that are not strings and wraps query filters in the $eq operator so values compare literally.
03Who is affected
Applications built on @langchain/mongodb 1.3.0 and earlier are exposed when they pass untrusted session identifiers to MongoDBChatMessageHistory and keep several users' histories in one collection. Deployments that derive identifiers server-side from authenticated values are not reachable through this flaw.
04What to do
Upgrade @langchain/mongodb to 1.3.1. Where an upgrade has to wait, reject any session identifier that is not a non-empty string, and derive identifiers from authenticated, server-controlled values instead of untrusted request fields. Note that 1.3.1 turns an empty-string session identifier into an error.
Sources 2 links, all fetched
- 1github.comGitHub Advisory
- 2github.comRelease 1.3.1