Context

A SQL injection vulnerability exists in LangGraph's SQLite checkpoint implementation that allows attackers to manipulate SQL queries through metadata filter keys. This affects applications that accept untrusted metadata filter keys (not just filter values) in checkpoint search operations.

Impact

Attackers who control metadata filter keys can execute arbitrary sql queries against the database.

Root Cause

The metadatapredicate() function constructs SQL queries by interpolating filter keys directly into f-strings without validation:

python VULNERABLE CODE (before fix) for querykey, queryvalue in metadatafilter.items(): operator, paramvalue = wherevalue(queryvalue) predicates.append( f"jsonextract(CAST(metadata AS TEXT), '$.{querykey}') {operator}" ) paramvalues.append(paramvalue)

While filter values are parameterized, filter keys are not validated, allowing SQL injection.

Attack Example

Before Fix: python from langgraph.checkpoint.sqlite import SqliteSaver

saver = SqliteSaver.fromconnstring("checkpoints.db")

Attacker controls the filter keys maliciousfilter = {"x') OR '1'='1": "dummy"}

Returns ALL checkpoints, bypassing filtering results = list(saver.list(None, filter=maliciousfilter))

Resulting SQL: sql WHERE jsonextract(CAST(metadata AS TEXT), '$.x') OR '1'='1') = ? -- Injected condition makes WHERE clause always true

Who Is Affected?

LangSmith Deployment Customers: NOT Impacted

LangSmith deployment customers are NOT affected by this vulnerability. LangSmith deployments do not allow configuring custom checkpointers, so the vulnerable code path cannot be reached.

High Risk: Custom Server Deployments

You are affected if your application: - Runs a custom server with SqliteSaver checkpointer - Exposes an endpoint for fetching checkpoint history (e.g., via getstatehistory()) - Accepts metadata filter keys from untrusted sources

Example vulnerable code: python Custom server endpoint - User controls filter key names - DANGEROUS @app.post("/api/history") def gethistory(request): filterfield = request.json.get("filterfield") # Untrusted input filtervalue = request.json.get("filtervalue")

# VULNERABLE: Attacker can bypass access controls history = list(graph.getstatehistory( config, filter={filterfield: filtervalue} )) return history

Note on privilege escalation: If an endpoint allows end users to specify arbitrary filter keys, those users likely already have legitimate access to query the checkpoint database. In such cases, this vulnerability may not constitute a privilege escalation, as users who can control filter keys would typically already be expected to have database access. However, the SQL injection still allows bypassing intended filtering logic and metadata-based access controls that the application may rely on for data isolation.

Additional Security Hardening (Defense in Depth)

This release also includes hardening improvements:

1. Checkpoint Limit Parameter: used f-string interpolation into parameterized query. Not considered a vulnerability as it requires users to accept untrusted input and not validate it against the actual API signature.

2. Store Filter Value Parameterization: Refactored all filter value handling from manual quote escaping to parameterized queries

Remediation

Immediate Actions

1. Update to the patched version of langgraph-checkpoint-sqlite 2. Audit your code for locations where filter keys come from untrusted sources