Langchainjs
Monthly
NoSQL injection in the @langchain/mongodb provider (part of langchainjs) before version 1.3.1 lets an authenticated low-privilege user read, modify, or delete another user's stored conversation history when multiple users' chat histories live in a shared MongoDB collection and the application passes an untrusted, attacker-controllable structured sessionId into MongoDBChatMessageHistory. The root cause is that the documented string type for sessionId is only enforced by TypeScript at compile time and is erased at runtime, so a value such as {$regex: "^victim-"} is handed straight into the MongoDB query filter and interpreted as a query operator rather than a literal identifier. Impact is tightly gated: applications that derive sessionId from an authenticated, server-controlled string (the documented correct usage) or that isolate histories per user are not affected, and no public exploit code was identified at time of analysis, with no confirmed active exploitation (CISA KEV).
RediSearch query injection in @langchain/redis (the Redis vector store provider for LangChain.js) prior to version 1.1.1 lets a low-privileged attacker who can influence the values passed into structured RediSearch TAG or TEXT filters inject unescaped RediSearch syntax and thereby broaden or otherwise alter the generated search query. Where an application uses such a filter as a tenant or document-access boundary, the manipulated query can return indexed documents outside the attacker's intended scope, resulting in limited confidentiality impact (read/exposure only, no write, code execution, or availability effect). Exploitation is highly conditional: the assessed vector is CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N (CVSS 4.0 base 2.3), no public exploit code has been identified, and no confirmed active exploitation (CISA KEV) or EPSS signal was provided, so overall risk is low; the fix is available in @langchain/redis 1.1.1.
NoSQL injection in the @langchain/mongodb provider (part of langchainjs) before version 1.3.1 lets an authenticated low-privilege user read, modify, or delete another user's stored conversation history when multiple users' chat histories live in a shared MongoDB collection and the application passes an untrusted, attacker-controllable structured sessionId into MongoDBChatMessageHistory. The root cause is that the documented string type for sessionId is only enforced by TypeScript at compile time and is erased at runtime, so a value such as {$regex: "^victim-"} is handed straight into the MongoDB query filter and interpreted as a query operator rather than a literal identifier. Impact is tightly gated: applications that derive sessionId from an authenticated, server-controlled string (the documented correct usage) or that isolate histories per user are not affected, and no public exploit code was identified at time of analysis, with no confirmed active exploitation (CISA KEV).
RediSearch query injection in @langchain/redis (the Redis vector store provider for LangChain.js) prior to version 1.1.1 lets a low-privileged attacker who can influence the values passed into structured RediSearch TAG or TEXT filters inject unescaped RediSearch syntax and thereby broaden or otherwise alter the generated search query. Where an application uses such a filter as a tenant or document-access boundary, the manipulated query can return indexed documents outside the attacker's intended scope, resulting in limited confidentiality impact (read/exposure only, no write, code execution, or availability effect). Exploitation is highly conditional: the assessed vector is CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N (CVSS 4.0 base 2.3), no public exploit code has been identified, and no confirmed active exploitation (CISA KEV) or EPSS signal was provided, so overall risk is low; the fix is available in @langchain/redis 1.1.1.