Can LangGraph's AI Memory Bug Expose Another User's Data?

August 6, 2026

CVE-2026-71433 could let LangGraph memory searches cross user namespace boundaries. See who is affected, what is confirmed, and how to patch and audit it.

Yes, under specific conditions. LangGraph's CVE-2026-71433 could let an ordinary scoped search return another user's stored AI memories when one namespace label was a prefix of another. The flaw affects Postgres and SQLite store packages before version 3.1.1, including a default backend used by some LangSmith deployments. There is no public evidence that attackers exploited it, and the bug did not affect every memory operation or every namespace design.

If you operate a LangGraph application, upgrade both relevant checkpoint packages, identify how user or tenant namespaces are constructed, and review whether search results could have crossed those boundaries. This is a data-separation failure, not proof that every LangGraph agent leaked its memory.

What Is Confirmed

GitHub published the official LangGraph security advisory GHSA-47pj-3jcm-6whg on August 6, 2026. The issue is assigned CVE-2026-71433, a CVSS 3.1 score of 5.3 (medium), and classifications for exposure of sensitive information and incorrect authorization.

The maintainer confirms that:

• langgraph-checkpoint-postgres versions below 3.1.1 are affected.
• langgraph-checkpoint-sqlite versions below 3.1.1 are affected.
• Scoped search and list_namespaces reads could cross an intended namespace boundary.
• No crafted SQL or SQL injection was required. An ordinary scoped read could be enough.
• Exact get, put, and delete operations used equality and were not affected.
• The in-memory store compared namespace segments directly and was not affected.
• The issue can reach hosted LangSmith deployments using the affected store backend.
• The maintainer has no evidence of exploitation in the wild.

The fixes are available in langgraph-checkpoint-postgres 3.1.1 and langgraph-checkpoint-sqlite 3.1.1. Both release notes identify segment-boundary matching as the relevant change.

How Could One User's AI Memory Match Another User's Namespace?

LangGraph stores long-term memories as documents organized by a namespace and key. Its persistence documentation shows a typical namespace such as (user_id, "memories"), then uses store.search(namespace) to retrieve that user's saved memories.

Postgres and SQLite stored the hierarchical namespace as one dot-joined string. Conceptually:

The vulnerable scoped read treated the first value as a string prefix. A pattern equivalent to alice% understands characters, not namespace segments. It can therefore match both alice and alice2.

That distinction is the entire bug. The application intended "everything inside Alice's namespace." The database pattern implemented "everything whose flattened text begins with these characters."

The advisory describes four boundary errors:

1. Sibling-prefix matches: a search for foo could also return foobar or foo2.
2. Pattern metacharacters: namespace labels containing _ or % could expand the match because those characters have special meaning in SQL LIKE patterns.
3. Suffix matches: a suffix such as alice could match a different leaf such as malice.
4. SQLite case matching: SQLite's default ASCII case-insensitive LIKE behavior could make scoped search disagree with exact read and write operations.

The patch requires either an exact namespace match or the actual . separator before descendant segments. It also escapes pattern characters and makes prefix and suffix behavior segment-aware.

Who Is Actually Affected?

The package version alone does not tell you whether data crossed between users. The advisory says the vulnerable behavior matters when all of these conditions line up:

• Your application uses the Postgres or SQLite LangGraph store.
• It relies on namespace scoping to separate users, customers, workspaces, or tenants.
• It performs search or list_namespaces reads on those stores.
• Namespace labels can share textual prefixes, contain pattern characters, or encounter the documented suffix or case behavior.

A simple risk matrix makes the distinction clearer:

Do not read the UUID exception too broadly. It addresses the exact matching conditions in this advisory. It is not a general guarantee that UUID-based tenancy, the rest of the application, or another dependency is secure.

Does CVE-2026-71433 Affect LangSmith Hosted Deployments?

It can. The advisory explicitly says the issue reaches hosted deployments, unlike some earlier store advisories.

LangChain's custom-store documentation says deployed agents receive a built-in Postgres-backed long-term memory store by default. The CVE notice adds the implementation detail: deployments using the default Python backend use the affected AsyncPostgresStore. Deployments configured with the separate gRPC backend received an equivalent fix.

