GHSA-9RWJ-6RC7-P77C

Vulnerability from github – Published: 2025-12-10 00:02 – Updated: 2025-12-11 15:49
VLAI?
Summary
LangGraph's SQLite is vulnerable to SQL injection via metadata filter key in SQLite checkpointer list method
Details

Context

A SQL injection vulnerability exists in LangGraph's SQLite checkpoint implementation that allows attackers to manipulate SQL queries through metadata filter keys. This affects applications that accept untrusted metadata filter keys (not just filter values) in checkpoint search operations.

Impact

Attackers who control metadata filter keys can execute arbitrary sql queries against the database.

Root Cause

The _metadata_predicate() function constructs SQL queries by interpolating filter keys directly into f-strings without validation:

# VULNERABLE CODE (before fix)
for query_key, query_value in metadata_filter.items():
    operator, param_value = _where_value(query_value)
    predicates.append(
        f"json_extract(CAST(metadata AS TEXT), '$.{query_key}') {operator}"
    )
    param_values.append(param_value)

While filter values are parameterized, filter keys are not validated, allowing SQL injection.

Attack Example

Before Fix:

from langgraph.checkpoint.sqlite import SqliteSaver

saver = SqliteSaver.from_conn_string("checkpoints.db")

# Attacker controls the filter keys
malicious_filter = {"x') OR '1'='1": "dummy"}

# Returns ALL checkpoints, bypassing filtering
results = list(saver.list(None, filter=malicious_filter))

Resulting SQL:

WHERE json_extract(CAST(metadata AS TEXT), '$.x') OR '1'='1') = ?
-- Injected condition makes WHERE clause always true

Who Is Affected?

LangSmith Deployment Customers: NOT Impacted

LangSmith deployment customers are NOT affected by this vulnerability. LangSmith deployments do not allow configuring custom checkpointers, so the vulnerable code path cannot be reached.

High Risk: Custom Server Deployments

You are affected if your application: - Runs a custom server with SqliteSaver checkpointer - Exposes an endpoint for fetching checkpoint history (e.g., via get_state_history()) - Accepts metadata filter keys from untrusted sources

Example vulnerable code:

# Custom server endpoint - User controls filter key names - DANGEROUS
@app.post("/api/history")
def get_history(request):
    filter_field = request.json.get("filter_field")  # Untrusted input
    filter_value = request.json.get("filter_value")

    # VULNERABLE: Attacker can bypass access controls
    history = list(graph.get_state_history(
        config,
        filter={filter_field: filter_value}
    ))
    return history

Note on privilege escalation: If an endpoint allows end users to specify arbitrary filter keys, those users likely already have legitimate access to query the checkpoint database. In such cases, this vulnerability may not constitute a privilege escalation, as users who can control filter keys would typically already be expected to have database access. However, the SQL injection still allows bypassing intended filtering logic and metadata-based access controls that the application may rely on for data isolation.

Additional Security Hardening (Defense in Depth)

This release also includes hardening improvements:

1. Checkpoint Limit Parameter: used f-string interpolation into parameterized query. Not considered a vulnerability as it requires users to accept untrusted input and not validate it against the actual API signature.

2. Store Filter Value Parameterization: Refactored all filter value handling from manual quote escaping to parameterized queries

Remediation

