RediSearch Query Injection in LangGraph Redis Checkpoint
| Field | Details |
|---|---|
| CVE ID | CVE-2026-27022 |
| Component | @langchain/langgraph-checkpoint-redis |
| Vulnerability Type | Query Injection (RediSearch DSL Injection) |
| CWE | CWE-74 – Improper Neutralization of Special Elements |
| Affected Versions | All versions < 1.0.2 |
| Fixed Version | 1.0.2 |
| CVSS v3.1 | 6.5 (Medium) |
| CVSS Vector | AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N |
| Attack Complexity | Low |
| Privileges Required | Low (Authenticated / API access required) |
| User Interaction | None |
| Impact | Confidentiality – High |
| Integrity Impact | None |
| Availability Impact | None |
| Exploit Availability | Public technical details and working PoC methodology available |
| Exploitation Method | Injection of RediSearch operators via unescaped filter parameters |
| Primary Risk | Cross-thread / Cross-tenant data exposure |
Overview
A query injection vulnerability was identified in the Redis checkpoint integration used by LangGraph. The issue exists in the way RediSearch query strings were constructed when filter parameters were supplied. User-controlled values were inserted into RediSearch queries without proper escaping of special characters.
RediSearch interprets characters such as:
| { } @ : ( ) * "
as operators or structural delimiters. When those characters were not escaped, it became possible for an attacker to manipulate the logical structure of the query.
As a result, thread-level isolation could be bypassed, allowing retrieval of checkpoint data belonging to other users or sessions.
No integrity or availability impact has been observed. The primary risk is unauthorized data exposure.
Technical Root Cause
The vulnerability stems from improper neutralization of special elements when constructing RediSearch tag queries.
The following unsafe pattern was used conceptually:
(@thread_id:{<thread>}) (@source:{<user_input>})
If <user_input> contained crafted syntax such as:
x}) | (@thread_id:{*
The resulting query would become:
(@thread_id:{victim-thread}) (@source:{x}) | (@thread_id:{*})
Because of RediSearch operator precedence, the OR clause would match any thread, effectively removing the intended restriction.
The issue aligns with:
- CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component
The flaw was corrected in version 1.0.2 by properly escaping tag values before constructing search queries.
Attack Scenario
The vulnerability can be exploited when:
- An API endpoint accepts filter parameters from users.
- Those parameters are passed directly to
RedisSaver.list()orShallowRedisSaver.list(). - No server-side validation or escaping is performed.
Example Exploitation Flow
- Attacker authenticates normally.
- Attacker supplies malicious filter input.
- Backend constructs unescaped RediSearch query.
- Search executes with injected logic.
- Data from other threads is returned.
Proof of Concept (Educational)
Malicious Filter Payload
x}) | (@thread_id:{*
Example Code Demonstration
import { RedisSaver } from "@langchain/langgraph-checkpoint-redis";const saver = new RedisSaver({ /* redis config */ });const data = await saver.list(
{ configurable: { thread_id: "user-thread-123" } },
{ filter: { source: "x}) | (@thread_id:{*" } }
);console.log(data);
If vulnerable, results may contain checkpoints from unrelated threads.
Impact Analysis
Confidentiality
- Cross-tenant data exposure
- Conversation history leakage
- Potential exposure of API keys, prompts, or proprietary data stored in checkpoints
Integrity
- No direct data modification observed
Availability
- No service disruption expected
Business Risk
- Data privacy violations
- Regulatory exposure (GDPR, HIPAA depending on stored content)
- Reputational damage
Indicators of Exploitation
The following may indicate active exploitation:
- Unexpected large result sets from history endpoints
- Filter parameters containing special characters
- Access to thread IDs not owned by requesting user
- Increase in Redis FT.SEARCH commands with unusual syntax
Detection Guidance
Log Sources to Monitor
- Application API access logs
- Reverse proxy / WAF logs
- Redis command logs
- RediSearch FT.SEARCH execution logs
- Backend service debug logs
Detection Queries
Splunk Query
index=app_logs sourcetype=api_access "/history"
| eval filter_param=params.filter
| where like(filter_param,"%|%")
OR like(filter_param,"%@thread_id:{*%")
OR match(filter_param,"\}\s*\)\s*\|")
| stats count by src_ip user filter_param
Splunk – Detect Cross Thread Access
index=app_logs sourcetype=api_response "/history"
| where requested_thread != returned_thread
| stats count by user requested_thread returned_thread
Elastic (KQL)
http.request.uri.query: *filter* AND
(
http.request.uri.query: *|* OR
http.request.uri.query: *@thread_id:{* OR
http.request.uri.query: *} ) |*
)
Elastic – Large Result Set Detection
event.dataset:api AND response.size > 100 AND
http.request.uri.path:/history
Threshold should be adjusted to match baseline behavior.
Generic Regex for SIEM
\}\s*\)\s*\|\s*\(@thread_id:\{\*
Forensic Artifacts
During investigation, the following should be reviewed:
- Full HTTP request parameters
- Correlation between authenticated user and thread IDs returned
- Redis FT.SEARCH query patterns
- Audit trail of accessed checkpoint keys
- Redis key access timestamps
Mitigation and Remediation
Immediate Actions
- Upgrade to version 1.0.2 immediately.
- Temporarily block filter parameters containing RediSearch operators.
- Restrict filterable fields to an allowlist.
Long-Term Controls
- Escape all RediSearch tag values before query construction.
- Validate filter keys strictly.
- Implement tenant isolation at key namespace level.
- Enforce ownership validation before returning search results.
- Deploy anomaly detection on data access patterns.
Secure Coding Recommendations
- Never concatenate user input into query strings.
- Apply strict input validation.
- Use parameterized query mechanisms where available.
- Treat search DSL syntax as executable input.
- Apply least-privilege access to Redis databases.
Validation After Patch
After upgrading:
- Attempt injection payload again.
- Confirm payload is treated as literal string.
- Verify results remain restricted to requested thread.
- Review logs for escaped query construction.
Exploit Maturity Assessment
- Publicly documented
- Simple to execute
- Requires authenticated or API-level access
- No specialized tooling required
Conclusion
CVE-2026-27022 represents a classical injection flaw within a search query context. Although rated as Medium, the confidentiality impact is significant in multi-tenant deployments.
Systems relying on LangGraph Redis checkpoint storage should be updated immediately. Environments that expose filterable search endpoints are at elevated risk.
Official Upgrade Link
Upgrade to secure version:
