FlawOpen

flawopen.com/Teardowns/cve-2026-71433-langgraph-store-namespace-boundary

● CVE-2026-71433 · CVSS 5.3 · Mittel
Sicherheitsforschung · FlawOpen

LangGraph CVE-2026-71433: Namespace-Leak

Gezielte LangGraph-Lesezugriffe in Postgres und SQLite konnten Namespace-Grenzen überschreiten und Daten benachbarter Tenants offenlegen. Aktualisieren Sie beide Pakete auf 3.1.1.

CVSS-VektorCVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N
💡 Einfache Erklärung (ELI5)

Stellen Sie sich vor, eine Bibliothekarin soll Ordner holen, deren Name mit „team“ beginnt. Sucht der Katalog nur nach dem Textanfang, kann er auch „team2“ zurückgeben. LangGraph verband Namespace-Bezeichnungen mit Punkten und nutzte ein Präfixmuster, das den Punkt nicht als Grenze verlangte. Die Korrektur verlangt den exakten Namespace oder ein echtes folgendes Segment, damit der Ordner eines Tenants nicht mit dem eines anderen verwechselt wird.

Kernkonzepte & Begriffe

Namespace
Ein Tupel von Bezeichnungen, mit dem der LangGraph Store Einträge gruppiert. Eine Anwendung kann es als Grenze zwischen Benutzern oder Tenants verwenden.
Präfixbereich
Eine Anfrage zum Lesen eines Namespace und seiner Nachfolger. Ein korrekter Treffer beachtet Segmentgrenzen: foo umfasst foo.child, aber nicht den benachbarten Namespace foobar.
SQL-`LIKE`-Muster
Ein Textmuster, bei dem % für eine beliebige Zeichenfolge und _ für ein Zeichen steht. Diese Zeichen müssen maskiert werden, wenn Namespace-Bezeichnungen wörtlich gelten sollen.
CWE-863
Fehlerhafte Autorisierung: Der Store lieferte Datensätze außerhalb des Namespace, den der Aufrufer lesen durfte.

Framework-Zuordnungen

  • CWE-Referenz für die in diesem Leitfaden beschriebene Schwachstelle: CWE-863

Ursachenanalyse

Vor Version 3.1.1 wandelten die Postgres- und SQLite-Checkpoint-Stores Namespace-Tupel in punktgetrennten Text um und begrenzten Suchen mit LIKE '<namespace>%'. LIKE kennt den Namespace-Trenner nicht; eine Suche für foo konnte deshalb auch zum benachbarten Namespace foobar passen. Zulässige %- und _-Bezeichnungen konnten außerdem als Platzhalter wirken. list_namespaces hatte verwandte Fehler bei Präfixen und Suffixen. Ein gewöhnlicher bereichsgebundener Lesezugriff genügte; fehlerhafte Eingaben waren nicht nötig. Betroffen sind nur die Lesewege search und Namespace-Auflistung der Postgres-/SQLite-Stores, wenn eine Anwendung Namespaces zur Tenant-Trennung verwendet. get, put und delete nutzen exakte Gleichheit und waren nicht betroffen; InMemoryStore vergleicht Namespace-Elemente und war ebenfalls nicht betroffen. Die Korrektur verlangt exakte Gleichheit oder einen Punkt vor Nachfolgersegmenten, maskiert LIKE-Metazeichen und nutzt segmentbewusste Muster für Namespace-Auflistungen. SQLite vermeidet bei der Suche außerdem das ASCII-groß-/kleinschreibungsunabhängige Verhalten von LIKE. Laut Advisory gibt es keine Hinweise auf Ausnutzung in freier Wildbahn. Die betroffenen Pakete sind ab 3.1.1 korrigiert.

CVE-2026-71433: Erreichbarkeitsmatrix nach Bereitstellung

