LangGraph Checkpoint Stores EUVD-2026-109182

Exploitation requires ALL of: (1) use of PostgresStore, AsyncPostgresStore, SqliteStore, or AsyncSqliteStore from langgraph-checkpoint-postgres < 3.1.3 or langgraph-checkpoint-sqlite < 3.1.2 (InMemoryStore is NOT affected because it compares namespace tuples); (2) an application design that relies on namespace tuples to separate users/tenants; and (3) untrusted input being allowed to choose a namespace label that reaches get, search, delete, list_namespaces, their async equivalents, or ops passed directly to batch/abatch - note that put/aput already rejected dotted labels, so write-through-put is not the vector. The concrete trigger is a label containing '.' (e.g. ('tenant.bob',)) that dot-joins to the same stored text as ('tenant','bob'). Limiting factors: the attacker must be an authenticated low-privileged caller (PR:L) with the ability to influence namespace labels; it depends on the multi-tenant namespace-isolation usage pattern rather than a default library install; and LangSmith's HTTP store API and the Agent Server (from 0.15.5/0.16.2) already reject such labels, with LangSmith Cloud deployments fixed on next revision, so self-hosted deployments are the primary exposure.

This is a medium-severity, deployment-dependent tenant-isolation flaw rather than a broad remote-compromise bug. The supplied CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:L/VA:N, score 6.0) tells a consistent story: network-reachable and low-complexity to trigger, but it carries AT:P (a specific attack requirement) and PR:L (the actor must already be an authenticated/low-privileged caller), which is why the score lands at medium despite VC:H. The high confidentiality impact reflects cross-tenant reads; integrity is rated low (overwrite/deletion of individual items) and availability none. No CISA KEV listing is present, so this is NOT confirmed actively exploited. No EPSS score was provided, so statistical exploitation probability cannot be weighed. No standalone exploit or PoC reference was supplied - the three references are the GitHub Security Advisory, the fix PR, and the fix commit - so the status is no public exploit identified. The vuln.today decision label is 'this_month' (not act_now/emergency), aligning with the medium technical score. No explicit SSVC decision-point values (automatable, technical impact) were provided, so that framework cannot be independently applied here. Net: real but conditional priority - genuinely dangerous ONLY where one of the affected Postgres/SQLite stores is used, namespaces are relied on to separate users/tenants, AND untrusted input can choose a namespace label reaching an unvalidated method; otherwise it is a high-impact-on-paper issue with a narrow real-world trigger. The advisory's CWE-863 (improper authorization) describes the mechanism more precisely than the NVD-assigned CWE-20.

In a multi-tenant LangGraph application that uses PostgresStore or SqliteStore and relies on namespace tuples to keep tenants apart, an authenticated low-privileged user supplies a namespace label such as ('tenant.bob',). Because the store flattens namespaces with '.'.join() and these labels were not validated on get/search/delete/list_namespaces/batch, the label resolves to the victim's ('tenant','bob') namespace, letting the attacker read, overwrite, or delete another tenant's stored items. No public exploit code was identified; the mechanism is documented in the vendor advisory with concrete call examples.