Die kurze Antwort
Auf der Black Hat 2026 legte Check Point Research rund elf Schwachstellen in den KI-Agenten-Frameworks offen, auf denen die meisten Teams aufbauen — LangChain, LangGraph, CrewAI, AutoGen, Microsoft Agent Framework und Google ADK — und die Schlagzeile heißt nicht Prompt Injection. Sie lautet, dass diese Frameworks angreiferkontrollierte Inhalte regelmäßig aus der Datenebene entkommen und die vertrauenswürdige Logik erreichen lassen: Orchestrierung, Speicher, Routing, Zustandsverwaltung und Systemanweisungen. So wird aus einem Text-Prompt eine SSRF-Anfrage, ein deserialisiertes Objekt, ein bösartiger Dateischreibvorgang oder ein Shell-Befehl.
Die Fehlerklassen sind alt — unsichere Deserialisierung, SSRF, Path Traversal, Use-after-free — aber hier weit gefährlicher, weil Agenten-Frameworks API-Schlüssel, Datenbank-Zugangsdaten und breiten Tool-Zugriff halten. Eine Schwachstelle im Microsoft Agent Framework reichte über das Laden nicht vertrauenswürdiger Checkpoints bis zur Remote Code Execution. Wenn autonome Agenten auf Ihrer Roadmap stehen, ist die praktische Lehre unmissverständlich: Behandeln Sie das Framework selbst als nicht vertrauenswürdigen Code zur Eingabeverarbeitung, nicht als sichere interne Infrastruktur.
Was Check Point tatsächlich fand
Auf der Black Hat 2026 stellte Check Point Research rund ein Dutzend Schwachstellen vor — mehrere als kritisch eingestuft —, verteilt über die Frameworks, die die Agenten-Entwicklung dominieren: LangChain, LangGraph, CrewAI, AutoGen, Microsoft Agent Framework und Google ADK. Keiner der einzelnen Fehler ist exotisch. Es sind dieselben Kategorien, die Application-Security-Teams seit zwei Jahrzehnten verfolgen: unsichere Deserialisierung, Server-Side Request Forgery (SSRF), Path Traversal und Use-after-free. Was sich geändert hat, ist der Kontext, in dem sie nun leben.
Das schwerwiegendste Beispiel stammt aus Microsofts Agent Framework: eine unsichere Deserialisierung, bei der der Agent — ausgelöst durch Prompt Injection — nicht vertrauenswürdige Checkpoint-Daten lud und dazu gebracht werden konnte, Angreifercode auszuführen — ein Remote-Code-Execution-Pfad mit geschätzt kritischer Schwere. Microsoft bestätigte den Bericht, zahlte eine Bug-Bounty von 10.000 US-Dollar und behob den Fehler, vergab aber keine CVE, da das Framework zum Zeitpunkt der Meldung durch Check Point noch kein allgemein verfügbares Produkt war. An anderer Stelle fanden die Forscher einen Datei schreibenden Assistenten in Google ADK, der standardmäßig über einfaches HTTP erreichbar war — eine Agentenfunktion, dem Netzwerk ohne jede vorgeschaltete Authentifizierung ausgesetzt. Für Teams, die bereits KI-Agenten-Workflows bauen, sind das keine Randfälle; es ist die Standardverdrahtung der Quickstart-Tutorials.
Warum alte Fehler in Agenten schlimmer werden
Um zu verstehen, warum eine vertraute Deserialisierungs-Schwachstelle in einem Agenten bedrohlicher ist, betrachten Sie, was ein Agenten-Framework tatsächlich hält. Es ist kein zustandsloser Request-Handler. Es trägt die API-Schlüssel des Modells, die Zugangsdaten für die Datenbanken und SaaS-Tools, die der Agent aufrufen kann, sein Gesprächsgedächtnis und oft direkte Pfade in interne Netzwerke. Check Points frühere Arbeit an LangGraph machte die Einsätze greifbar: Ein kompromittierter LangGraph-Server legte LLM-API-Schlüssel, Kundendaten, CRM-Zugangsdaten, Gesprächsverlauf und internen Netzwerkzugriff auf einmal offen. Das Framework ist ein Engpass mit hohem Vertrauen, also erbt jede Code-Execution-Schwachstelle darin dieses gesamte Vertrauen.
Der Mechanismus, der es ausnutzbar macht, ist das Grenzversagen, zu dem Check Point immer wieder zurückkehrt. In einer normalen App sind Nutzereingaben Daten und bleiben Daten. In diesen Agenten-Frameworks kann angreiferkontrollierter Prompt-Inhalt aus der Datenebene entkommen und den Kontrollfluss beeinflussen — welches Tool als Nächstes läuft, was aus dem Speicher deserialisiert wird, welche URL der Agent abruft, in welchen Pfad er schreibt. Genau das ist die frühere LangGraph-Checkpointer-Kette in Kurzform: Eine SQL-Injection (CVE-2025-67644) platzierte einen bösartigen Checkpoint, und eine unsichere msgpack-Deserialisierung (CVE-2026-28277) verwandelte diesen Checkpoint in Remote Code Execution, mit einer parallelen Redis-Injection-Variante (CVE-2026-27022). Die Fixes landeten in langgraph 1.0.10 und höher, langgraph-checkpoint-sqlite 3.0.1+ und langgraph-checkpoint-redis 1.0.2+ — aber es ist die Form des Angriffs, die sich verallgemeinern lässt.
Warum das ein Muster ist, keine einzelne CVE
Der Grund, das als architektonische Warnung statt als Patch-Notiz zu behandeln, ist, dass dieselben Schwächen unabhängig voneinander in unverwandten Frameworks auftauchen. Wenn sechs verschiedene Projekte — von LangChain über Googles ADK bis zu Microsofts Agent Framework — allesamt die Daten-/Kontroll-Grenze auf ähnliche Weise durchlässig machen, ist die Ursache nicht ein einzelner unachtsamer Maintainer. Es ist, dass das gesamte Ökosystem auf Fähigkeit und Entwicklungstempo hin optimiert heranwuchs und Speicher, Tools und Routing mit implizitem Vertrauen verdrahtete, bevor irgendjemand die Orchestrierungsebene als Sicherheitsgrenze behandelte. Microsofts eigenes Sicherheitsteam kennzeichnete dieselbe „Prompts werden zu Shells”-Klasse von RCE bereits früher im Jahr 2026; die Offenlegung von Check Point zeigt, dass sie systemisch ist.
Diese Einordnung ist wichtig, weil sie ändert, wo Sie Aufwand investieren. Wenn Sie glauben, Prompt Injection sei die Krankheit, gießen Sie Ressourcen in Eingabefilterung und Guardrail-Prompts — notwendig, aber nie vollständig, weil eine entschlossene Injection durchkommen wird. Wenn Sie akzeptieren, dass die Injection nur der Lieferwagen ist und das eigentliche Problem darin liegt, was das Framework mit der Nutzlast tut, investieren Sie in die Grenzen, die Schäden tatsächlich eindämmen: niemals nicht vertrauenswürdigen Zustand deserialisieren, jeden Agenten-Endpunkt authentifizieren und jedem Agenten die engstmöglichen Zugangsdaten und Netzwerkreichweite geben. Der erste Ansatz versucht, ein ungewinnbares Eingabe-Sanitisierungsrennen zu gewinnen; der zweite begrenzt den Schadensradius, wenn das Rennen verloren geht.
Was das für DACH-Software-Teams bedeutet
Die erste Konsequenz ist, dass Agenten-Frameworks jetzt in Ihren Application-Security-Umfang gehören, nicht in einen separaten „KI-Experiment”-Topf. Die Komponenten, die Teams als interne Infrastruktur behandeln — Checkpointer, Speicher, Router, Tool-Loader — sind genau die Eingabeverarbeitungs-Pfade, die Check Point ausnutzte. Sie verdienen dasselbe Threat Modeling, Dependency-Pinning und Penetrationstests und Sicherheitsaudits, die Sie bereits auf Ihre Web-Ebene anwenden. Wenn Ihr Pentest-Umfang am API-Gateway endet und die Agenten-Laufzeit nie berührt, testet er den falschen Perimeter.
Was das für den DACH-Markt bedeutet. Im deutschsprachigen Raum treibt vor allem der Mittelstand KI-Agenten in Kundenservice, Beschaffung und interne Automatisierung — oft aus dem Quickstart-Template heraus, ohne dedizierte Sicherheitsprüfung. Für regulierte FinTechs und HealthTech-Anbieter verschärft sich die Lage: Ein Agenten-Framework mit unbeschränkten Zugangsdaten ist eine Angriffsfläche, die unter DSGVO, BaFin-/DORA-Anforderungen im Finanzsektor und der laufenden NIS2-Umsetzung nachweislich kontrolliert werden muss. Als Orientierung bieten sich die Mindeststandards und Handlungsempfehlungen des BSI (Bundesamt für Sicherheit in der Informationstechnik) an — die Prinzipien „nicht vertrauenswürdige Eingaben validieren” und „Rechteausweitung eindämmen” gelten auch für die Orchestrierungsebene von Agenten.
Die zweite ist ein Compliance-Punkt, der regulierte Arbeit am härtesten trifft. Ein Agent, der über ein Framework mit nicht eng gefassten Zugangsdaten Produktionsdaten lesen kann, ist eine Kontrolllücke, und eine Remote-Code-Execution-Schwachstelle in diesem Framework ist ein meldepflichtiger Vorfall, der nur darauf wartet zu passieren. Für FinTech- und HealthTech-Teams sind die Kontrollen, die Sie um Agenten-Frameworks legen — Identitäten nach dem Least-Privilege-Prinzip, Egress-Allowlists, sandboxed Deserialisierung, ein Audit-Trail der Tool-Aufrufe — zugleich die Nachweise, die Prüfer unter SOC 2, DORA und der EU-KI-Verordnung erwarten. Sie einmal zu dokumentieren dient sowohl der Sicherheit als auch dem Regulator.
Die dritte ist eine architektonische Disziplin, die wenig kostet, wenn Sie sie früh tun, und viel, wenn Sie sie spät tun. Geben Sie jedem Agenten seine eigenen, eng gefassten Zugangsdaten nach dem Least-Privilege-Prinzip statt eines gemeinsamen Hauptschlüssels, damit ein gekaperter Agent nicht Ihr gesamtes Umfeld erreichen kann. Setzen Sie eine Egress-Allowlist vor die Tool-Aufrufe der Agenten, damit ein SSRF nicht auf interne Dienste überschwenken kann. Und laden Sie niemals Checkpoints, Speicher oder serialisierten Zustand aus einer Quelle, die Sie nicht vollständig kontrollieren. Teams, die diese Einschränkungen von Anfang an in die Plattform- und DevOps-Ebene einbauen, absorbieren die nächste Framework-CVE als Routine-Update; Teams, die sie überspringen, erben ein unverfolgbares, überprivilegiertes Geflecht, dessen Entwirrung teuer ist.
Was jetzt zu tun ist
Sie müssen dieses Quartal keine Frameworks austauschen. Sie müssen aber aufhören, die Agenten-Laufzeit als vertrauenswürdigen internen Code zu behandeln. Hier ist die auslieferbare Fassung.
- Inventarisieren und pinnen Sie Ihre Frameworks. Listen Sie jedes Agenten-Framework und jede Version in Produktion auf und aktualisieren Sie auf die gepatchten Releases (für LangGraph bedeutet das langgraph 1.0.10+, checkpoint-sqlite 3.0.1+, checkpoint-redis 1.0.2+).
- Abonnieren Sie die Sicherheitshinweise jedes Frameworks. Behandeln Sie Framework-CVEs wie Laufzeit- und OS-Patches, mit einem Verantwortlichen und einem SLA.
- Deserialisieren Sie niemals nicht vertrauenswürdigen Zustand. Checkpoints, Speicher und serialisierte Objekte aus jeder Quelle, die Sie nicht kontrollieren, sind Code-Execution-Risiken; validieren oder sandboxen Sie sie.
- Authentifizieren Sie jeden Agenten-Endpunkt. Keine Agentenfunktion — Datei-Schreiber, Tool-Server, Admin-Routen — sollte über einfaches HTTP ohne Authentifizierung erreichbar sein.
- Begrenzen Sie Zugangsdaten und Egress. Geben Sie jedem Agenten Least-Privilege-Schlüssel und eine ausgehende Allowlist, damit eine Injection nicht auf Ihr gesamtes Netzwerk überschwenken kann.
- Nehmen Sie Agenten in Ihre Sicherheitstests auf. Bringen Sie die Agenten-Laufzeit in Threat Modeling und Pentest-Umfang und führen Sie einen Audit-Trail der Tool-Aufrufe für SOC 2, DORA und die EU-KI-Verordnung.
Nichts davon ist ein Urteil gegen LangChain, CrewAI oder die anderen — es sind etablierte Werkzeuge, die es wert sind, genutzt zu werden. Die dauerhafte Erkenntnis ist architektonisch: Wenn Agenten vom Antworten zum Handeln übergehen, ist das Framework, das sie zusammenschaltet, nun sicherheitskritischer Code, und die Teams, die es heute als nicht vertrauenswürdig modellieren, werden nach der nächsten Offenlegung weit weniger aufräumen müssen.
Häufig gestellte Fragen
Was hat Check Point Research auf der Black Hat 2026 offengelegt?
Check Point Research legte rund ein Dutzend Schwachstellen (etwa 11) in den meistgenutzten KI-Agenten-Frameworks offen, darunter LangChain, LangGraph, CrewAI, AutoGen, Microsoft Agent Framework und Google ADK. Die Schwachstellen gehören zu klassischen Software-Fehlerklassen — unsichere Deserialisierung, SSRF, Path Traversal und Use-after-free —, die innerhalb von Frameworks, die API-Schlüssel, Zugangsdaten und Datenzugriffe halten, weit gefährlicher werden. Ein Problem im Microsoft Agent Framework ermöglichte Remote Code Execution über das Laden nicht vertrauenswürdiger Checkpoints (geschätzter CVSS 9.8); Microsoft zahlte eine Bounty von 10.000 US-Dollar und behob es, vergab aber keine CVE, weil das Framework bei der Offenlegung kein allgemein verfügbares Produkt war. Ein Datei schreibender Assistent in Google ADK war standardmäßig über HTTP erreichbar.
Ist das dasselbe wie Prompt Injection?
Nein. Der Kernpunkt von Check Point ist, dass Prompt Injection nur der Zustellmechanismus ist. Die eigentliche Schwachstelle ist, was das Framework mit dem eingeschleusten Inhalt macht: Statt angreiferkontrollierten Text auf die Datenebene zu beschränken, lassen die Frameworks ihn oft in die vertrauenswürdige Logik einfließen — Orchestrierung, Speicher, Routing, Zustandsverwaltung und Systemanweisungen. Genau das verwandelt einen Text-Prompt in eine SSRF-Anfrage, ein deserialisiertes Objekt, einen Dateischreibvorgang oder einen Shell-Befehl. Der Fehler steckt in der Middleware, nicht im Modell.
Welche KI-Agenten-Frameworks sind betroffen?
Die Offenlegung nennt LangChain, LangGraph, CrewAI, AutoGen, Microsoft Agent Framework und Google ADK — die Frameworks, zu denen die meisten Teams zuerst greifen. Eine frühere Check-Point-Kette in LangGraph kombinierte eine SQL-Injection (CVE-2025-67644), eine unsichere msgpack-Deserialisierung mit Remote Code Execution (CVE-2026-28277) und eine Redis-Injection (CVE-2026-27022) über den Checkpointer, behoben in langgraph 1.0.10+, langgraph-checkpoint-sqlite 3.0.1+ und langgraph-checkpoint-redis 1.0.2+. Das Muster, nicht eine einzelne Bibliothek, ist die Geschichte: Dieselben Schwächen treten im gesamten Ökosystem immer wieder auf.
Müssen wir aufhören, LangChain, CrewAI oder AutoGen zu nutzen?
Nein. Das sind etablierte, aktiv gepflegte Frameworks, und der verantwortungsvolle Schritt ist zu patchen, nicht sie herauszureißen. Aktualisieren Sie auf die behobenen Versionen, abonnieren Sie die Sicherheitshinweise jedes Frameworks und behandeln Sie das Framework selbst als Angriffsfläche: Laden Sie niemals Checkpoints, Speicher oder serialisierten Zustand aus nicht vertrauenswürdigen Quellen, exponieren Sie keine HTTP-Endpunkte von Agenten ohne Authentifizierung und stellen Sie Tool-Aufrufe von Agenten hinter Egress-Kontrollen. Ziel ist es, die Orchestrierungsebene nicht länger als vertrauenswürdige interne Infrastruktur zu behandeln.
Was sollten Engineering-Teams jetzt tun?
Inventarisieren Sie jedes Agenten-Framework und jede Version in der Produktion und pinnen Sie sie auf gepatchte Releases. Modellieren Sie die eigenen Komponenten des Frameworks — Speicher, Checkpointer, Router, Tool-Loader — als nicht vertrauenswürdige Eingabepfade und validieren oder sandboxen Sie alles Deserialisierte. Geben Sie Agenten eng gefasste Zugangsdaten nach dem Least-Privilege-Prinzip und Netzwerk-Egress-Allowlists, damit ein gekaperter Agent nicht Ihr gesamtes Umfeld erreichen kann. Nehmen Sie diese Pfade in Ihren bestehenden Umfang für Application-Security- und Penetrationstests auf. Für regulierte FinTech- und HealthTech-Arbeit dokumentieren Sie die Kontrollen als Nachweis für SOC 2, DORA und die EU-KI-Verordnung.
Quellen
The Register — Prompt injection isn't the bug, AI agent frameworks are
Check Point Blog — When your AI agent's memory becomes a security liability
Check Point Research — From SQLi to RCE: exploiting LangGraph's checkpointer
Microsoft Security Blog — When prompts become shells: RCE vulnerabilities in AI agent frameworks