Bereitstellung und Namespace-FormDokumentiertes VerhaltenTriage-Maßnahme
PostgresStore / AsyncPostgresStore oder SqliteStore / AsyncSqliteStore vor 3.1.1; die Mandantentrennung hängt von Namespaces ab.Eine eingegrenzte search- oder list_namespaces-Abfrage kann einen benachbarten Namespace erreichen, wenn Bezeichnungen ein Textpräfix teilen (foo / foobar, 1 / 12) oder % / _ enthalten. SQLite behandelte bei der Suche außerdem reine ASCII-Groß-/Kleinschreibungsunterschiede als gleich.Aktualisieren Sie das zuständige Checkpoint-Paket auf 3.1.1 oder höher. Testen Sie benachbarte Präfixe, Platzhalterzeichen, Suffixe und Groß-/Kleinschreibung mit dem Produktions-Backend.
SQLite-Store vor 3.1.1 mit Namespace-Bezeichnungen, die sich nur durch ASCII-Groß-/Kleinschreibung unterscheiden.Die fehlerhafte Suche nach Nachfahren verwendete das ASCII-groß-/kleinschreibungsunabhängige LIKE, während exakte Operationen die Schreibweise unterschieden.Aktualisieren Sie und ergänzen Sie einen Regressionstest zur Schreibweise, falls Bezeichnungen sich so unterscheiden können.
UUID-Bezeichnungen fester Länge ohne % oder _.Laut Advisory ist dieses Schema nicht betroffen: Bezeichnungen fester Länge können keine Präfixe voneinander sein.Bestätigen Sie, dass jedes Segment diese Invariante erfüllt. Wenn Bezeichnungen variieren oder Platzhalter enthalten können, behandeln Sie die Bereitstellung als betroffen.
InMemoryStore.Nicht betroffen: Namespace-Elemente werden einzeln verglichen.Für dieses CVE ist keine Aktualisierung nötig; behalten Sie Prüfungen der Mandantenzugehörigkeit an der Anwendungsschnittstelle bei.
Gehostete LangSmith-Bereitstellung.Die Standardeinstellung LANGGRAPH_STORE_BACKEND=python verwendet AsyncPostgresStore und ist mit einem betroffenen Paket im Umfang. Das separate grpc-Backend erhielt eine gleichwertige Korrektur.Prüfen Sie konfiguriertes Backend und eingesetzte Version; verifizieren Sie Version oder gehosteten Rollout, statt die Betroffenheit aus dem Produktnamen abzuleiten.

Schritt-für-Schritt Angriffsablauf

Schritt 1

Store-Backend und Bezeichnungen prüfen

Die Bereitstellung muss langgraph-checkpoint-postgres oder langgraph-checkpoint-sqlite vor Version 3.1.1 einsetzen und Namespaces zur Trennung von Benutzern oder Tenants verwenden. Gemeinsame Präfixe sowie %- und _-Bezeichnungen machen die Grenze relevant.

Schritt 2

Ein gewöhnlicher Bereichs-Lesezugriff erfolgt

Eine authentifizierte Anwendungsanfrage sucht in einem Namespace wie foo. Der Aufrufer braucht keine besondere Nutzlast zu senden; der normale Namespace ist die Eingabe des fehlerhaften Vergleichs.

Schritt 3

Das Backend flacht ab und vergleicht Muster

Der Store verbindet Bezeichnungen mit Punkten und verwendet ein LIKE-Präfix mit abschließendem %. Da kein Trenner verlangt wird, kann foo zu foobar passen; Musterzeichen in Bezeichnungen können den Trefferbereich ebenfalls erweitern.

Schritt 4

Einträge benachbarter Namespaces können zurückkommen

Wenn die Anwendung Namespaces als Tenant-Grenzen behandelt, können Suche oder Auflistung gespeicherte Einträge eines anderen Benutzers zurückgeben. Das ist ein Vertraulichkeitsproblem auf Lesewegen, keine SQL-Injection und kein Schreibzugriff.

Schritt 5

Aktualisieren und Isolation erneut testen

Aktualisieren Sie beide passenden Pakete auf 3.1.1 oder neuer. Testen Sie benachbarte Präfixe, wörtliche %- und _-Bezeichnungen, Suffixe sowie das Verhalten der SQLite-Groß-/Kleinschreibung mit getrennten Test-Tenants.

Quellcode: Verwundbar vs. Sicher

Das verwundbare Prädikat behandelt jede Zeichenfolge, die mit dem abgeflachten Namespace beginnt, als Nachfolger. Die Korrektur ergänzt einen exakten Gleichheitsvergleich und verlangt vor Nachfolgersegmenten einen echten Punkt; außerdem maskiert sie Backslash, % und _ im LIKE-Muster. Der Upstream-Commit ersetzt auch die Präfix-/Suffixmuster von list_namespaces durch segmentbewusste Treffer und passt die SQLite-Suche an. Dies ist ein Quellcodeauszug, kein Ersatzmodul.

Quelltextauszug: libs/checkpoint-postgres/langgraph/store/postgres/base.py

VERWUNDBARE IMPLEMENTIERUNG
def _prepare_batch_search_queries(op):
    ns_condition = "TRUE"
    ns_param = None
    if op.namespace_prefix:
        ns_condition = "store.prefix LIKE %s"
        ns_param = (f"{_namespace_to_text(op.namespace_prefix)}%",)
    return ns_condition, ns_param
GEHÄRTETER SICHERHEITS-PATCH
def _escape_like_literal(text: str) -> str:
    return text.replace("\\", "\\\\").replace("%", "\\%").replace("_", "\\_")

def _namespace_prefix_condition(namespace_prefix: tuple[str, ...]) -> tuple[str, tuple]:
    path = _namespace_to_text(namespace_prefix)
    condition = r"(store.prefix = %s OR store.prefix LIKE %s ESCAPE '\\')"
    return condition, (path, f"{_escape_like_literal(path)}.%")

if op.namespace_prefix:
    ns_condition, ns_param = _namespace_prefix_condition(op.namespace_prefix)

Checkliste für Engineering & Systemsicherheit

Quellen