LangChain Redis package patched over search filter injection

LangChain has fixed a filter injection flaw in its @langchain/redis npm package that could let an attacker widen the scope of a vector search and read documents they were not meant to see. The issue was published as GitHub advisory GHSA-5x6v-p487-7qh2, tracked as CVE-2026-105799, on 6 October 2026. All versions of the package up to and including 1.1.0 are affected.

According to the advisory, the package did not properly escape values used to build structured RediSearch TAG and TEXT filters. RediSearch is the query engine used to search data stored in Redis, and these filters are how an application narrows results to a particular tag or text field. Because the values were passed through without escaping, an application that fed attacker-controlled input into one of those filters could allow the attacker to inject RediSearch syntax and change the query that was actually run.

The practical impact depends on how the filter is used. The advisory says an attacker who controls the filter values can "alter or broaden the resulting search query". Where an application relies on such a filter as a tenant boundary or a document-access control, that broadening may expose indexed documents outside the attacker's intended scope. In other words, a filter intended to limit results to one customer's documents could be rewritten to return more.

This pattern matters for retrieval systems that sit behind AI agents and chatbots. Retrieval-augmented generation setups commonly store embedded documents in a vector database and apply a metadata filter at query time to keep one user's data separate from another's. If the user's own text, or text drawn from a document the agent has read, reaches the filter unescaped, the separation can be bypassed by syntax rather than by any flaw in the model.

The fix is to upgrade to @langchain/redis 1.1.1 or later. LangChain said the patch escapes RediSearch special characters, validates field names and the types of structured filters, and applies the same protections across both the fluent filter builders and query construction based on custom schemas. That last point is worth noting for teams that have written their own schema handling, since the advisory indicates the gap existed in more than one code path.

The advisory does not say whether the issue was exploited in the wild, and no affected applications are named. It credits two external reporters, identified only by their GitHub handles.

Operators running the package should check which version is pinned in their dependency files, including transitive installs, and upgrade. Where filter values originate from user input, request parameters or document content, teams may also want to review logs for queries containing unusual RediSearch syntax, although the advisory offers no detection guidance of its own. There is no published workaround other than upgrading.