That does not establish that every LangSmith tenant was exposed, that every hosted revision used a vulnerable build at the same time, or that anyone retrieved another customer's data. Only the vendor can provide complete platform-wide deployment and access evidence.

If you use LangSmith Cloud, ask a narrower set of questions:

• Which backend and package version handled the store for each affected revision?
• When was the equivalent hosted fix deployed?
• Did your graph use namespaces as its user or tenant boundary?
• Could namespace labels share prefixes or contain special characters?
• Are there query, trace, or response records that can show which scoped searches ran?

Why Is The Severity Only Medium If Memory Can Cross Tenants?

CVSS describes exploit conditions and technical impact, not the sensitivity of every application's data.

The official vector includes high confidentiality impact but no integrity or availability impact. It also reflects conditions that make exploitation less universal: the caller needs access to a read path, the namespace design must be susceptible, and only certain store operations are affected.

For one application, the exposed item might be a harmless preference. For another, a long-term memory could contain customer context, internal project details, contact information, extracted file facts, health concerns, or instructions used by an agent. The same CVE can therefore be operationally minor in one deployment and a serious privacy incident in another.

The right response is not to relabel the score. It is to combine the advisory's technical score with your own data classification, tenant model, and evidence of affected reads.

What Should LangGraph Operators Do Now?

1. Upgrade Both Store Packages

Upgrade langgraph-checkpoint-postgres and langgraph-checkpoint-sqlite to 3.1.1 or newer wherever they appear. Check application lockfiles, container images, worker images, notebooks, background jobs, and deployed revisions rather than only a developer laptop.

If you use only one backend, confirm that the unused package is not still bundled into another service or test environment.

2. Inventory Namespace Construction

Find the code that creates store namespaces. Record:

• which segment represents a user or tenant;
• whether labels are emails, usernames, numeric IDs, slugs, or UUIDs;
• whether labels can contain _ or %;
• whether case is normalized;
• whether one valid label can be a prefix of another;
• which code paths call search or list_namespaces.

Do not assume that adding a tenant ID to a tuple created an authorization boundary. A namespace is a data-selection mechanism; the application still needs authenticated identity, authorization checks, and tests that prove the selection cannot cross tenants.

3. Test The Boundary, Not Just The Happy Path

Create harmless test tenants with names designed to collide, such as user1 and user12. Add canary records to each. Verify that every scoped read returns only the intended canary after the upgrade.

Also test:

• mixed case;
• underscore and percent characters if your identifiers allow them;
• prefix and suffix namespace filters;
• synchronous and asynchronous store clients;
• old workers during a rolling deployment.

This is safer and more informative than querying real customer memories to see whether something unexpected appears.

4. Investigate Possible Exposure Carefully

The advisory does not give operators a universal forensic query. Your evidence will depend on what the application logs and whether it records store operations or only final agent responses.

Review scoped searches during the vulnerable period, the namespace supplied, the returned item namespaces, and whether any returned content reached a model response, trace, tool call, or downstream system. Preserve evidence before changing retention settings.

If you find cross-user data, follow your incident-response and notification process. Do not conclude "no breach" merely because no error appeared: the vulnerable request could succeed normally.

5. Separate Selection From Authorization

Use fixed-length opaque tenant identifiers when practical, but treat that as defense in depth. Enforce the authenticated tenant at the service layer and, for high-risk multi-tenant systems, consider database controls that do not rely entirely on a text prefix.

Add regression tests that fail whenever a query for one tenant returns a record whose stored tenant identity differs. The most valuable test is an invariant: every result must belong to the authenticated principal, regardless of how the storage adapter implements a namespace.

What Is Still Unclear

Several material facts are not established by the disclosure:

• How many deployments were exposed. Neither the advisory nor the release notes provide an affected-install count.
• Whether anyone exploited the flaw. The maintainer says it has no evidence of exploitation; absence of evidence is not proof that no cross-boundary read occurred.
• The complete hosted remediation timeline. Package releases were published before the public CVE, but the advisory does not provide a deployment-by-deployment LangSmith timeline.
• What data any affected application stored. LangGraph namespaces can contain many kinds of JSON documents; sensitivity depends on the application.
• Whether an exposed item reached a user. A store could return an extra item without the application displaying it, or it could pass the item into a model and later surface it. Operators need their own traces and outputs.
• Whether independent researchers have reproduced real-world exposure. At publication time, current searches found the primary advisory and patch material but no independent exploitation report.

