LangChain Patched AI Memory Flaws That Could Cross User Boundaries. Are You Affected?

October 12, 2026

LangChain patched chat-history and AI-memory isolation flaws that could cross user boundaries in affected apps. Check the versions, conditions, and fixes.

LangChain Patched AI Memory Flaws That Could Cross User Boundaries. Are You Affected?

Short answer: Newly published LangChain and LangGraph security advisories describe conditional flaws that could let one user reach another user's stored AI conversation or long-term memory. One affects MongoDBChatMessageHistory in @langchain/mongodb through version 1.3.0. Another affects LangGraph.js Postgres stores before 1.0.6 and Redis stores before 1.0.12.

These are serious isolation failures, but they are not evidence that every LangChain app leaked chats. The MongoDB path requires an application to accept an untrusted structured session identifier and store multiple users' histories in one collection. The LangGraph paths matter when an application relies on affected namespace matching as a security boundary. The maintainers have published fixes, and no reviewed source establishes exploitation in the wild.

If you operate an affected AI app, upgrade first, then test the real tenant boundary. A package update closes the known code paths; it does not prove that old logs, exports, caches, vector indexes, backups, or custom retrieval code never exposed or copied another user's data.

Research cutoff: October 12, 2026.

The Answer in One Minute

The fresh disclosures cover two related ways that an AI application's memory boundary can fail.

First, LangChain's MongoDBChatMessageHistory advisory says the component documented sessionId as a string but did not enforce that type at runtime. TypeScript types disappear when code runs. If an application forwarded a user-controlled object instead of a server-validated string, MongoDB could interpret that object as a query condition. In a shared collection, a crafted condition could match another session and let an attacker read, append to, or delete that conversation.

The affected package is @langchain/mongodb through 1.3.0. Version 1.3.1 rejects non-string and empty session identifiers and wraps filters in MongoDB's literal $eq operator. Applications that already derive session identifiers from authenticated, server-controlled values and enforce the string type are not affected by this path.

Second, LangGraph's Postgres and Redis store advisory says namespace matching did not reliably isolate long-term-memory documents. Postgres searches could return sibling namespaces with the same leading characters. Redis matching ignored case, punctuation, and word order, which could let one namespace read, replace, or delete documents belonging to another. The fixed releases are @langchain/langgraph-checkpoint-postgres 1.0.6 and @langchain/langgraph-checkpoint-redis 1.0.12.

The practical lesson is larger than these packages: an AI “session,” “thread,” “namespace,” or “memory” label is not automatically an authorization boundary. Authentication must determine who the caller is, authorization must determine which records that identity may reach, and the database query must enforce the same decision every time.

What Is Confirmed

A query-shaped session identifier could reach another stored conversation

The maintainer advisory assigns the chat-history issue CVE-2026-106119 and GHSA-m6rx-h84q-8r95. GitHub scores it 6.0 under CVSS 4.0, with high confidentiality impact, low integrity impact, and no direct availability impact.

The vulnerable component placed sessionId into MongoDB filters without first verifying that the runtime value was a non-empty string. A developer could believe a TypeScript declaration protected the boundary, while an incoming JSON request still delivered an object such as a MongoDB operator.

LangChain's patch commit gives a concrete example: a value shaped like { $regex: "^victim-" } could be treated as a query rather than as a literal session name. The commit says the earlier behavior could allow a caller to read, append to, or delete another session's chat history.

That is not a model hallucination, prompt injection, or training-data leak. It is a conventional query-injection and authorization problem in the application memory layer. The AI-specific consequence is that the affected records may contain private prompts, assistant answers, tool results, summaries, or other conversation context.

The fixed MongoDB release adds two defenses

The 1.3.1 release changes the behavior in two ways:

  1. The constructor throws a TypeError unless sessionId is a non-empty string.
  2. Message reads, writes, and deletion compare the identifier with $eq, which tells MongoDB to treat the value literally.

LangChain added tests for both layers. One test rejects objects, arrays, numbers, null values, undefined values, and empty strings. A second test bypasses the constructor check deliberately and confirms that the literal query still does not read, change, or delete a planted victim message.

That defense in depth matters. Validation at the application edge can be missed or refactored later; a literal comparison at the database boundary prevents the same input from becoming query logic.

Postgres namespace prefix matching could return sibling memory

LangGraph's advisory describes a separate long-term-memory issue in PostgresStore. A search scoped to a namespace such as ['tenant', 'a'] could return records from a sibling namespace such as ['tenant', 'ab'] because their labels shared leading characters.

The advisory says direct item retrieval, writes, and deletes were not affected on the Postgres path. Search results and namespace listings were. That distinction matters: the flaw could expose memory documents through search without giving the same caller every direct storage operation.

The Postgres issue affects versions from 0.1.1 through 1.0.5 and is fixed in 1.0.6. The patched store matches namespace segments rather than loose prefixes and discards results that do not belong to the requested namespace.

Redis namespace matching could read, replace, or delete other memory documents

The Redis path was broader. The advisory says the store matched words in namespace labels while ignoring case, order, and punctuation, and it did not escape those labels. Under affected configurations, an operation for one namespace could act on another namespace's documents—especially when users could influence namespace labels.

The Redis issue affects versions before 1.0.12. The advisory tells operators to upgrade every process that writes to the store because one older process can still replace or delete documents outside the intended namespace even after other application instances are patched.

LangGraph assigns the combined store advisory a CVSS 3.1 score of 7.1, or high severity. The described impact includes high confidentiality and integrity effects and low availability effects.

The affected records can be AI long-term memory

LangGraph's own persistence documentation separates short-term thread state from long-term stores. Checkpointers maintain a conversation or workflow's state; stores hold cross-thread information such as user preferences, facts, and shared knowledge.

That makes namespace isolation more than a database hygiene issue. A long-term-memory record may contain distilled personal context that an agent can recall in future conversations. If another tenant can search or modify it, the failure can become both a privacy breach and an integrity problem: the wrong user may see private facts, or an agent may later act on memory another user planted.

Public sources do not establish real-world exploitation

The reviewed maintainer advisories, patch commits, release notes, NVD record, and GitLab advisory mirror describe vulnerable conditions and demonstrated test cases. They do not name a compromised customer, confirm exploitation in production, count affected deployments, or say LangChain's own hosted services were breached.

The accurate claim is therefore: affected applications could cross user boundaries under the stated conditions. It is not accurate to say that LangChain exposed every user's chats or that the flaw proves anyone's conversation was stolen.

What Is Still Unclear

How many deployed applications meet the vulnerable conditions?

Package download counts do not answer that question. An application is exposed to the MongoDB path only if it combines the affected package with untrusted structured session input and a shared multi-user collection. A deployment using a server-generated authenticated string is not affected by that path even before the package upgrade.

The LangGraph store risk likewise depends on whether an application uses the affected Postgres or Redis package, treats namespaces as an access boundary, stores more than one user's data in the same backend, and exposes searches or writes that can reach the faulty matching behavior.

No reviewed source provides a reliable affected-deployment count.

Whether any production user data was accessed

The advisories establish capability under controlled conditions, not historical exploitation. Operators need their own logs and traces to answer whether a suspicious value reached sessionId, whether searches returned results from an unauthorized namespace, or whether Redis writes changed records outside the caller's tenant.

Absence of a public incident report is not proof that nobody was affected. It is also not evidence that exploitation occurred. The right response is scoped investigation, not speculation.

Whether custom wrappers created equivalent flaws

The published versions fix the named package code. Many teams wrap LangChain components with their own API routes, session mapping, caching, retrieval, and deletion logic. Those custom layers can reintroduce the same class of mistake by trusting a caller-supplied tenant key or by applying an authorization filter after retrieval rather than inside the query.

An upgrade should therefore be followed by tests at the application's real public boundary. A unit test for a library is not a substitute for a multi-tenant integration test using the same authentication, API gateway, database, cache, and worker processes as production.

What happened to derived or copied data before the fix?

If an unauthorized record was ever returned, it may have been copied into model prompts, traces, observability systems, summaries, embeddings, caches, exports, support tickets, or backups. The package update does not automatically find or remove those derivatives.

That does not mean such copies exist. It means an investigation should follow data lineage rather than stopping at the source table. A memory record can leave the original store when an agent retrieves it and sends it to a model or tool.

Who Is Actually Affected?

Check the MongoDB chat-history package

You need urgent review if all of these are true:

Upgrade to 1.3.1 or later. If an immediate upgrade is impossible, the maintainer says to reject anything that is not a non-empty string and derive the identifier from an authenticated, server-controlled value. Upgrading remains the recommended fix.

Check the LangGraph Postgres store

