Miggo Logo
Miggo Vulnerability Database
→
CVE-2025-8709

CVE-2025-8709: LangGraph's SQLite store implementation has a SQL Injection Vulnerability

7.3

CVSS Score
3.0

Basic Information

CVE ID
CVE-2025-8709
GHSA ID
GHSA-4h97-wpxp-3757
EPSS Score
0.0377%
CWE
CWE-89
Published
10/26/2025
Updated
10/27/2025
KEV Status
No
Technology
TechnologyPython

Technical Details

CVSS Vector
CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N
Package NameEcosystemVulnerable VersionsFirst Patched Version
langgraph-checkpoint-sqlitepip<= 2.0.102.0.11

Vulnerability Intelligence
Miggo AIMiggo AI

Miggo AIRoot Cause Analysis

The analysis of the security patch for CVE-2025-8709 reveals a SQL injection vulnerability in the langgraph-checkpoint-sqlite package. The root cause is the improper handling of keys within the filter parameter of the SqliteStore.search method. These keys were used directly in SQL query construction without sanitization.

The patch introduces a new function, _validate_filter_key, which uses a regular expression to allow only safe characters in filter keys. This validation function is then called at the beginning of _get_filter_condition and within the loop of _prepare_batch_search_queries.

The vulnerable functions are identified as:

  1. SqliteStore.search: The public API method that takes the malicious filter object as input.
  2. SqliteStore._prepare_batch_search_queries: This method iterates over the user-provided filter and was modified to validate each key.
  3. SqliteStore._get_filter_condition: This method constructs the SQL WHERE clause and was also modified to validate the key before using it.

An attacker could exploit this by crafting a filter with a malicious key, such as "access') = 'public' OR '1'='1'", to bypass security filters and access or exfiltrate data from the SQLite database.

Vulnerable functions

SqliteStore._get_filter_condition
libs/checkpoint-sqlite/langgraph/store/sqlite/base.py
This function is responsible for creating SQL filter conditions. Before the patch, it used the 'key' argument directly in the construction of the SQL query without any validation or sanitization. This allowed an attacker to inject malicious SQL by providing a specially crafted key in the filter, leading to a SQL injection vulnerability.
SqliteStore._prepare_batch_search_queries
libs/checkpoint-sqlite/langgraph/store/sqlite/base.py
This function iterates through the user-supplied filter criteria to prepare search queries. It extracts the 'key' from the filter and, prior to the patch, passed it to other methods without validation. The addition of `_validate_filter_key(key)` in the patch indicates that this function was a source of the vulnerability by processing unsanitized user input.
SqliteStore.search
libs/checkpoint-sqlite/langgraph/store/sqlite/base.py
This is the public-facing method that serves as the entry point for the vulnerability. It accepts a 'filter' argument from the user, which can contain malicious keys. Although the SQL injection doesn't happen directly in this function, it receives the tainted input and passes it down to internal methods like `_prepare_batch_search_queries` and `_get_filter_condition`, which then construct the malicious SQL query. The exploit is triggered by calling this function.

WAF Protection Rules

WAF Rule

* SQL inj**tion vuln*r**ility *xists in t** l*n****in-*i/l*n**r*p* r*pository, sp**i*i**lly in t** L*n**r*p*'s SQLit* stor* impl*m*nt*tion. T** *****t** v*rsion is l*n**r*p*-****kpoint-sqlit* *.*.**. T** vuln*r**ility *ris*s *rom improp*r **n*lin* o*

Reasoning

T** *n*lysis o* t** s**urity p*t** *or *V*-****-**** r*v**ls * SQL inj**tion vuln*r**ility in t** `l*n**r*p*-****kpoint-sqlit*` p**k***. T** root **us* is t** improp*r **n*lin* o* k*ys wit*in t** `*ilt*r` p*r*m*t*r o* t** `Sqlit*Stor*.s**r**` m*t*o*.