These uncertainties should appear in any defensible headline or incident assessment. "Could expose" is supported. "LangGraph leaked everyone's memories" is not.

The Larger AI Privacy Lesson: A Memory Label Is Not A Security Boundary

Agent memory creates a tempting shortcut: place each user's records under a user-shaped namespace, then search inside that namespace whenever the agent needs context. That can be a useful organization scheme. It is not automatically authorization.

A reliable memory boundary needs several layers:

1. The request is tied to an authenticated user or tenant.
2. The application derives the namespace from trusted identity, not arbitrary prompt text.
3. The storage query preserves segment boundaries.
4. Every returned record is checked against the intended owner.
5. Logs and traces make an unexpected cross-boundary result detectable.
6. Deletion and retention operate on the same identity model.

CVE-2026-71433 failed at layer three. The impact became possible because some applications expected that layer to carry the weight of layer four as well.

This is also why AI memory privacy cannot be judged from a settings label alone. Ask where memories live, how they are separated, what retrieves them, what reaches the model, and what evidence exists when the boundary fails.

Where OpenVeil Fits - And Where It Does Not

OpenVeil is a privacy-focused hosted AI workspace for adults. Its normal chat history and custom personas are stored in the user's browser rather than maintained as a normal server-side chat-history record. That can reduce the centralized history surface for someone who wants AI chat, private search, files, voice, images, and video without operating a multi-tenant LangGraph memory service.

That is a product-architecture difference, not a claim that OpenVeil is fully offline or immune to unrelated vulnerabilities. Active requests still require processing by OpenVeil and necessary providers. Browser-local history can still be exposed through the device, browser profile, extensions, sync behavior, or content a user sends again.

OpenVeil does not patch LangGraph, audit your agent deployment, or protect a separate LangGraph installation. If you operate an affected store, upgrade it. If your real need is a ready-to-use privacy-focused AI workspace rather than a custom stateful agent platform, compare the documented boundaries and try OpenVeil's one-time preview without a card.

For related boundary analysis, see our guides to browser-local AI chat history and the separate Langflow 1.11.0 security bundle.

Frequently Asked Questions

What is CVE-2026-71433?

CVE-2026-71433 is a LangGraph store vulnerability in which Postgres and SQLite namespace searches could match beyond the intended namespace segment. In susceptible multi-user applications, a scoped read could return another user's stored items.

Which LangGraph versions fix the memory namespace bug?

The official advisory identifies langgraph-checkpoint-postgres 3.1.1 and langgraph-checkpoint-sqlite 3.1.1 as the first patched versions. Upgrade to 3.1.1 or a newer supported release.

Was this SQL injection?

No. The advisory says values were bound parameters, not injected into SQL text. The flaw was that the bound value acted as a pattern and did not preserve namespace segment boundaries.

Did the bug change or delete memories?

Not according to the advisory. The documented impact is confidentiality through affected read paths. Exact put, get, and delete operations used equality and were not affected by this CVE.

Were fixed-length UUID namespaces affected?

The maintainer says fixed-length identifiers such as UUIDs, without _ or %, do not meet the documented prefix condition because one cannot be the full prefix of another of the same length. That does not guarantee the rest of an application's authorization design is secure.

Does a lack of exploitation evidence mean no data was exposed?

No. It means the maintainer has not identified public evidence of exploitation. Operators still need to review their versions, namespace design, scoped reads, traces, and returned records to determine their own exposure.

Is every LangSmith deployment affected?

The advisory says the issue can reach hosted deployments and identifies relevant backends, but it does not say every deployment exposed data. Version, backend, namespace design, operations used, and the hosted remediation timeline all matter.

Bottom Line

LangGraph's memory namespace flaw is a real cross-user confidentiality risk with a clear patch and important limits. Upgrade the Postgres and SQLite store packages to 3.1.1 or newer, test colliding namespace labels, and investigate whether any scoped read returned records outside the authenticated tenant.

The durable lesson is broader than one CVE: organize AI memories with namespaces, but enforce privacy with authorization, segment-aware queries, result validation, and evidence you can audit.