CVE-2026-27022

@langchain/langgraph-checkpoint-redis is the Redis checkpoint and store implementation for LangGraph. A query injection vulnerability exists in the @langchain/langgraph-checkpoint-redis package's filter handling. The RedisSaver and ShallowRedisSaver classes construct RediSearch queries by directly interpolating user-provided filter keys and values without proper escaping. RediSearch has special syntax characters that can modify query behavior, and when user-controlled data contains these characters, the query logic can be manipulated to bypass intended access controls. This vulnerability is fixed in 1.0.2.

@langchain/langgraph-checkpoint-redis is the Redis checkpoint and store implementation for LangGraph. A query injection vulnerability exists in the @langchain/langgraph-checkpoint-redis package's filter handling. The RedisSaver and ShallowRedisSaver classes construct RediSearch queries by directly interpolating user-provided filter keys and values without proper escaping. RediSearch has special syntax characters that can modify query behavior, and when user-controlled data contains these characters, the query logic can be manipulated to bypass intended access controls. This vulnerability is fixed in 1.0.2.

Summary

A query injection vulnerability exists in the @langchain/langgraph-checkpoint-redis package's filter handling. The RedisSaver and ShallowRedisSaver classes construct RediSearch queries by directly interpolating user-provided filter keys and values without proper escaping. RediSearch has special syntax characters that can modify query behavior, and when user-controlled data contains these characters, the query logic can be manipulated to bypass intended access controls.

Attack surface

The core vulnerability was in the list() methods of both RedisSaver and ShallowRedisSaver: these methods failed to escape RediSearch special characters in filter keys and values when constructing queries. When unescaped data containing RediSearch syntax was used, the injected operators were interpreted by RediSearch rather than treated as literal search values.

This escaping bug enabled the following attack vector:

• Thread boundary escape via OR operator: RediSearch uses | as an OR operator with specific precedence rules. A query like A B | C is interpreted as (A AND B) OR C. By injecting }) | (@thread_id:{* into a filter value, an attacker can append an OR clause that matches all threads, effectively bypassing the thread isolation constraint.

The injected query (@thread_id:{legitimate-thread}) (@source:{x}) | (@thread_id:{*}) matches:

• Documents with thread_id:legitimate-thread AND source:x, OR
• Documents with ANY thread_id

The second clause matches all threads, bypassing thread isolation entirely.

Who is affected?

Applications are vulnerable if they:

• Pass user-controlled input to filter parameters — When using getStateHistory() or checkpointer.list() with filter values derived from user input, HTTP parameters, or other untrusted sources.
• Use Redis checkpointing in multi-tenant applications — Applications that rely on thread isolation to separate data between users or tenants are at risk of cross-tenant data access.

The most common attack vector is through API endpoints that expose filtering capabilities to end users, allowing them to search or filter their conversation history.

Impact

Attackers who control filter input can bypass thread isolation by injecting RediSearch OR operators to construct queries that match all threads regardless of the intended thread constraint. This enables access to checkpoint data from threads the attacker is not authorized to view.

Key severity factors:

• Enables complete bypass of thread-based access controls
• Sensitive conversation data from other users may be exposed
• Affects multi-tenant applications relying on thread isolation for data separation
• Requires only control over filter input values (common in user-facing APIs)

Exploit example

import { RedisSaver } from "@langchain/langgraph-checkpoint-redis";

const saver = new RedisSaver({ /* redis config */ });

// Normal usage - should only see thread "user-123-thread"
const legitHistory = saver.list({
  configurable: { thread_id: "user-123-thread" }
}, {
  filter: { source: "loop" }
});

// Attacker crafts malicious filter value
const attackerFilter = {
  source: "x}) | (@thread_id:{*"  // Injects OR clause matching ALL threads
};

// This produces a query like:
// (@thread_id:{user-123-thread}) (@source:{x}) | (@thread_id:{*})
// Due to precedence, this matches ALL threads!

const stolenHistory = saver.list({
  configurable: { thread_id: "user-123-thread" }
}, {
  filter: attackerFilter
});

// stolenHistory now contains checkpoints from ALL threads - DATA LEAKED!

Security hardening changes

The 1.0.2 patch introduces the following changes:

• Escape utility function: A new escapeRediSearchTagValue() function properly escapes all RediSearch special characters (- . < > { } [ ] " ' : ; ! @ # $ % ^ & * ( ) + = ~ | \ ? /) by prefixing them with backslashes.
• Filter key escaping: All filter keys are escaped before being used in query…

@langchain/langgraph-checkpoint-redis is the Redis checkpoint and store implementation for LangGraph. A query injection vulnerability exists in the @langchain/langgraph-checkpoint-redis package's filter handling. The RedisSaver and ShallowRedisSaver classes construct RediSearch queries by directly interpolating user-provided filter keys and values without proper escaping. RediSearch has special syntax characters that can modify query behavior, and when user-controlled data contains these characters, the query logic can be manipulated to bypass intended access controls. This vulnerability is fixed in 1.0.2.

@langchain/langgraph-checkpoint-redis is the Redis checkpoint and store implementation for LangGraph. A query injection vulnerability exists in the @langchain/langgraph-checkpoint-redis package's filter handling. The RedisSaver and ShallowRedisSaver classes construct RediSearch queries by directly interpolating user-provided filter keys and values without proper escaping. RediSearch has special syntax characters that can modify query behavior, and when user-controlled data contains these characters, the query logic can be manipulated to bypass intended access controls. This vulnerability is fixed in 1.0.2.

Summary

A query injection vulnerability exists in the @langchain/langgraph-checkpoint-redis package's filter handling. The RedisSaver and ShallowRedisSaver classes construct RediSearch queries by directly interpolating user-provided filter keys and values without proper escaping. RediSearch has special syntax characters that can modify query behavior, and when user-controlled data contains these characters, the query logic can be manipulated to bypass intended access controls.

Attack surface

The core vulnerability was in the list() methods of both RedisSaver and ShallowRedisSaver: these methods failed to escape RediSearch special characters in filter keys and values when constructing queries. When unescaped data containing RediSearch syntax was used, the injected operators were interpreted by RediSearch rather than treated as literal search values.

This escaping bug enabled the following attack vector:

• Thread boundary escape via OR operator: RediSearch uses | as an OR operator with specific precedence rules. A query like A B | C is interpreted as (A AND B) OR C. By injecting }) | (@thread_id:{* into a filter value, an attacker can append an OR clause that matches all threads, effectively bypassing the thread isolation constraint.

The injected query (@thread_id:{legitimate-thread}) (@source:{x}) | (@thread_id:{*}) matches:

• Documents with thread_id:legitimate-thread AND source:x, OR
• Documents with ANY thread_id

The second clause matches all threads, bypassing thread isolation entirely.

Who is affected?

Applications are vulnerable if they:

• Pass user-controlled input to filter parameters — When using getStateHistory() or checkpointer.list() with filter values derived from user input, HTTP parameters, or other untrusted sources.
• Use Redis checkpointing in multi-tenant applications — Applications that rely on thread isolation to separate data between users or tenants are at risk of cross-tenant data access.

The most common attack vector is through API endpoints that expose filtering capabilities to end users, allowing them to search or filter their conversation history.

Impact

Attackers who control filter input can bypass thread isolation by injecting RediSearch OR operators to construct queries that match all threads regardless of the intended thread constraint. This enables access to checkpoint data from threads the attacker is not authorized to view.

Key severity factors:

• Enables complete bypass of thread-based access controls
• Sensitive conversation data from other users may be exposed
• Affects multi-tenant applications relying on thread isolation for data separation
• Requires only control over filter input values (common in user-facing APIs)

Exploit example

import { RedisSaver } from "@langchain/langgraph-checkpoint-redis";

const saver = new RedisSaver({ /* redis config */ });

// Normal usage - should only see thread "user-123-thread"
const legitHistory = saver.list({
  configurable: { thread_id: "user-123-thread" }
}, {
  filter: { source: "loop" }
});

// Attacker crafts malicious filter value
const attackerFilter = {
  source: "x}) | (@thread_id:{*"  // Injects OR clause matching ALL threads
};

// This produces a query like:
// (@thread_id:{user-123-thread}) (@source:{x}) | (@thread_id:{*})
// Due to precedence, this matches ALL threads!

const stolenHistory = saver.list({
  configurable: { thread_id: "user-123-thread" }
}, {
  filter: attackerFilter
});

// stolenHistory now contains checkpoints from ALL threads - DATA LEAKED!

Security hardening changes

The 1.0.2 patch introduces the following changes:

• Escape utility function: A new escapeRediSearchTagValue() function properly escapes all RediSearch special characters (- . < > { } [ ] " ' : ; ! @ # $ % ^ & * ( ) + = ~ | \ ? /) by prefixing them with backslashes.
• Filter key escaping: All filter keys are escaped before being used in query…