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 _metadata_predicate() function constructs SQL queries by interpolating filter keys directly into f-strings without validation:

# VULNERABLE CODE (before fix)
for query_key, query_value in metadata_filter.items():
    operator, param_value = _where_value(query_value)
    predicates.append(
        f"json_extract(CAST(metadata AS TEXT), '$.{query_key}') {operator}"
    )
    param_values.append(param_value)

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

Attack Example

Before Fix:

from langgraph.checkpoint.sqlite import SqliteSaver

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

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

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

Resulting SQL:

WHERE json_extract(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 get_state_history())
• Accepts metadata filter keys from untrusted sources...