LangChain MongoDB EUVD-2026-93771

Exploitation requires a specific deployment: multiple users' chat histories stored in one shared MongoDB collection AND an application that feeds an untrusted, attacker-controllable structured sessionId (a JS object, not a validated string) into MongoDBChatMessageHistory in @langchain/mongodb before 1.3.1. The attacker must be an authenticated low-privilege user (PR:L) able to invoke chat-history read/add/clear operations and able to supply a non-string sessionId such as {$regex:...} or {$ne:null}. LIMITING FACTORS: applications that derive sessionId from an authenticated, server-controlled string (the documented correct usage) are not affected; per-user/isolated collections also neutralize cross-tenant impact; and the AT:P attack requirement reflects that the vulnerable wiring is non-default rather than guaranteed.

This is a moderate-severity NoSQL injection (CWE-943) whose real-world risk is tightly gated by deployment architecture rather than being a broad, drive-by threat. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:L/VA:N) scores 6.0: network-reachable and low-complexity, but with an explicit attack requirement (AT:P) and a required low-privilege foothold (PR:L), meaning the attacker must already be an authenticated participant able to invoke chat-history operations. No EPSS score was provided in the input and the CVE is not listed in CISA KEV, so there is no signal of automated or widespread exploitation. There is no separately flagged weaponized POC, but the fix PR (#11672) ships a regression test that publicly demonstrates the exact injection technique (passing {$regex:'^victim-'} or {$ne:null} as sessionId), so the mechanism is openly documented. The confidentiality impact is genuinely high (VC:H - reading other users' conversations), while integrity is rated low and availability nil. Net: this is a real, patch-worthy issue for any multi-tenant application that stores several users' histories in one shared MongoDB collection AND wires an untrusted structured sessionId into it - but it is explicitly not exploitable for applications using authenticated, server-controlled string identifiers, which is the documented safe pattern. Treat it as a targeted, configuration-dependent flaw rather than a universally critical one.

A multi-tenant LLM application stores every user's chat history in a single shared MongoDB collection and passes a client-supplied sessionId value straight into MongoDBChatMessageHistory without validating it is a string. An authenticated low-privilege attacker submits a sessionId that is a MongoDB operator object such as {"$regex":"^victim-"} or {"$ne":null}, causing the query filter to match other users' documents so the attacker can read, overwrite, or clear victim conversations. No standalone weaponized exploit is published, but the fix commit's regression test publicly demonstrates the technique.