Review applications using @langchain/langgraph-checkpoint-postgres versions 0.1.1 through 1.0.5 when namespace searches or listings are used to separate tenants or users. Upgrade to 1.0.6 or later.

Test sibling namespaces with shared prefixes, not only completely different names. For example, create planted sentinel records for tenant/a, tenant/ab, and tenant/a-b, then prove that each authorized caller can retrieve only its own marker.

Check the LangGraph Redis store

Review every process using @langchain/langgraph-checkpoint-redis before 1.0.12. Upgrade readers, writers, background workers, scheduled jobs, and old containers together.

Testing should vary case, punctuation, and word order. The known issue was not simply one bad key; it was the meaning assigned to namespace labels. A partially upgraded fleet can remain unsafe if an old writer still applies the vulnerable matching behavior.

You are not automatically affected because your app uses LangChain

The advisories name specific JavaScript packages and versions. They do not say that every Python application, every LangChain component, every database integration, or every hosted LangChain product shares the same flaw.

Inventory exact package names and resolved versions. Do not infer exposure from the LangChain brand alone, and do not infer safety merely because a top-level framework package appears current while a transitive store package remains old.

What Developers Should Do Now

1. Patch the exact packages

Pin and deploy at least these fixed versions where applicable:

Confirm the resolved production lockfile and running artifact, not only package.json. Containers, serverless bundles, background workers, and long-lived processes can preserve an older dependency after the source manifest changes.

2. Move identity derivation to the server

A request should not be able to choose its own effective tenant by submitting sessionId, userId, or namespace as an authoritative value. The server should derive the storage scope from the authenticated principal and a server-owned mapping.

If a client needs a public conversation identifier, treat it as an object to authorize—not as proof of ownership. Before every read, write, search, export, or delete, bind the record to the authenticated user or tenant inside the database query.

3. Enforce the boundary in the query

Validation is necessary, but authorization should also live in the storage operation. A safe query should require both the requested object and the authorized tenant. Filtering unauthorized results after a broad search is weaker because the data has already crossed into application memory, logging, or tracing code.

For vector and semantic search, include the tenant constraint in the retrieval plan and verify it on every returned item. Similarity should rank only records the caller is already allowed to see.

4. Add adversarial isolation tests

Plant unique synthetic markers in several test tenants and attempt to cross the boundary through:

A good test fails closed. It should return an authorization error or an empty authorized result without logging the victim marker.

5. Review evidence without exposing more sensitive data

Look for unusual session-identifier shapes, MongoDB operators, cross-tenant result counts, namespace collisions, and writes whose tenant does not match the authenticated principal. Preserve authorized evidence, limit access, and avoid copying whole conversations into an investigation ticket when a hashed marker or record identifier is enough.

If evidence suggests actual access, follow the organization's incident-response and notification obligations. This article is technical information, not legal advice.

6. Trace derived copies

Map where retrieved memory can go: model-provider requests, prompt and tool traces, observability platforms, caches and queues, vector indexes and summaries, analytics or support systems, exports, and backups.

Document each system's owner, retention rule, deletion capability, and evidence status. Do not claim complete remediation until the known copies have been addressed or deliberately retained under an authorized policy.

What This Does Not Prove

It does not prove every AI memory system is unsafe

The advisories show specific implementation failures. They do not invalidate every database, vector store, memory framework, or hosted AI service. Strong tenant isolation is possible when identity, authorization, query constraints, testing, monitoring, and deletion are designed together.

It does not prove model providers trained on exposed records

Cross-session retrieval and foundation-model training are different questions. A vulnerable app could expose a record without using it for training. Conversely, a product's training policy does not repair a broken tenant boundary. Ask about both separately.

It does not prove encryption would have prevented the issue

Encryption at rest protects stored bytes from some infrastructure threats. An authorized application process still needs to decrypt data to serve it. If that process runs an overbroad query, encryption may not stop it from returning the wrong user's plaintext.

It does not make browser-local history risk-free

Keeping normal chat history in a browser reduces the size and duration of a server-side conversation archive, but browser-local records still depend on device security, browser profiles, extensions, backups, synchronization behavior, and the active request path. Local history is a different boundary, not a universal security guarantee.

Where OpenVeil Fits—and Where It Does Not

OpenVeil is an 18+ privacy-focused hosted AI workspace. For normal private chat sessions, OpenVeil documents browser-local AI chat history and no normal server-side chat-history account record. OpenVeil also says documented product content such as prompts and uploads is not used to train foundation models.

