LangGraph MongoDB checkpointer opened cross-tenant memory to filter injection

LangGraph's MongoDB checkpointer shipped a bug that let a caller read another tenant's agent state. GHSA-533j-2v4q-mw5h, tracked as CVE-2026-55253 with a CVSS of 7.7, covers MongoDBSaver.list() and MongoDBStore.search() accepting a filter without rejecting $-prefixed MongoDB operator keys. Send an operator instead of a plain value and the query steps outside its thread scope.

That matters if you're running LangGraph with MongoDB as the backing store for more than one tenant or user. It gives a caller a way to read state that isn't theirs, not a crash or a denial of service. The fix landed in langgraph-checkpoint-mongodb 0.3.0 and langgraph-store-mongodb 0.4.0.

A parallel npm advisory, CVE-2026-48121, covers the same bug class in the JS packages. Unenforced identifier types let $gt and $ne bypass thread scoping there too, fixed in 1.3.1. Same shape of bug, two ecosystems, two separate patch numbers to track if you're running both.

The advisory doesn't say how long the bug was live or whether anyone found evidence of it being exploited before the fix. It also doesn't say whether other LangGraph checkpointer backends, like Postgres or Redis, share the same filter-handling pattern.

I've built on LangGraph. The checkpointer is exactly the kind of code path nobody reviews for injection, because it feels like internal plumbing, not a query boundary. The moment agent state serves more than one tenant, every filter parameter it accepts is untrusted input and needs to be treated that way. Check your version now. The list() and search() calls built from caller-supplied filters are the ones to audit first.