LangGraph store flaw let one tenant reach another's data
A namespace check missing from read and delete calls meant a single dot in a label could cross tenant boundaries, LangChain said in an advisory published on 23 October 2026.
By The Agentic Times ·

LangChain has disclosed a vulnerability in LangGraph's Postgres and SQLite checkpoint stores that allowed callers to read, overwrite or delete data belonging to other namespaces. The advisory, GHSA-6hmw-9432-67qq, was published on 23 October 2026 and carries the identifier CVE-2026-115883. All releases of langgraph-checkpoint-postgres before 3.1.3 and langgraph-checkpoint-sqlite before 3.1.2 are affected.
The cause is a mismatch between how namespaces are stored and how they are checked. According to the advisory, both stores save a namespace as its labels joined with a full stop, so the two-part namespace ("tenant", "bob") and the single-part namespace ("tenant.bob",) resolve to the same stored string. The base store class rejected labels containing a dot in put and aput, but not in get, search, delete, list_namespaces or their async versions. The batch and abatch methods checked nothing at all, including the put operations passed inside them.
That gap means a crafted label spells out a different namespace. The advisory gives concrete examples. Calling get or search on ("tenant.bob",) returned data stored under ("tenant", "bob"). Calling delete on ("tenant.alice",) deleted the item stored under ("tenant", "alice"). Passing a put operation for ("tenant.bob",) through batch overwrote that tenant's item.
LangChain said applications may be affected if they use one of these stores, rely on namespaces to keep users or tenants apart, and allow untrusted input to choose a namespace label that reaches a read, delete or batch call. The InMemoryStore compares namespaces as tuples rather than joined text and is not affected.
One consequence of the original put restriction is that the damage is bounded in one respect. Because labels written through put could never contain a dot, the company said no stored data becomes unreachable once the fix is applied.
The flaw also reached LangSmith Deployment. The advisory said the HTTP store API already rejected labels containing dots, but store calls made from within graph code bypassed that check and hit the same problem. The Agent Server rejects these labels from versions 0.15.5 and 0.16.2. On LangSmith Cloud, new deployments and revisions already include the fix, and existing deployments pick it up on their next revision. Self-hosted deployments need to upgrade themselves.
The remedy is to move to langgraph-checkpoint-postgres 3.1.3 or langgraph-checkpoint-sqlite 3.1.2. Both require langgraph-checkpoint 4.3.0. In that release, get, search, delete and list_namespaces reject labels that are empty, are not strings, or contain a dot, raising an InvalidNamespaceError. The Postgres and SQLite stores apply the same check to every operation passed to batch and abatch.
LangChain added guidance for anyone running their own store implementations. Stores outside the LangGraph repository that turn namespaces into delimited text can call langgraph.store.base.validate_op_namespace for each operation they run, the advisory said.
The pattern is a familiar one in multi-tenant systems: a separator character used to flatten structured identifiers into a single string, combined with validation applied at only one of several entry points. In agent deployments, where graph code can issue store calls directly, every path into the store needs the same check.
Sources
- github.comhttps://github.com/advisories/GHSA-6hmw-9432-67qq
