Langgraph Checkpoint Sqlite
Monthly
Cross-namespace data exposure in the Postgres- and SQLite-backed LangGraph stores (langgraph-checkpoint-postgres before 3.1.3 and langgraph-checkpoint-sqlite before 3.1.2) lets an authenticated, low-privileged caller who can influence a namespace label read, overwrite, or delete items stored under a different tenant's namespace. The stores flatten a namespace with ".".join(namespace), so a single label such as ("tenant.bob",) resolves to the same stored text as ("tenant", "bob"); only put/aput validated labels, while get, search, delete, list_namespaces, their async variants, and ops passed straight to batch/abatch accepted dotted labels unchecked. Exposure is deployment-dependent rather than universal: it requires an application that relies on namespace tuples to isolate tenants and passes untrusted input into those calls, InMemoryStore is unaffected because it compares namespace tuples, and there is no public exploit identified at time of analysis. The reported CVSS 4.0 score is 6.0, while the independent assessment rates it CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N.
SQL injection in the langgraph-checkpoint-sqlite package (versions 3.0.0 and below) allows untrusted metadata filter keys to be interpolated directly into SQLite queries, letting an attacker who controls filter key names alter the WHERE clause of checkpoint search queries and retrieve or manipulate checkpoint data outside their intended filter scope. The flaw is conditional rather than universal: it only triggers when a host application forwards attacker-controlled filter key names into SqliteSaver or AsyncSqliteSaver list(), alist(), or get_state_history() calls, since typical applications hardcode filter keys and are unaffected, and LangSmith managed deployments are explicitly not impacted because they disallow custom checkpointers. Publicly available exploit code exists and the vendor has released a fix in 3.0.1, but the EPSS score is very low (0.02%, 6th percentile) and there is no evidence of active exploitation; the NVD vector (7.8, AV:L/PR:L) and the independent assessment (AV:N/PR:N, C:H/I:L/A:L) disagree on network reachability and authentication, so prerequisites depend on how the exposing endpoint is deployed.
Cross-namespace data exposure in the Postgres- and SQLite-backed LangGraph stores (langgraph-checkpoint-postgres before 3.1.3 and langgraph-checkpoint-sqlite before 3.1.2) lets an authenticated, low-privileged caller who can influence a namespace label read, overwrite, or delete items stored under a different tenant's namespace. The stores flatten a namespace with ".".join(namespace), so a single label such as ("tenant.bob",) resolves to the same stored text as ("tenant", "bob"); only put/aput validated labels, while get, search, delete, list_namespaces, their async variants, and ops passed straight to batch/abatch accepted dotted labels unchecked. Exposure is deployment-dependent rather than universal: it requires an application that relies on namespace tuples to isolate tenants and passes untrusted input into those calls, InMemoryStore is unaffected because it compares namespace tuples, and there is no public exploit identified at time of analysis. The reported CVSS 4.0 score is 6.0, while the independent assessment rates it CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N.
SQL injection in the langgraph-checkpoint-sqlite package (versions 3.0.0 and below) allows untrusted metadata filter keys to be interpolated directly into SQLite queries, letting an attacker who controls filter key names alter the WHERE clause of checkpoint search queries and retrieve or manipulate checkpoint data outside their intended filter scope. The flaw is conditional rather than universal: it only triggers when a host application forwards attacker-controlled filter key names into SqliteSaver or AsyncSqliteSaver list(), alist(), or get_state_history() calls, since typical applications hardcode filter keys and are unaffected, and LangSmith managed deployments are explicitly not impacted because they disallow custom checkpointers. Publicly available exploit code exists and the vendor has released a fix in 3.0.1, but the EPSS score is very low (0.02%, 6th percentile) and there is no evidence of active exploitation; the NVD vector (7.8, AV:L/PR:L) and the independent assessment (AV:N/PR:N, C:H/I:L/A:L) disagree on network reachability and authentication, so prerequisites depend on how the exposing endpoint is deployed.