LangGraph-Luecken zeigen das Risiko gespeicherter Agenten

Worum es geht

Check Point Research hat am 11. Juni 2026 Details zu drei inzwischen gepatchten Schwachstellen in LangGraph veröffentlicht. Die spannendste Kette verbindet eine SQL-Injection im SQLite-Checkpointer mit unsicherer Deserialisierung und kann in bestimmten selbst gehosteten Setups zu Remote Code Execution führen.

Das ist keine abstrakte Laborwarnung. LangGraph wird genutzt, um zustandsbehaftete KI-Agenten zu bauen: Workflows, die mehrere Schritte, Werkzeuge und Zwischenergebnisse speichern. Genau diese gespeicherte Erinnerung wird zum Angriffspunkt, wenn eine Anwendung Nutzerparameter ungeprüft in die Checkpoint-Suche durchreicht.

Was LangGraph-Checkpointer tatsächlich machen

LangGraph-Checkpointer speichern den Zustand eines Agenten nach einzelnen Schritten. Dadurch kann ein Agent später fortsetzen, seine Historie anzeigen oder mit früheren Ergebnissen weiterarbeiten. In selbst gehosteten Installationen können dafür unter anderem SQLite- oder Redis-Backends eingesetzt werden.

Laut Check Point entsteht die kritische Kette, wenn eine Anwendung get_state_history() mit einem vom Nutzer kontrollierten filter anbietet. Der SQLite-Checkpointer baute Teile der Abfrage aus Metadaten-Schlüsseln zusammen. Ein Angreifer konnte dadurch SQL einschleusen, eine gefälschte Checkpoint-Zeile in das Ergebnis bringen und anschließend Daten auslösen, die beim Laden des Checkpoints unsicher verarbeitet wurden.

Check Point nennt drei betroffene Bereiche: CVE-2025-67644 für die SQLite-SQL-Injection, CVE-2026-28277 für unsafe msgpack deserialization und CVE-2026-27022 für eine ähnliche Injection-Klasse im Redis-Checkpointer. Gepatcht sind laut Research-Post unter anderem langgraph-checkpoint-sqlite 3.0.1+, langgraph 1.0.10+ und langgraph-checkpoint-redis 1.0.2+.

Warum das wichtig ist

KI-Agenten sind nicht nur Chatfenster. Sie bekommen oft API-Schlüssel, interne Dokumente, Ticketzugriff, Build-Systeme oder Browser-Werkzeuge. Wenn der Persistenz-Layer eines Agenten kompromittiert wird, kann daraus mehr werden als ein kaputter Chatverlauf.

Die Meldung ist auch deshalb relevant, weil der Angriff nicht beim Modell selbst beginnt. Er entsteht an der Softwarekante um das Modell herum: Datenbankabfragen, Serialisierung, gespeicherter Zustand, Nutzerfilter. Genau dort entstehen gerade viele reale Risiken, während Teams ihre ersten Agenten aus Prototypen in interne Produktion heben.

Für Entwickler ist die praktische Konsequenz klar: Patches einspielen, get_state_history() nicht direkt mit ungeprüften Nutzerfiltern verbinden und gespeicherte Agentenzustände wie sensible Serverdaten behandeln.

Einfach erklärt

Stell dir eine Bäckerei vor, die jede Teigschüssel mit einem Zettel versieht: Kundin, Rezept, Uhrzeit, nächster Arbeitsschritt. Wenn jemand eigene Zettel in die Ablage schmuggeln darf und die Bäckerei diese Zettel später ungeprüft als Arbeitsanweisung ausführt, kann aus einer harmlosen Bestellhistorie plötzlich ein Sabotageplan werden.

LangGraph-Checkpoints sind ähnlich: Sie sind Gedächtnisnotizen für Agenten. Das Gedächtnis ist nützlich, aber es darf nicht von außen mit Befehlen verwechselt werden.

Praktisches Beispiel

Ein internes Support-Team betreibt einen LangGraph-Agenten für 25.000 Kundentickets pro Monat. Der Agent speichert pro Ticket mehrere Checkpoints, damit ein Mitarbeiter später sehen kann, warum ein Rabatt vorgeschlagen oder ein Fall eskaliert wurde.

Wenn die Anwendung eine Historien-Suche anbietet und Filter wie user_id oder ticket_status ungeprüft übernimmt, könnte ein Angreifer einen manipulierten Filter senden. In einem verwundbaren Setup landet dann nicht nur eine falsche Suchabfrage in SQLite, sondern eine präparierte Checkpoint-Zeile, die beim Laden Code ausführt. Aus einer Komfortfunktion für Audit-Trails wird ein Eintrittspunkt in den Server.

Einordnung und Grenzen

Erstens betrifft die beschriebene Kette nicht automatisch jede LangGraph-Nutzung. Check Point grenzt das Risiko auf selbst gehostete Setups mit SQLite- oder Redis-Checkpointer und nutzerkontrollierten Filtern ein. LangChains managed LangSmith Deployment nutzt laut Check Point PostgreSQL und sei von dieser Kette nicht betroffen.

Zweitens sind die Schwachstellen gepatcht. Die eigentliche Gefahr liegt deshalb bei ungepflegten Deployments, internen Agenten ohne saubere Update-Prozesse und Anwendungen, die Debug- oder History-Endpunkte zu breit freigeben.

Drittens ersetzt ein Update nicht die Architekturarbeit. Auch gepatchte Agentensysteme brauchen Eingabevalidierung, minimale Rechte für Werkzeuge, getrennte Secrets und Logging, das Angriffe auf den Persistenz-Layer sichtbar macht.

SEO- und GEO-Schlüsselbegriffe

LangGraph, LangChain, AI agent security, Check Point Research, CVE-2025-67644, CVE-2026-28277, CVE-2026-27022, remote code execution, SQLite checkpointer, Redis checkpointer, AI workflow security