LangGraph-Schwachstellenkette: Wie eine SQL-Injection im Checkpointer und ein unsicherer msgpack-Decoder selbst-gehostete KI-Agenten zur Remote-Code-Execution führen

TL;DR — 90 Sekunden

Betroffen?

Selbst-gehostete LangGraph-Deployments, die den SQLite-Checkpointer (langgraph-checkpoint-sqlite < 3.0.1) oder den Redis-Checkpointer (@langchain/langgraph-checkpoint-redis < 1.0.1) mit nutzerkontrolliertem Filter-Input betreiben, sowie langgraph < 1.0.10 für den msgpack-Decoder. LangSmith-gehostete Deployments sind nicht betroffen.

Risiko?

Verkettet (CVE-2025-67644 + CVE-2026-28277) eine Remote-Code-Execution auf dem Agenten-Server: SQL-Injection im Checkpointer → gefälschte Checkpoint-Zeile → unsichere msgpack-Deserialisierung beim Laden → Code-Ausführung. Einzeln: SQLi der Metadaten-Abfrage (7.3), unsichere Objekt-Rekonstruktion (6.8), RediSearch-Query-Injection mit Zugriffskontroll-Bypass (6.5).

Sofortmaßnahme?

Auf langgraph ≥ 1.0.10, langgraph-checkpoint-sqlite ≥ 3.0.1 und @langchain/langgraph-checkpoint-redis ≥ 1.0.1 heben. Den get_state_history()-Pfad nicht ohne Authentifizierung exponieren; Filter-Input behandeln wie jede andere nutzerkontrollierte Eingabe.

Empfehlung?

Mittelstand und Enterprise: priorisiert einspielen, wo ein selbst-gehosteter LangGraph-Server externen oder halb-vertrauten Filter-Input verarbeitet; der Agenten-Server gehört als privilegierte Identität behandelt, nicht als interner Hilfsdienst.

Kritikalität?

high (referenziert das Hero-Badge — verkettete RCE, aber an selbst-gehostetes Setup, exponierten Pfad und nutzerkontrollierten Filter gebunden; kein bekannter Masseneinsatz).

 

Was ist das Problem?

LangGraph baut Agenten als Zustandsmaschine: Jeder Schritt eines Agenten wird als Checkpoint persistiert, damit ein Lauf pausieren, fortsetzen, verzweigen und seine Historie zurücklesen kann. Dieses Gedächtnis liegt in einem austauschbaren Speicher, dem Checkpointer, üblich auf SQLite oder Redis. Genau dort sitzen die drei Lücken, die Check Point Research am 12. Juni offengelegt hat. Der entscheidende Punkt ist nicht exotisch, sondern alt: Es sind klassische Schwachstellenklassen (SQL-Injection, unsichere Deserialisierung, Query-Injection), die hier in einer Komponente landen, die erhöhte Rechte und Vertrauen trägt — dem Speicher, aus dem ein Agent seine eigene Vergangenheit lädt.

Die schwerste Wirkung entsteht aus einer Kette. CVE-2025-67644 (CVSS 7.3) ist eine SQL-Injection im SQLite-Checkpointer: Über Metadaten-Filterschlüssel lässt sich die Abfrage manipulieren, die LangGraph zum Abruf historischer Checkpoints stellt. CVE-2026-28277 (CVSS 6.8) ist eine unsichere msgpack-Deserialisierung: Beim Laden eines Checkpoints rekonstruiert LangGraph aus dem gespeicherten BLOB ein Objekt, ohne den Inhalt als nicht vertrauenswürdig zu behandeln. Einzeln betrachtet ist die zweite Lücke laut LangGraph eine Post-Exploitation-Schwäche, sie verlangt, dass ein Angreifer bereits Checkpoint-Daten schreiben kann. Die SQL-Injection liefert genau diese Vorbedingung frei Haus: Sie schiebt eine gefälschte Checkpoint-Zeile mit angreiferkontrolliertem BLOB in die Ergebnismenge, die der Decoder anschließend arglos rekonstruiert.

Die dritte Lücke, CVE-2026-27022 (CVSS 6.5), ist eine RediSearch-Query-Injection im Redis-Checkpointer (@langchain/langgraph-checkpoint-redis). Sie erlaubt, Suchabfragen so zu manipulieren, dass Zugriffskontrollen umgangen werden — etwa der Abruf von Checkpoints über die vorgesehene Mandanten- oder Thread-Grenze hinweg. Sie steht nicht in der RCE-Kette, gehört aber in dieselbe Betrachtung, weil sie denselben architektonischen Reflex trifft: Filter-Input, der ungeprüft in eine Abfrage gegen den Agentenspeicher fließt.

