CVE-2026-71433: 
Python vulnerability analysis and mitigation

CVE-2026-71433 is a namespace isolation bypass vulnerability in LangGraph's Postgres and SQLite checkpoint store implementations that allows authenticated users to retrieve stored items belonging to other tenants or users. It affects langgraph-checkpoint-postgres and langgraph-checkpoint-sqlite packages prior to version 3.1.1, maintained by langchain-ai. The vulnerability was published on August 6, 2026, with the fix merged on July 30, 2026. It carries a CVSS v3.1 base score of 5.3 (Medium) (GitHub Advisory, Feedly).

The root cause (CWE-200, CWE-863) lies in how hierarchical namespaces are serialized and queried: tuples like ("memories", "alice") are flattened to dot-joined strings (e.g., memories.alice) and scoped reads use a SQL LIKE '%' pattern match against this string. Because LIKE has no concept of the . separator, a prefix search for ("foo",) also returns rows stored under ("foobar",) or ("foo2",). Additionally, namespace labels containing SQL LIKE metacharacters (_ and %) were interpolated into the pattern unescaped, so ("user_1",) would match ("userX1",). On SQLite, LIKE is case-insensitive for ASCII, introducing a further case-mismatch bypass. Critically, this is not SQL injection — values were passed as bound parameters; the flaw is that the bound value itself was a LIKE pattern whose metacharacters were not neutralized (GitHub Advisory, Fix PR).

Successful exploitation results in unauthorized disclosure of stored checkpoint items belonging to other tenants or users, constituting a confidentiality breach in multi-tenant LangGraph deployments. There is no integrity or availability impact — get, put, and delete operations compare namespaces with strict equality (=) and were never affected; only read paths (search and list_namespaces) are vulnerable. LangSmith hosted deployments using LANGGRAPH_STORE_BACKEND=python (the default, which uses AsyncPostgresStore) are also affected, broadening the scope beyond self-hosted installations (GitHub Advisory).

No public exploit code or in-the-wild exploitation has been reported; the maintainers explicitly state they have no evidence of this behavior being exploited in the wild (GitHub Advisory). Exploitation requires low privileges (an authenticated caller) but no crafted input — an ordinary scoped search or list_namespaces call is sufficient when namespace labels meet the vulnerable conditions. The EPSS score is approximately 0.0023 (very low probability of exploitation in the near term), and the vulnerability is not listed in the CISA KEV catalog (Feedly). NVD SSVC assessment classifies exploitation as "none" and automation as "no" (Feedly).

1. Identify a vulnerable deployment: Confirm the target application uses PostgresStore/AsyncPostgresStore or SqliteStore/AsyncSqliteStore from langgraph-checkpoint-postgres or langgraph-checkpoint-sqlite < 3.1.1, and that namespaces are used as tenant or user boundaries.
2. Obtain authenticated access: Acquire valid credentials or an API token for the LangGraph application — low-privilege access is sufficient.
3. Identify namespace structure: Use list_namespaces() to enumerate existing namespaces. Look for namespaces whose flattened dot-joined form shares a leading character sequence with another tenant's namespace (e.g., your namespace is ("user", "1") and a sibling is ("user", "12")).
4. Issue a prefix-scoped search: Call store.search(("user", "1"), ...) or list_namespaces(prefix=["user", "1"]). Due to the unanchored LIKE '%' pattern, the query also returns items stored under ("user", "12") or any namespace whose dot-joined form starts with user.1.
5. Exploit metacharacter labels: If your namespace contains _ or % (e.g., ("user_1",)), a scoped search also matches sibling namespaces like ("userX1",) due to unescaped LIKE wildcards.
6. Retrieve cross-tenant data: Collect the returned items, which may include stored agent memory, conversation state, or other sensitive checkpoint data belonging to other users or tenants (GitHub Advisory, Fix PR).

• Logs: Application-level logs showing search() or list_namespaces() calls returning items from namespaces not owned by the requesting user; unexpected cross-tenant namespace entries in query results.
• Database: SQL query logs (if enabled) showing LIKE patterns matching multiple dot-joined namespace prefixes in a single query against the store table; queries returning rows with prefix values that do not exactly match the requested namespace prefix.
• Behavioral: A single authenticated user or API token repeatedly calling list_namespaces() or search() with short or common prefix values (e.g., single-character or numeric prefixes) that would match many sibling namespaces — potentially indicative of namespace enumeration (GitHub Advisory).

Upgrade to langgraph-checkpoint-postgres==3.1.1 or langgraph-checkpoint-sqlite==3.1.1, released July 30, 2026, which fix the issue by anchoring namespace prefix matching to segment boundaries, escaping LIKE metacharacters, and switching SQLite's descendant match from LIKE to GLOB (Postgres Release, SQLite Release). As an operational workaround prior to patching, use fixed-length namespace labels such as UUIDs — no UUID can be a string prefix of another, and UUIDs contain no _ or % characters. Where namespace labels are user-supplied, validate them at the application boundary rather than relying solely on store-level scoping (GitHub Advisory). Note that InMemoryStore compares namespaces element-wise and was never affected.

The vulnerability was reported by researcher VuxNx and fixed by Elior Nataf Lackritz (eliornl) of the LangGraph team, with the fix merged on July 30, 2026 (Fix PR). A community member (Aleksandr Filippov) confirmed post-fix that a previously filed related issue (#8300, covering PostgresStore.search() unescaped LIKE matching) was also resolved by the same PR (Fix PR). The advisory notes that a JavaScript port of the same issue was subsequently identified in langgraph-checkpoint-js (tracked separately as langchain-ai/langgraphjs#2721), indicating broader ecosystem awareness of the pattern (Fix PR).