LangGraph: a dot in a namespace label reaches another tenant's data

01What happened

LangChain published advisory GHSA-6hmw-9432-67qq for LangGraph on 21 October 2026 and credits VuxNx as the reporter. The flaw carries CVE-2026-115883 and affects the Postgres and SQLite store backends. GitHub reviewed it and added it to its advisory database on 23 October.

02How it works

Both stores join the labels of a namespace tuple with a dot to build one stored key, so a single label that already contains a dot collides with a multi-label namespace: the tuple with the label tenant.bob lands where the tuple of tenant then bob lands. The put method rejected dotted labels, but get, search, delete and list_namespaces did not, nor their async forms, nor operations passed through batch and abatch. A caller who supplies such a label reads, overwrites or deletes items in the other namespace.

03Who is affected

Deployments on langgraph-checkpoint-postgres before 3.1.3 or langgraph-checkpoint-sqlite before 3.1.2 are exposed where namespace labels come from untrusted input. InMemoryStore is not. LangSmith Cloud is patched automatically, while self-hosted Agent Server needs 0.15.5 or 0.16.2.

04What to do

Upgrade to langgraph-checkpoint-postgres 3.1.3 or langgraph-checkpoint-sqlite 3.1.2, which reject invalid labels with InvalidNamespaceError. Stores implemented outside the repository should call langgraph.store.base.validate_op_namespace on each operation.

Questions people ask

Which LangGraph packages do I need to upgrade for CVE-2026-115883?

Upgrade langgraph-checkpoint-postgres to 3.1.3 or langgraph-checkpoint-sqlite to 3.1.2. Both require langgraph-checkpoint 4.3.0 and reject a namespace label containing a dot with InvalidNamespaceError. Self-hosted LangSmith Deployment Agent Server needs version 0.15.5 or 0.16.2, while LangSmith Cloud deployments receive the fix automatically without any operator action.

Is LangGraph's InMemoryStore affected by the namespace collision?

InMemoryStore is not affected by CVE-2026-115883. The advisory limits the flaw to the Postgres and SQLite store backends, which join namespace labels with a dot into a single stored key. The collision between a dotted single label and a two-label namespace does not arise in the in-memory store, so no upgrade is needed for it.

Am I exposed if my LangGraph namespace labels are not user-supplied?

Exposure depends on who controls the namespace label. CVE-2026-115883 needs a caller able to supply a label containing a dot, which the advisory frames as an attacker controlling that label. Applications that build namespaces only from trusted server-side values are much less exposed, though upgrading the store package remains the advisory's remediation.

Sources 3 links, all fetched

1. 1github.comLangGraph Advisory
2. 2github.comGitHub Advisory DB
3. 3pypi.orgPostgres Store On PyPI