CVE-2026-48121 in langgraphjs
Summary
by MITRE • 08/04/2026
@langchain/langgraph-checkpoint-mongodb provides a LangGraph.js CheckpointSaver implementation that uses MongoDB for storage. Versions 1.3.0 and below are vulnerable to NoSQL injection: checkpoint identifiers (thread_id, checkpoint_ns, checkpoint_id) from config.configurable are passed into MongoDB find() queries in MongoDBSaver.getTuple() without type enforcement. If an attacker supplies an object payload (such as MongoDB operators $gt or $ne) instead of a string, it can be interpreted as a query operator, bypassing thread scoping and leaking checkpoints, including pending writes, across tenants. Applications are at risk if they forward untrusted input into config.configurable without coercing it to strings or validating it against a schema, particularly in multi-tenant or user-isolated setups. Apps that only use server-issued, string-typed identifiers with schema validation rejecting non-string fields are not affected. This issue has been 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 • 08/04/2026
This vulnerability resides within the @langchain/langgraph-checkpoint-mongodb package where the MongoDBSaver.getTuple() method fails to properly validate or sanitize checkpoint identifiers before incorporating them into MongoDB find() queries. The flaw stems from the lack of type enforcement when processing thread_id, checkpoint_ns, and checkpoint_id values that originate from the config.configurable object. These identifiers should logically be string-typed values representing unique thread references but can be manipulated by attackers to inject malicious MongoDB operators such as $gt or $ne into database queries.
The technical implementation issue manifests when untrusted input flows directly into MongoDB query parameters without proper sanitization or type coercion. When attackers provide objects instead of strings as checkpoint identifiers, the MongoDB driver interprets these objects as query operators rather than simple search values. This misinterpretation enables bypassing the intended thread scoping mechanisms that should isolate checkpoints belonging to different tenants or users. The vulnerability creates a cross-tenant data leakage scenario where malicious actors can access checkpoints from other users or threads by crafting specific query payloads that exploit the lack of input validation.
From an operational standpoint, this vulnerability poses significant risks in multi-tenant environments where different users or applications share the same MongoDB instance but require data isolation. Applications using server-side generated string identifiers with proper schema validation remain unaffected since these cannot be manipulated to inject malicious operators. However, systems that accept user-provided configuration values without proper type enforcement create an attack surface where adversaries can escalate privileges by accessing checkpoints belonging to other tenants. The impact extends beyond simple data exposure as it may also allow attackers to access pending writes and potentially manipulate the state of other users' workflows.
Security mitigations should focus on implementing strict input validation and type coercion for all checkpoint identifiers before they are processed by MongoDB queries. Applications must enforce string-typed values for thread_id, checkpoint_ns, and checkpoint_id fields through schema validation or explicit type conversion. The implementation should leverage parameterized queries or proper sanitization techniques to prevent injection of MongoDB operators. Organizations should also consider implementing additional access controls and monitoring mechanisms to detect unauthorized access patterns in multi-tenant deployments. This vulnerability aligns with CWE-94 (Improper Control of Generation of Code) and represents a specific instance of NoSQL injection that can be categorized under ATT&CK technique T1213.002 (Data from Information Repositories) where adversaries exploit weak input validation to access restricted data within database systems.
The fix implemented in version 1.3.1 addresses the root cause by enforcing proper type checking and sanitization of checkpoint identifiers before database operations. This remediation ensures that all identifiers are converted to strings or validated against expected formats, preventing malicious operators from being interpreted as part of the query structure. Organizations should prioritize updating to this patched version while implementing comprehensive input validation policies across their entire application stack to prevent similar vulnerabilities in other components that interact with database systems.