CVE-2025-67644: 
Python vulnerability analysis and mitigation

CVE-2025-67644 is a SQL injection vulnerability in the LangGraph SQLite Checkpoint library (langgraph-checkpoint-sqlite), a Python package that implements LangGraph's CheckpointSaver using SQLite (both sync and async via aiosqlite). All versions up to and including 3.0.0 are affected; the issue was disclosed on December 10–11, 2025, and fixed in version 3.0.1. It carries a CVSS v3.1 base score of 7.3–7.8 (High), depending on the scoring authority (GitHub Advisory, Red Hat).

The root cause is CWE-89 (Improper Neutralization of Special Elements used in an SQL Command). The vulnerable _metadata_predicate() function in libs/checkpoint-sqlite/langgraph/checkpoint/sqlite/utils.py constructs SQL queries by interpolating metadata filter keys directly into f-strings without any validation, while filter values are correctly parameterized. An attacker who can supply arbitrary metadata filter key names to checkpoint search operations (e.g., via saver.list() or graph.get_state_history()) can inject SQL syntax into the resulting query. For example, passing {"x') OR '1'='1": "dummy"} as the filter causes the WHERE clause to always evaluate as true, bypassing intended filtering logic. The fix in version 3.0.1 introduces a _validate_filter_key() function that enforces a strict allowlist regex (^[a-zA-Z0-9_.-]+$) before any key is interpolated into a query (GitHub Advisory, Patch Commit).

Successful exploitation allows a low-privileged local attacker to execute arbitrary SQL queries against the application's SQLite checkpoint database, resulting in high confidentiality impact (unauthorized access to all stored checkpoint data, which may include agent state, conversation history, and sensitive application secrets), low-to-high integrity impact (potential data modification or deletion), and no direct availability impact. Applications that expose checkpoint history endpoints accepting user-controlled filter key names are at highest risk, as attackers can bypass metadata-based access controls and data isolation boundaries. LangSmith-managed deployments are explicitly not affected, as they do not permit custom checkpointer configuration (GitHub Advisory).

A proof-of-concept exploit is publicly documented in the GitHub Security Advisory, demonstrating how a crafted filter key bypasses checkpoint filtering. There is no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.016% (very low), and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires low privileges and local access to an application that passes untrusted metadata filter keys to checkpoint search operations (GitHub Advisory, Feedly).

1. Identify a vulnerable target: Locate a custom server application using langgraph-checkpoint-sqlite ≤3.0.0 that exposes an endpoint for fetching checkpoint history (e.g., via get_state_history() or a custom /api/history route) and accepts user-supplied metadata filter field names.
2. Craft a malicious filter key: Construct a metadata filter dictionary where the key contains SQL injection syntax, such as {"x') OR '1'='1": "dummy"}. The key breaks out of the json_extract() call and injects an always-true condition.
3. Submit the payload: Send a request to the vulnerable endpoint with the malicious filter key as the filter_field parameter (e.g., via a POST request to /api/history with JSON body {"filter_field": "x') OR '1'='1", "filter_value": "dummy"}).
4. Observe SQL injection effect: The resulting SQL WHERE clause becomes WHERE json_extract(CAST(metadata AS TEXT), '$.x') OR '1'='1') = ?, which always evaluates to true, returning all checkpoints regardless of intended access controls.
5. Escalate: With unrestricted query access, craft additional payloads to exfiltrate specific checkpoint data, enumerate stored agent states, or attempt further SQL manipulation depending on SQLite capabilities and application context (GitHub Advisory).

• Logs: Application logs showing unexpected or anomalous checkpoint list/search requests with filter keys containing special characters such as ', ), OR, =, or other SQL syntax fragments.
• Database: SQLite checkpoint database queries returning unexpectedly large result sets (all checkpoints) when a filtered query should return a subset; audit logs (if enabled) showing unusual json_extract query patterns.
• Application Behavior: Checkpoint history endpoints returning data belonging to other users or sessions, indicating bypassed access controls.
• Network: Unusual volume of checkpoint history API calls from a single source, potentially indicating automated enumeration of checkpoint data (GitHub Advisory).

Upgrade langgraph-checkpoint-sqlite to version 3.0.1 or later, which introduces strict validation of metadata filter keys via an allowlist regex (^[a-zA-Z0-9_.-]+$). As an interim workaround, audit all code paths where metadata filter keys originate from user input and enforce server-side validation to restrict keys to known, trusted values before passing them to checkpoint search operations. Applications that do not expose checkpoint history endpoints to untrusted users are not at risk (GitHub Advisory, Patch Commit).

The vulnerability received notable media coverage in March 2026 as part of a broader cluster of LangChain/LangGraph security issues disclosed around the same time. The Hacker News and TechRadar covered the broader LangGraph vulnerability set, highlighting input validation weaknesses in widely used AI frameworks (The Hacker News, TechRadar). Security researchers at Cyera published a detailed research post titled "LangDrained" examining multiple data-exposure paths through LangChain's AI framework ecosystem, including this vulnerability (Cyera Research). CSO Online and Security Boulevard also covered the broader LangChain input validation issues, noting the systemic risk of AI pipeline frameworks accepting untrusted input without sufficient sanitization.