Immediate Actions

  1. Update to the patched version of langgraph-checkpoint-sqlite
  2. Audit your code for locations where filter keys come from untrusted sources
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "langgraph-checkpoint-sqlite"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-67644"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-89"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-10T00:02:21Z",
    "nvd_published_at": "2025-12-11T00:16:23Z",
    "severity": "HIGH"
  },
  "details": "# Context\n\nA SQL injection vulnerability exists in LangGraph\u0027s SQLite checkpoint implementation that allows attackers to manipulate SQL queries through metadata filter keys. This affects applications that accept **untrusted metadata filter keys** (not just filter values) in checkpoint search operations.\n\n# Impact\n\nAttackers who control metadata filter keys can execute arbitrary sql queries against the database.\n\n# Root Cause\n\nThe `_metadata_predicate()` function constructs SQL queries by interpolating filter keys directly into f-strings without validation:\n\n```python\n# VULNERABLE CODE (before fix)\nfor query_key, query_value in metadata_filter.items():\n    operator, param_value = _where_value(query_value)\n    predicates.append(\n        f\"json_extract(CAST(metadata AS TEXT), \u0027$.{query_key}\u0027) {operator}\"\n    )\n    param_values.append(param_value)\n```\n\nWhile filter **values** are parameterized, filter **keys** are not validated, allowing SQL injection.\n\n# Attack Example\n\n**Before Fix:**\n```python\nfrom langgraph.checkpoint.sqlite import SqliteSaver\n\nsaver = SqliteSaver.from_conn_string(\"checkpoints.db\")\n\n# Attacker controls the filter keys\nmalicious_filter = {\"x\u0027) OR \u00271\u0027=\u00271\": \"dummy\"}\n\n# Returns ALL checkpoints, bypassing filtering\nresults = list(saver.list(None, filter=malicious_filter))\n```\n\n**Resulting SQL:**\n```sql\nWHERE json_extract(CAST(metadata AS TEXT), \u0027$.x\u0027) OR \u00271\u0027=\u00271\u0027) = ?\n-- Injected condition makes WHERE clause always true\n```\n\n## Who Is Affected?\n\n### LangSmith Deployment Customers: NOT Impacted\n\n**LangSmith deployment customers are NOT affected by this vulnerability.** LangSmith deployments do not allow configuring custom checkpointers, so the vulnerable code path cannot be reached.\n\n### High Risk: Custom Server Deployments\n\nYou are affected if your application:\n- Runs a custom server with SqliteSaver checkpointer\n- Exposes an endpoint for fetching checkpoint history (e.g., via `get_state_history()`)\n- Accepts metadata filter keys from untrusted sources\n\n**Example vulnerable code:**\n```python\n# Custom server endpoint - User controls filter key names - DANGEROUS\n@app.post(\"/api/history\")\ndef get_history(request):\n    filter_field = request.json.get(\"filter_field\")  # Untrusted input\n    filter_value = request.json.get(\"filter_value\")\n\n    # VULNERABLE: Attacker can bypass access controls\n    history = list(graph.get_state_history(\n        config,\n        filter={filter_field: filter_value}\n    ))\n    return history\n```\n\n**Note on privilege escalation:** If an endpoint allows end users to specify arbitrary filter keys, those users likely already have legitimate access to query the checkpoint database. In such cases, this vulnerability may not constitute a privilege escalation, as users who can control filter keys would typically already be expected to have database access. However, the SQL injection still allows bypassing intended filtering logic and metadata-based access controls that the application may rely on for data isolation.\n\n### Additional Security Hardening (Defense in Depth)\n\nThis release also includes hardening improvements:\n\n**1. Checkpoint Limit Parameter**: used f-string interpolation into parameterized query.  Not considered a vulnerability as it requires users to accept untrusted input and not validate it against the actual API signature. \n\n**2. Store Filter Value Parameterization**: Refactored all filter value handling from manual quote escaping to parameterized queries\n\n## Remediation\n\n### Immediate Actions\n\n1. **Update to the patched version** of `langgraph-checkpoint-sqlite`\n2. **Audit your code** for locations where filter keys come from untrusted sources",
  "id": "GHSA-9rwj-6rc7-p77c",
  "modified": "2025-12-11T15:49:44Z",
  "published": "2025-12-10T00:02:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/langchain-ai/langgraph/security/advisories/GHSA-9rwj-6rc7-p77c"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-67644"
    },
    {
      "type": "WEB",
      "url": "https://github.com/langchain-ai/langgraph/commit/297242913f8ad2143ee3e2f72e67db0911d48e2a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/langchain-ai/langgraph"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "LangGraph\u0027s SQLite is vulnerable to SQL injection via metadata filter key in SQLite checkpointer list method"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…