Wer ist betroffen?

Die Trennlinie verläuft entlang Self-Hosting plus nutzerkontrolliertem Filter-Input. Die volle Kette greift dort, wo ein selbst-betriebener LangGraph-Server den get_state_history()-Pfad erreichbar macht und Filterwerte aus einer nicht vollständig vertrauenswürdigen Quelle annimmt, etwa ein Agenten-Endpunkt, der Endnutzer- oder Mandanten-Eingaben in die Checkpoint-Abfrage durchreicht. Wer LangGraph rein intern, ohne exponierten Verlaufsabruf und ohne fremden Filter-Input fährt, hat ein geringeres Akut-Risiko, schließt die Lücke aber mit demselben Update. LangSmith-gehostete Deployments sind nach Angaben der Maintainer nicht betroffen, weil die gehostete Persistenzschicht den dafür nötigen Fremdschreibzugriff auf den Checkpoint-Store unterbindet.

Auswirkungen

Das verlässlich erreichbare Worst-Case-Ergebnis der Kette ist Code-Ausführung im Laufzeitkontext des Agenten. Das ist deshalb gravierend, weil ein KI-Agent selten ein nacktes Rechenobjekt ist: Er hält in der Regel API-Schlüssel, Modell-Tokens, Datenbank-Zugänge und oft weitreichende Werkzeuge. LangGraph formuliert die Eskalation nüchtern (vom Schreibzugriff auf den Checkpoint-Store zur Code-Ausführung) und benennt die Folge: Laufzeit-Secrets können offengelegt werden, und der Agent kann als Sprungbrett auf weitere Systeme dienen, die seine Laufzeit erreicht. Anders gesagt: Wer den Agenten kompromittiert, erbt dessen Berechtigungen, nicht nur dessen Rechenzeit.

Die ehrliche Einordnung der Schwere: Die CVSS-Einzelwerte liegen im High-/Medium-Bereich (7.3, 6.8, 6.5), nicht bei 9+. Die RCE entsteht erst durch die Verkettung und ist an konkrete Vorbedingungen gebunden: selbst-gehostet, exponierter Verlaufspfad, nutzerkontrollierter Filter, SQLite- oder Redis-Checkpointer. Wo diese Bedingungen zusammenkommen, ist der Handlungsdruck hoch; wo nicht, bleibt es ein reguläres, aber zügiges Update. Die übergeordnete Lehre formuliert Check Point präzise: Eine altbekannte Schwachstellenklasse wie SQL-Injection wird gefährlicher, wenn sie in einem KI-Agenten-Framework auftaucht, das erhöhte Rechte und Vertrauen mit sich trägt. Die Klasse ist nicht neu — der Ort, an dem sie greift, schon.

Mitigation / Sofortmaßnahmen

Sofort: betroffene Pakete auf die gepatchte Linie heben

# Python-Stack (SQLite-Checkpointer + Kern)
pip install -U "langgraph>=1.0.10" "langgraph-checkpoint-sqlite>=3.0.1"

# oder mit uv
uv pip install -U "langgraph>=1.0.10" "langgraph-checkpoint-sqlite>=3.0.1"

# JS/TS-Stack (Redis-Checkpointer)
npm install @langchain/langgraph-checkpoint-redis@^1.0.1

# Installierte Versionen verifizieren
pip show langgraph langgraph-checkpoint-sqlite 2>/dev/null | grep -E 'Name|Version'
npm ls @langchain/langgraph-checkpoint-redis

Den Verlaufspfad nicht ungeschützt exponieren

# get_state_history() (bzw. der Endpunkt, der ihn aufruft) gehört hinter Authentifizierung.
# Filter-/Metadaten-Werte sind nutzerkontrollierter Input — nie ungeprüft in die
# Checkpoint-Abfrage durchreichen. Wo möglich, Filterfelder serverseitig auf eine
# Allowlist bekannter Schlüssel begrenzen, statt beliebige Metadaten-Keys zu akzeptieren.

Wenn ein Update kurzfristig nicht möglich ist (Stopgaps, kein Ersatz für den Patch)

# 67644 / 27022: Filter-Input vor der Checkpoint-Abfrage auf eine feste Allowlist
#                an Metadaten-Schlüsseln zwingen; freie Filterausdrücke aus
#                nutzerkontrollierter Quelle blockieren.
# 28277:         Checkpoint-Store gegen Fremdschreibzugriff abdichten — kein
#                schreibender Pfad aus nicht vertrauenswürdiger Quelle auf SQLite-Datei
#                bzw. Redis-Keys des Checkpointers.
# Allgemein:     get_state_history()-nahe Endpunkte vorübergehend nur intern/authentifiziert.

