CVE-2025-67644

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.

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

Example vulnerable code:

# Custom server endpoint - User controls filter key names - DANGEROUS
@app.post("/api/history")
def get_history(request):
    filter_field = request.json.get("filter_field")  # Untrusted input
    filter_value = request.json.get("filter_value")

    # VULNERABLE: Attacker can bypass access controls
    history = list(graph.get_state_history(
        config,
        filter={filter_field: filter_value}
    ))
    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

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

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

Untrusted input alters a database query, allowing the attacker to read or modify data the query was not intended to access. Typical impact: data disclosure or modification.

CVE-2025-67644 has a CVSS score of 7.3 (High). The vector is requires local access, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (3.0.1); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is CVE-2025-67644? CVE-2025-67644 is a high-severity SQL injection vulnerability in langgraph-checkpoint-sqlite (pip), affecting versions < 3.0.1. It is fixed in 3.0.1. Untrusted input alters a database query, allowing the attacker to read or modify data the query was not intended to access.
2. How severe is CVE-2025-67644? CVE-2025-67644 has a CVSS score of 7.3 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of langgraph-checkpoint-sqlite are affected by CVE-2025-67644? langgraph-checkpoint-sqlite (pip) versions < 3.0.1 is affected.
4. Is there a fix for CVE-2025-67644? Yes. CVE-2025-67644 is fixed in 3.0.1. Upgrade to this version or later.
5. Is CVE-2025-67644 exploitable, and should I be worried? Whether CVE-2025-67644 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2025-67644 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2025-67644? Upgrade langgraph-checkpoint-sqlite to 3.0.1 or later.