That design can reduce one risk illustrated by these advisories: a large server-side collection of normal account chat histories is not OpenVeil's history model. It is a meaningful architectural distinction for adults who want hosted chat without a normal cloud account archive of every conversation.

The boundary must stay precise. OpenVeil is not fully offline or anonymous. Active requests still have to be processed by OpenVeil and necessary AI, search, upload-processing, hosting, routing, security, billing, and infrastructure providers. Account and billing records remain necessary. Files, search, voice, images, and video can have feature-specific processing paths.

OpenVeil is also not a LangChain vulnerability scanner, dependency patch service, database firewall, tenant-isolation audit, breach-remediation product, or protection for data already submitted to another application. Developers using the affected packages should patch and investigate their own systems.

If the product choice itself is still unclear, compare private hosted chat with local AI and read why no chat history does not mean no logs. You can also review the OpenVeil privacy policy before trying the service.

Questions To Ask Any AI App That Stores Memory

  1. Is the session or tenant identifier derived from the authenticated account, or accepted from the client?
  2. Is authorization enforced inside every database and vector-search query?
  3. Are chat history, short-term checkpoints, long-term memory, files, and embeddings stored separately?
  4. Can one tenant influence namespace names or filters?
  5. Are read, search, write, export, and delete operations tested independently?
  6. Does a deletion remove only the source record, or also summaries, embeddings, caches, and traces?
  7. Which processes and services still run older dependency versions during deployment?
  8. What evidence would show that another user's record was returned?
  9. What is the retention and incident-notification policy?
  10. Does “no training” describe the same boundary as “no stored chat history,” or a different one?

Clear answers should name the component, identity source, authorization rule, storage system, retention period, deletion behavior, and verification method. “Enterprise-grade,” “encrypted,” or “private” without those details is not enough.

FAQ

What is CVE-2026-106119?

CVE-2026-106119 is a query-injection flaw in LangChain.js MongoDBChatMessageHistory. In affected applications, a structured untrusted session identifier could be interpreted as MongoDB query logic and reach another user's stored conversation. The fix is @langchain/mongodb 1.3.1 or later.

Was LangChain hacked?

The public advisories describe vulnerable open-source package behavior. They do not establish a breach of LangChain's own systems, exploitation in the wild, or a confirmed customer incident.

Could the flaw read another user's chat history?

Yes, under the documented preconditions. The attacker must be able to influence the structured session identifier, the application must use an affected version and shared multi-user collection, and the attacker must be able to invoke chat-history operations. Applications using authenticated server-controlled strings are not affected by that path.

Could it change or delete messages too?

The maintainer says the MongoDB flaw could read, append to, or delete another session's chat history. The Redis namespace flaw could read, replace, or delete another namespace's documents. The Postgres namespace issue affected search and namespace listing, not direct item writes or deletes according to the advisory.

Does upgrading prove no data was exposed?

No. Upgrading closes the known vulnerable path. Operators still need logs, traces, sentinel tests, and data-lineage review to determine whether the path was reachable or used before the fix.

Is this the same as prompt injection?

No. These disclosures concern query construction and namespace isolation in storage code. Prompt injection manipulates a model through instructions in untrusted content. Both can expose memory, but they are different mechanisms and require different controls.

Does browser-local chat history avoid every memory risk?

No. Browser-local history avoids a normal server-side chat-history account archive, but active requests still require processing, and local records remain subject to device, browser, extension, backup, and synchronization risks.

The Bottom Line

LangChain and LangGraph patched real AI-memory isolation flaws, but the scope is conditional. @langchain/mongodb through 1.3.0 could treat an untrusted structured session identifier as query logic. LangGraph's affected Postgres and Redis stores could cross namespace boundaries when applications relied on those namespaces to isolate long-term memory.

Operators should deploy the fixed versions, derive storage scope from authenticated server-side identity, enforce authorization inside every query, test adversarial tenant boundaries, and investigate any historical evidence without overstating what the advisories prove.

For users choosing an AI product, the durable question is not whether a company calls something a “session” or “private memory.” Ask where the record lives, how identity binds to it, how authorization is enforced, what is retained, what is sent to providers, and how the product proves deletion and isolation.

Sources

When privacy, account control, uploads, and search matter, OpenVeil gives you a private AI workspace designed for that job.