LangGraph-Checkpointer: Kettenangriff führt zu RCE in selbst gehosteten Umgebungen

Forschende von Check Point haben drei behobene Schwachstellen in LangGraph offengelegt – dem offenen LangChain-Framework zum Aufbau von Multi-Agent-KI-Anwendungen. Zwei davon lassen sich laut den Forschenden zu einer Angriffskette kombinieren, die zu Remote Code Execution (RCE) auf selbst gehosteten Servern führt. Die Schwachstellen betreffen die Komponenten zur Speicherung von Checkpoints (Checkpointer) für SQLite und Redis. Die verwaltete Plattform LangSmith ist den Angaben zufolge nicht von diesen Problemen betroffen. Nutzende selbst gehosteter Installationen müssen die betroffenen Pakete umgehend aktualisieren.

Entdeckte Schwachstellen

Alle drei Schwachstellen wurden vom Check-Point-Forscher Yarden Porat entdeckt und im technischen Bericht des Unternehmens dokumentiert. Jede von ihnen erhielt eine eigene CVE-Kennung und ist in den Empfehlungen der GitHub Security Advisory bestätigt:

• CVE-2025-67644 (CVSS 7.3) – SQL injection in der SQLite-Checkpoint-Implementierung. Ein Angreifer kann SQL-Abfragen über Metadaten-Filter-Schlüssel manipulieren. Betroffen sind Versionen von langgraph-checkpoint-sqlite vor 3.0.1.
• CVE-2026-28277 (CVSS 6.8) – unsichere Deserialisierung von msgpack in LangGraph, die es erlaubt, beim Laden eines Checkpoints mit manipulierten Daten eine Objektrekonstruktion auszulösen. Betroffen sind Versionen von langgraph vor 1.0.10.
• CVE-2026-27022 (CVSS 6.5) – RediSearch-Query-Injection in @langchain/langgraph-checkpoint-redis, die es ermöglicht, Zugriffskontrollmechanismen zu umgehen. Betroffen sind Versionen vor 1.0.1.

Es ist hervorzuheben, dass keine der Schwachstellen für sich genommen ein kritisches Niveau auf der CVSS-Skala erreicht. Erst ihre Kombination erzeugt jedoch die gravierendste Bedrohung.

Mechanismus der Angriffskette: von SQL injection zu RCE

Laut Check Point lassen sich CVE-2025-67644 und CVE-2026-28277 zu einer Kette kombinieren, um Remote Code Execution zu erreichen. Voraussetzung ist, dass die Anwendung Zugriff auf den Endpunkt get_state_history() bereitstellt, über den historische Checkpoints anhand von Metadaten abgerufen werden können.

Die Abfolge des Angriffs sieht wie folgt aus:

1. Der Angreifer erstellt eine Payload im msgpack-Format, die Anweisungen zur Ausführung beliebigen Codes enthält.
2. Über SQL injection in den Filterparametern manipuliert der Angreifer das Ergebnis der Datenbankabfrage so, dass eine gefälschte Checkpoint-Zeile zurückgegeben wird, in deren Spalte „checkpoint“ vom Angreifer kontrollierte serialisierte Daten stehen.
3. Die Anwendung verarbeitet das Abfrageergebnis und deserialisiert den bösartigen Checkpoint-BLOB.
4. Die unsichere Deserialisierung führt zur Ausführung der Payload des Angreifers auf dem Server.

Der entscheidende Aspekt dieser Kette besteht darin, dass eine klassische SQL injection als Liefervektor für die Ausnutzung der Deserialisierungs-Schwachstelle dient. Ohne die erste Schwachstelle würde die zweite einen direkten Schreibzugriff auf den Checkpoint-Speicher voraussetzen, was die Angriffsfläche deutlich einschränkt.

Sicht der Entwickler und Umfang der Bedrohung

Die Maintainer von LangGraph haben CVE-2026-28277 als Post-Exploitation-Problem eingestuft: Für eine erfolgreiche Ausnutzung sei die Möglichkeit erforderlich, vom Angreifer kontrollierte Daten in den Checkpoint-Speicher zu schreiben. Nach ihrer Einschätzung sind typische Konfigurationen im verwalteten Hosting so ausgelegt, dass ein solcher Zugriff verhindert wird.

Die Angriffskette ist in selbst gehosteten Deployments anwendbar, die SQLite oder Redis als Checkpoint-Speicher verwenden, sofern Benutzereingaben in die Filterparameter einfließen. Die verwaltete Plattform LangSmith Deployment ist den Angaben zufolge nicht von diesen Schwachstellen betroffen. Hinweise auf eine aktive Ausnutzung unter realen Bedingungen lagen zum Zeitpunkt der Offenlegung nicht vor.

Bewertung der Auswirkungen

Am stärksten gefährdet sind Organisationen, die LangGraph in ihrer eigenen Infrastruktur betreiben, um KI-Agenten mit Zugriff auf interne Systeme aufzubauen. Im Erfolgsfall erlangt ein Angreifer die Möglichkeit, beliebigen Code in der Ausführungsumgebung des Agenten laufen zu lassen, was zur Kompromittierung von Laufzeitgeheimnissen und zum Zugriff auf angrenzende Systeme führen kann, auf die der Agent zugreifen darf.

Der Fall zeigt anschaulich, wie traditionelle Schwachstellenklassen – SQL injection und unsichere Deserialisierung – im Kontext von KI-Agenten-Frameworks an Gefährlichkeit gewinnen. Agenten verfügen in der Regel über erweiterte Privilegien und hohes Vertrauen, wodurch die Kompromittierung ihrer Ausführungsumgebung deutlich zerstörerischer ist als die eines herkömmlichen Webanwendungssystems.

Empfehlungen zur Behebung

• Aktualisieren Sie die betroffenen Pakete: langgraph-checkpoint-sqlite auf Version 3.0.1 oder höher, langgraph auf 1.0.10 oder höher, @langchain/langgraph-checkpoint-redis auf 1.0.1 oder höher.
• Implementieren Sie Authentifizierung für selbst gehostete LangGraph-Server – Endpunkte wie get_state_history() sollten nicht ohne Autorisierung zugänglich sein.
• Schließen Sie langlebige statische Geheimnisse aus der Ausführungsumgebung der Agenten aus; setzen Sie auf Credential-Rotation.
• Setzen Sie Netzsegmentierung ein: Isolieren Sie die Ausführungsumgebung der KI-Agenten von kritischen internen Systemen.
• Behandeln Sie KI-Agenten als privilegierte Identitäten und wenden Sie das Prinzip der minimalen Rechte an, um deren Zugriff zu beschränken.
• Validieren Sie Benutzereingaben, bevor Sie sie an die Filterparameter der Checkpoints übergeben – verlassen Sie sich nicht ausschließlich auf Schutzmechanismen auf Framework-Ebene.

Organisationen, die LangGraph in selbst gehosteten Konfigurationen einsetzen, sollten mit hoher Priorität alle drei betroffenen Komponenten aktualisieren und die Erreichbarkeit der State-Management-Endpunkte der Agenten prüfen. Selbst wenn bislang keine bestätigte Ausnutzung in realen Umgebungen bekannt ist, senkt die detaillierte technische Beschreibung der Angriffskette durch Check Point die Einstiegshürde für potenzielle Angreifer erheblich.