CVE-2026-105799 in redis
Summary
by MITRE • 10/06/2026
LangChain is a framework for building LLM-powered applications. Prior to 1.1.1, @langchain/redis does not escape attacker-controlled values in structured RediSearch TAG filters and structured RediSearch TEXT filters, allowing injected RediSearch syntax to alter or broaden the generated search query. When an application uses an attacker-influenceable filter as a tenant or document-access boundary, the modified query can expose indexed documents outside the attacker's intended scope. This issue is fixed in version 1.1.1.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified within LangChain versions prior to 1.1.1 represents a critical security flaw rooted in improper input validation and sanitization of user-supplied data when interacting with Redis search functionalities. Specifically, the @langchain/redis integration fails to properly escape attacker-controlled values embedded within structured RediSearch TAG filters and TEXT filters. This lack of escaping allows malicious actors to inject arbitrary RediSearch syntax into query parameters that are intended for filtering or searching indexed documents. The core technical flaw lies in the framework's handling of dynamic filter construction, where special characters used by the Redis search engine to define logical operators, field boundaries, and grouping structures are not neutralized before being passed to the underlying database driver.
This vulnerability directly facilitates an injection attack vector similar to SQL injection but specific to the RediSearch query language. By injecting syntax such as unescaped quotes or logical operators like OR and AND, an attacker can manipulate the structure of the search query generated by LangChain. For instance, if a filter is designed to restrict results to documents belonging to a specific tenant ID, an attacker could inject logic that bypasses this restriction, effectively widening the scope of the returned data set. This capability allows for unauthorized access to information that should remain isolated based on application-level security policies or multi-tenancy architectures.
The operational impact of this vulnerability is severe in environments where Redis serves as a backend for document retrieval with strict access control boundaries. When an application relies on these filters to enforce tenant isolation or user-specific data visibility, the ability to alter query logic results in a direct breach of confidentiality and potentially integrity if combined with other vulnerabilities. Attackers can enumerate sensitive documents belonging to other tenants or users by broadening search criteria beyond their authorized scope. This exposure compromises the fundamental security model of multi-tenant applications built on top of LangChain and Redis, leading to potential data leaks and regulatory non-compliance depending on the nature of the exposed information.
From a classification perspective, this issue aligns with CWE-78 Improper Neutralization of Special Elements used in an OS Command (In this case, a query language command) and CWE-94 Improper Control of Generation of Code ('Code Injection'). In terms of offensive security frameworks, it maps to the MITRE ATT&CK technique T1059.007 Command and Scripting Interpreter: JavaScript, as well as data exfiltration techniques involving structured search queries. The vulnerability exploits the trust placed in framework-level abstractions that fail to enforce strict input sanitization at the boundary between application logic and database query generation.
Mitigation for this vulnerability requires an immediate upgrade of the @langchain/redis package to version 1.1.1 or later, where the issue has been resolved through improved escaping mechanisms. For applications unable to update immediately due to dependency constraints, developers should implement strict input validation on all filter values before they are passed to LangChain functions. This includes whitelisting allowed characters for tenant IDs and document identifiers, ensuring that only alphanumeric strings and specific safe delimiters are accepted. Additionally, implementing least-privilege principles in Redis ACLs can limit the damage if an injection occurs by restricting which commands or index fields a service account is permitted to query. Regular security audits of how dynamic values interact with search engines are essential to prevent similar injection flaws in other parts of the application stack.