CVE-2026-105799

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.

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.

Summary

@langchain/redis did not properly escape values used to construct structured RediSearch TAG and TEXT filters. An application that passes attacker-controlled values into these filters could allow the attacker to alter the resulting search query.

Affected versions

@langchain/redis versions through 1.1.0 are affected.

Impact

An attacker who can control values passed to the affected structured TAG or TEXT filters can inject RediSearch syntax and alter or broaden the resulting search query. In applications that use an attacker-influenceable filter as a tenant or document-access boundary, this may expose indexed documents outside the attacker's intended scope.

Remediation

Upgrade to @langchain/redis 1.1.1 or later.

The fix escapes RediSearch special characters, validates field names and structured filter types, and applies these protections across fluent filter builders and custom-schema query construction.

Credits

Thanks to @thesanjok and @shovanchakraborty for reporting this issue.

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.

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.

Summary

@langchain/redis did not properly escape values used to construct structured RediSearch TAG and TEXT filters. An application that passes attacker-controlled values into these filters could allow the attacker to alter the resulting search query.

Affected versions

@langchain/redis versions through 1.1.0 are affected.

Impact

An attacker who can control values passed to the affected structured TAG or TEXT filters can inject RediSearch syntax and alter or broaden the resulting search query. In applications that use an attacker-influenceable filter as a tenant or document-access boundary, this may expose indexed documents outside the attacker's intended scope.

Remediation

Upgrade to @langchain/redis 1.1.1 or later.

The fix escapes RediSearch special characters, validates field names and structured filter types, and applies these protections across fluent filter builders and custom-schema query construction.

Credits

Thanks to @thesanjok and @shovanchakraborty for reporting this issue.