LangGraph stuft CVE-2026-28277 ausdrücklich als Post-Exploitation-Problem ein, die Deserialisierung wird erst zur Waffe, wenn ein Angreifer Checkpoint-Daten schreiben kann. Das ist kein Grund zur Entwarnung, sondern der Hebel der Mitigation: Wer den Schreibpfad auf den Checkpoint-Store dichthält und Filter-Input zähmt, nimmt der RCE-Kette die Vorbedingung, auch bevor jedes Paket aktualisiert ist. Das Update bleibt Pflicht; die Eingrenzung des Schreibzugriffs ist die robustere, dauerhafte Linie.

Detection / Prüfung

Bestand feststellen: Wer betreibt welchen Checkpointer in welcher Version?

# Python-Projekte im Bestand auf betroffene Pakete absuchen
grep -rnE 'langgraph-checkpoint-sqlite|langgraph\b' --include='requirements*.txt' \
  --include='pyproject.toml' --include='uv.lock' --include='poetry.lock' path/to/repos

# JS/TS-Projekte auf den Redis-Checkpointer absuchen
grep -rn '@langchain/langgraph-checkpoint-redis' --include='package*.json' path/to/repos

# Laufende Umgebung
pip show langgraph langgraph-checkpoint-sqlite 2>/dev/null | grep -E 'Name|Version'

Code-Pfad: wird Filter-Input aus nutzerkontrollierter Quelle in den Verlaufsabruf gereicht?

# Aufrufe des Verlaufsabrufs und der Metadaten-Filter finden
grep -rnE 'get_state_history|aget_state_history|\.filter\b|metadata_filter' \
  --include='*.py' --include='*.ts' --include='*.js' path/to/app

# Gegenprobe: Wird der Filter aus Request-/Endnutzer-Eingaben gespeist?
grep -rnE 'request\.(args|json|query)|req\.(body|query|params)' \
  --include='*.py' --include='*.ts' path/to/app

Abnahme nach dem Patch

# Versionen nach Update bestätigen (Ziel: 1.0.10 / 3.0.1 / 1.0.1)
pip show langgraph langgraph-checkpoint-sqlite 2>/dev/null | grep Version
npm ls @langchain/langgraph-checkpoint-redis

# Regressionstest nur in isolierter Testumgebung:
# - präparierter Metadaten-Filter darf keine fremde/gefälschte Checkpoint-Zeile mehr liefern
# - ein manipuliertes Checkpoint-BLOB darf beim Laden kein Objekt mehr rekonstruieren
#   (auf gepatchtem Stand verifizieren — keine Live-Daten verwenden)

Betreiberempfehlung

Operational Decision Block:

• Priorisiert einspielen (heute), wenn: ein selbst-gehosteter LangGraph-Server den get_state_history()-Pfad erreichbar macht und Filter-/Metadaten-Input aus externer oder halb-vertrauter Quelle annimmt (SQLite- oder Redis-Checkpointer).
• Im laufenden Patch-Zyklus (diese Woche), wenn: LangGraph rein intern läuft, ohne exponierten Verlaufsabruf und ohne fremden Filter-Input.
• Nur verifizieren, wenn: Pakete bereits auf langgraph 1.0.10 / langgraph-checkpoint-sqlite 3.0.1 / @langchain/langgraph-checkpoint-redis 1.0.1 stehen und der Schreibpfad auf den Checkpoint-Store nachweislich nicht aus fremder Quelle erreichbar ist.

Mittelstand

Wenn Sie einen KI-Agenten selbst betreiben, behandeln Sie den Agenten-Server wie eine privilegierte Identität, nicht wie einen internen Hilfsdienst: Authentifizierung vor den Verlaufsabruf, keine langlebigen statischen Secrets in der Agenten-Laufzeit, Netzsegmentierung zwischen Agent und übrigen Systemen. Dann die eine Frage klären, die diese Kette wirklich stellt: Reicht irgendwo Endnutzer- oder Mandanten-Eingabe ungeprüft als Filter in die Checkpoint-Abfrage? Wenn ja, ist die dauerhafte Härtung die Allowlist auf der Filterebene, nicht nur das Update.

Enterprise / mehrstufige Flotten

Den LangGraph-Bestand per Inventar (SBOM, Lockfiles) erfassen statt per Stichprobe, der Checkpointer steckt oft als transitive Abhängigkeit in Agenten-Diensten. Schreibpfade auf SQLite-Dateien und Redis-Keys des Checkpointers gegen Fremdzugriff abdichten; Mandantentrennung gegen die RediSearch-Query-Injection (27022) zusätzlich serverseitig erzwingen, nicht allein über den Suchausdruck.

