LangGraph SQLite Checkpoint CVE-2025-67644

Exploitable only when the host application passes attacker-controlled metadata filter KEYS (not merely values) into SqliteSaver / AsyncSqliteSaver checkpoint search operations (list(), alist(), get_state_history()) on versions <= 3.0.0 - for example a custom server endpoint that copies a request JSON field name into filter={filter_field: filter_value}. The vulnerable _metadata_predicate() interpolates keys into f-strings while values are already parameterized. Strong limiting factors: the key must be untrusted (typical applications hardcode filter keys and are unaffected); LangSmith managed deployments are NOT impacted because they do not permit custom checkpointers; and only the SQLite backend (sync or aiosqlite async) is in scope. Per the NVD vector's PR:L this would be low-privilege authenticated, but the GHSA example implies the exposing endpoint may be unauthenticated - authentication requirements are not confirmed from the vulnerable library alone and depend on the deployment.

Signals are mixed and point to a conditional, low-urgency issue despite the 7.8 'High' rating. The NVD CVSS vector (AV:L/AC:L/PR:L/UI:N/C:H/I:H/A:H) describes low-privilege local exploitation with full CIA impact, but this conflicts with the GHSA/description, which frames the realistic attack path as a network-facing custom server endpoint that forwards untrusted metadata filter keys into SqliteSaver.list()/get_state_history() - i.e. AV:N in practice. This AV:L-vs-network discrepancy should be verified, but either way exploitation is gated by a non-default coding pattern: the application must accept attacker-controlled filter KEYS (not just values), which is uncommon. EPSS is 0.02% (6th percentile), the CVE is NOT in CISA KEV, and there is no confirmed active exploitation; publicly available exploit code exists (a trivial PoC in the GHSA), but PoC availability is distinct from in-the-wild use. The NVD I:H/A:H ratings are also optimistic for defenders - the injection lands inside a single SELECT's WHERE clause (sqlite3 does not permit stacked statements), so the demonstrated impact is filter/access-control bypass and bulk data disclosure (confidentiality) rather than reliable write/destroy. Net: a real but narrow bug - high priority only for teams that expose checkpoint-search endpoints with user-supplied filter keys on vulnerable versions; low priority for everyone else, and explicitly not exploitable in LangSmith managed deployments.

An application exposes a checkpoint-history endpoint (e.g. /api/history) that maps a user-supplied request field directly into the filter key of graph.get_state_history()/SqliteSaver.list(). An attacker submits a filter key such as "x') OR '1'='1", which breaks out of the json_extract path and forces the WHERE clause true, returning all stored checkpoints and bypassing intended filtering/access controls. A working proof-of-concept is published in the GHSA-9rwj-6rc7-p77c advisory.