Description

LangChain MongoDB provides integrations between MongoDB, Atlas, LangChain, and LangGraph. Prior to langgraph-checkpoint-mongodb 0.3.0 and langgraph-store-mongodb 0.4.0, MongoDBSaver.list(), MongoDBSaver.alist(), and MongoDBStore.search() incorporate filter dictionaries into MongoDB queries without recursively rejecting keys prefixed with $. An authenticated caller who controls a filter argument through HTTP query parameters, request body fields, or agent tool arguments can inject MongoDB Query Language operators such as $regex or $where. In a multi-tenant deployment that uses the filter to enforce per-user or per-tenant isolation, injected operators can bypass intended equality filtering and expose other tenants' checkpoint or store data. Filters constructed entirely from trusted server-side values have lower practical risk. This issue is fixed in langgraph-checkpoint-mongodb 0.3.0 and langgraph-store-mongodb 0.4.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.7",
  "pubDate": "2026-09-14T18:17:55.500Z",
  "pubdate": "2026-09-14T18:17:55.500Z",
  "executiveSummary": "The vulnerability is a MongoDB Query Language (MQL) injection flaw found in LangChain MongoDB integration packages, specifically langgraph-checkpoint-mongodb and langgraph-store-mongodb.\nThe root cause is the failure to recursively sanitize input filters, allowing authenticated users to inject unauthorized MQL operators such as $regex or $where into database queries.\nThe impact is significant for multi-tenant environments where these filters are used to enforce data isolation; successful exploitation allows an attacker to bypass intended equality constraints, resulting in unauthorized access to sensitive checkpoint or store data belonging to other tenants.\nThis vulnerability requires an authenticated attacker capable of influencing filter arguments via application input vectors like HTTP parameters, request bodies, or agent tool arguments.\nThe risk is critical in systems relying on these filters for tenant-level isolation, as it facilitates unauthorized cross-tenant data exfiltration.\nThe issue is addressed by updating to langgraph-checkpoint-mongodb 0.3.0 and langgraph-store-mongodb 0.4.0.",
  "technicalDetails": "The vulnerability resides within the implementation of MongoDBSaver.list(), MongoDBSaver.alist(), and MongoDBStore.search() methods. These functions accept user-provided filter dictionaries which are subsequently passed directly into MongoDB query execution contexts without sufficient structural validation.\nThe core of the vulnerability lies in the lack of recursive sanitization for keys prefixed with the '$' symbol. MongoDB query operators (e.g., $regex, $where, $gt, $ne) are interpreted by the database engine when present in query objects. By failing to block these keys, the application layer allows an attacker to alter the intended logic of the database query.\nIn a typical multi-tenant deployment, developers use filters to restrict query results to a specific tenant ID (e.g., {'tenant_id': 'user_123'}). An attacker can manipulate the input to provide a dictionary such as {'tenant_id': {'$ne': 'user_123'}}, which negates the intended filter and instructs the database to return all records except those belonging to the attacker, effectively exposing the entire dataset.\nAttack flow: 1. An authenticated attacker identifies an input vector (such as an API endpoint or agent tool) that propagates parameters into a MongoDB filter object. 2. The attacker crafts a malicious payload containing MQL operators. 3. The vulnerable method accepts the input and constructs the MQL query object containing the injected operator. 4. The MongoDB driver executes the query, now containing the injected operator, against the backend database. 5. The application returns the results of the modified query, disclosing data outside the scope of the intended tenant isolation policy.\nThis vulnerability is present in versions of langgraph-checkpoint-mongodb prior to 0.3.0 and langgraph-store-mongodb prior to 0.4.0. The exploitability is contingent on the application design relying on these client-provided filters for authorization and access control logic. The severity is significantly elevated in deployments where these filters serve as the primary security mechanism for ensuring data privacy between distinct users or organizational units."
}