Kubernetes / deklarative Stacks

Gepatchte Images mit den neuen Paketständen über die Registry ausrollen und per Digest pinnen. Den Checkpoint-Store (Redis/SQLite-PVC) per NetworkPolicy und RBAC vom unkontrollierten Schreibzugriff trennen. Daran denken: Ein rollierender Neustart ist nötig, damit die Pods die gepatchten Bibliotheken laden.

Was wir konkret getan haben

Wir haben den Advisory am Erscheinungstag gegen unseren Bestand geprüft. Die erste Frage war nicht „Nutzen wir LangGraph?“, sondern „Wo läuft ein Agent selbst-gehostet, welchen Checkpointer benutzt er, und erreicht ihn fremder Filter-Input?“. Weil unsere Agenten-Dienste über Lockfiles und Image-Digests inventarisiert sind, war die Versions- und Topologiefrage in Minuten beantwortet statt per Dienst-Stichprobe. Die betroffenen Paketstände sind gehoben, und der Verlaufsabruf liegt, wo er überhaupt exponiert ist, hinter Authentifizierung; Filterfelder sind serverseitig auf bekannte Schlüssel begrenzt, statt beliebige Metadaten-Keys zu akzeptieren.

Der Lesson-Learned ist eine Architektur-Aussage, keine Einzelmaßnahme: Das Gefährliche an dieser Kette ist nicht „LangGraph ist unsicher“, sondern dass eine klassische SQL-Injection in der Gedächtnisschicht eines Agenten landet, also dort, wo Vertrauen und Rechte gebündelt sind. Patchen schließt die drei konkreten Stellen; die dauerhafte Härtung schließt die Klasse: nutzerkontrollierter Filter-Input wird auf Allowlists gezwungen, der Schreibpfad auf den Checkpoint-Store wird gegen Fremdzugriff abgedichtet, und der Agent wird als privilegierte Identität mit minimalem Rechte-Fußabdruck behandelt. Genau hier zahlt sich aus, dass wir selbst-gehostete KI für den Mittelstand nicht als Bequemlichkeit, sondern als Souveränität bauen: Wer den Agenten besitzt, muss ihn auch wie ein privilegiertes System schützen — und kann es, weil Speicher, Netz und Secrets im eigenen Zugriff liegen.

Fazit

Die LangGraph-Kette ist kein Feueralarm für jeden, aber ein Pflichttermin für alle, die KI-Agenten selbst hosten. Drei alte Schwachstellenklassen (SQL-Injection, unsichere Deserialisierung, Query-Injection) treffen hier die Gedächtnisschicht eines Agenten, und zwei davon ergeben verkettet eine Remote-Code-Execution auf dem Agenten-Server. Die Schwere ist ehrlich einzuordnen: hohe Einzelwerte, RCE nur unter konkreten Vorbedingungen (selbst-gehostet, exponierter Verlaufspfad, nutzerkontrollierter Filter, SQLite- oder Redis-Checkpointer), LangSmith-gehostet nicht betroffen. Wer diese Bedingungen erfüllt, handelt im 48-Stunden-Fenster; wer LangGraph rein intern fährt, spielt das Update im laufenden Zyklus ein. Die nachhaltige Lehre liegt eine Ebene tiefer als der Patch: Ein KI-Agent ist kein Hilfsdienst, sondern eine privilegierte Identität. Patchen schließt die Stelle; den Agenten als privilegiertes System zu behandeln (Filter auf Allowlist, Schreibpfad dicht, minimale Rechte) schließt die Klasse.

Quellen

• The Hacker News — „LangGraph Flaw Chain Exposes Self-Hosted AI Agents to Remote Code Execution“ (12.06.2026) — Übersicht der drei CVEs und der Kette
• Check Point Research — „From SQLi to RCE: Exploiting LangGraph’s Checkpointer“ (Yarden Porat) — Primärquelle, technische Analyse
• GitHub Security Advisory GHSA-9rwj-6rc7-p77c — CVE-2025-67644 (SQL-Injection, SQLite-Checkpointer)
• GitHub Security Advisory GHSA-g48c-2wqr-h844 — CVE-2026-28277 (unsichere msgpack-Deserialisierung)
• GitHub Security Advisory GHSA-5mx2-w598-339m — CVE-2026-27022 (RediSearch-Query-Injection, Redis-Checkpointer)
• LangChain — LangGraph (Projektseite / Dokumentation get_state_history())