Was ist passiert?
Die Cloud Security Alliance veröffentlichte am 6. August 2026 eine Forschungsnotiz, in der CoreBreak beschrieben wird, ein Satz von vier CVEs in den Agent-Frameworks AWS, Google und Vercel, bei denen die Tool-Dispatch-Schicht einen Tool-Aufruf ausführte, ohne zu überprüfen, ob ein Sprachmodell ihn tatsächlich erzeugt hatte. Für alle vier gibt es Herstellerkorrekturen.
Die AI Safety Initiative der Cloud Security Alliance veröffentlichte am 6. August 2026 einen Forschungsbericht, in dem ein plattformübergreifendes Schwachstellenmuster beschrieben wird, das die Forscher CoreBreak nannten. Der Mitteilung zufolge präsentierten die Sicherheitsforscher Hedi Ingber und Aviyam Ivgi, Mitbegründer der Sicherheitsfirma Stealth, auf der Black Hat USA 2026 Ergebnisse, die zeigen, dass die Tool-Ausführungsebenen von Amazon Bedrock AgentCore, dem Agent Development Kit (ADK) für Python von Google und den mit dem AI SDK von Vercel verteilten Harness-Paketen jeweils dazu veranlasst werden könnten, ein Tool auszuführen, ohne dass es jemals zu einem legitimen Modellwechsel kommt. Da das Sprachmodell nie aufgerufen wurde, so heißt es in der Notiz, hatten die um das Modell herum aufgebauten Leitplanken keine Möglichkeit, einzugreifen.
Agent-Frameworks dieser Art haben eine gemeinsame Struktur. Eine Orchestrierungsschicht bündelt die Benutzeranfrage, die Systemaufforderung, den Konversationsverlauf und einen Katalog verfügbarer Tools, sendet sie an ein Sprachmodell und wartet darauf, dass das Modell eine strukturierte Anweisung zurückgibt, die ein Tool und seine Argumente benennt. Das SDK sendet dann die entsprechende Funktion, das entsprechende Skript oder den API-Aufruf und gibt das Ergebnis zurück in die Konversation. CoreBreak zielt auf den letzten Schritt ab: Dem Hinweis zufolge behandelte die Versandlogik in jedem der drei Produkte Daten, die lediglich einem modellgenerierten Toolaufruf ähnelten, als maßgeblich, ohne zu überprüfen, woher sie stammten.
In der Notiz werden vier CVE-Identifikatoren mit unterschiedlichen Ausnutzungspfaden aufgeführt, wobei Hersteller-Bulletins und Einträge in der National Vulnerability Database zitiert werden. AWS hat CVE-2026-18830 (CVSS v4.0 8.6, High) dem Bedrock AgentCore-Harness-Fehler zugewiesen, bei dem ein authentifizierter Remote-Anrufer einen Tool-Use-Content-Block direkt in die letzte Nachricht einer InvokeHarness-API-Anfrage einfügen konnte. Google hat CVE-2026-18236 (9.3, Kritisch) einer ADK-Schwachstelle zugeordnet, bei der ein Angreifer, der Ereignisse in den Sitzungsverlauf einschleusen konnte, eine menschliche Genehmigungsbestätigung fälschen konnte, weil der Bestätigungsprozessor nicht überprüfte, ob das Zieltool zum ausführenden Agenten gehörte, ob es tatsächlich eine Bestätigung benötigte oder ob sein Name und seine Argumente mit dem ursprünglich aufgezeichneten Anruf übereinstimmten. Vercels @ai-sdk/harness-codex und @ai-sdk/harness-opencode erhielten CVE-2026-64650 und CVE-2026-64651 (jeweils 6.3, Mittel), wobei bösartiger Code, der bereits in einer Linux-Sandbox ausgeführt wurde, eine Prozesspfadprüfung bestehen konnte, die jedem Prozess vertraute, dessen Befehlszeile den Pfad eines genehmigten Hilfsskripts enthielt.
Korrekturen sind verfügbar, aber der Aufwand ist je nach Bereitstellungsmodell unterschiedlich. In der Notiz heißt es, dass die Fehlerbehebung von AWS für die vollständig verwaltete Bedrock AgentCore InvokeHarness-API automatisch vor dem 31. Juli 2026 bereitgestellt wurde und keine Maßnahmen des Kunden erforderte, obwohl weiterhin empfohlen wird, die Abdeckung für eine bestimmte Region und Konfiguration zu bestätigen. Der Fix von Google wurde am 16. Juli 2026 im ADK für Python Version 2.5.0 ausgeliefert, und die Fixes von Vercel wurden am 10. Juli 2026 in Harness-Codex 1.0.29 und Harness-Opencode 1.0.28 ausgeliefert – Paketaktualisierungen, die selbst gehostete Betreiber selbst anwenden müssen. Der Hinweis stellt CoreBreak in den Unterschied zu Prompt Injection: Prompt Injection versucht, das Urteilsvermögen des Modells zu manipulieren, während CoreBreak die Frage umgeht, ob das Modell überhaupt Urteilsvermögen ausgeübt hat.
Lesen Sie die Primärquelle: labs.cloudsecurityalliance.org ↗
Warum es wichtig ist
Inhaltsfilter, Systemaufforderungen, Ablehnungsschulungen und menschliche Genehmigungstore gehen alle davon aus, dass das Modell die Partei ist, die entscheidet, ob ein Tool ausgeführt wird. Wenn die Dispatch-Schicht etwas in der Form eines Tool-Aufrufs eines Modells akzeptiert, werden diese Kontrollen eher umgangen als außer Kraft gesetzt – und die Protokolle, die Überwachungsteams normalerweise prüfen, werden nie erstellt.
Die meisten Unternehmenskontrollen für die Agenten-KI basieren auf oder um das Modell herum. Systemaufforderungen schränken sensible Aktionen ein, Inhaltsfilter bewerten Ein- und Ausgaben, Ablehnungstraining wird in Modellgewichtungen integriert und menschliche Bestätigungsschritte sperren Tools mit hohem Risiko. Bei jeder dieser Kontrollen wird davon ausgegangen, dass das Modell die Partei ist, die entscheidet, ob ein Tool ausgeführt wird. Wenn eine Dispatch-Schicht eine korrekt geformte Nutzlast ausführt, bieten diese Investitionen kaum präventiven Schutz – nicht weil sie schlecht konzipiert waren, sondern weil die Angriffsrouten um den Ort herum verlaufen, an dem sie ausgeführt werden. Das ist eine andere Problemklasse als eine Leitplanke, über die man argumentieren kann.
Die spezifischen Fähigkeiten hinter diesen Versandebenen geben dem Ergebnis Gewicht. In der Notiz heißt es, dass die Vercel-Schwachstellen Host-exponierte Tools wie geheime Suchvorgänge, Bereitstellungsvorgänge und Cloud-API-Aufrufe erreichen könnten. Der Google-Fehler ist noch offensichtlicher: Er ermöglichte es gefälschten Bestätigungen, Tools zu erreichen, die bewusst hinter der menschlichen Zustimmung platziert wurden, was Kontrollorganisationen für Aktionen vorbehalten, die als zu folgenreich für eine Automatisierung angesehen werden. Eine Umgehung, die speziell den „Human-in-the-Loop“-Schritt neutralisiert, untergräbt die Schadensbegrenzung, die viele Teams anführen, wenn sie eine umfassendere Agentenautonomie rechtfertigen.
Die Patch-Story verdeutlicht auch eine Asymmetrie, die mit der Verbreitung von Agententools erneut auftreten wird. Kunden des vollständig verwalteten AWS-Dienstes wurden ohne Zutun behoben. Teams, die das ADK von Google oder die Harness-Pakete von Vercel in ihren eigenen Umgebungen ausführen, müssen die Empfehlung beachten, die Abhängigkeit aktualisieren und erneut bereitstellen – und Abhängigkeitsaktualisierungen in Produktions-Stacks verzögern sich routinemäßig um Wochen oder Monate. Die gleiche zugrunde liegende Designlücke hat daher ein sehr unterschiedliches praktisches Offenlegungsfenster, je nachdem, ob eine Organisation die Agenteninfrastruktur als Service nutzt oder sie in ihrer eigenen Codebasis anbietet.
Es gibt auch eine Erkennungslücke. In dem Hinweis wird darauf hingewiesen, dass sich die Sicherheitsüberwachung für Agentensysteme im Allgemeinen auf Modelleingaben und -ausgaben konzentriert – die Protokollierung von Eingabeaufforderungen, die Kennzeichnung verdächtiger Abschlüsse und die Überprüfung der vom Modell ausgewählten Tools. Wenn ein Tool ausgeführt wird, ohne dass das Modell ausgeführt wird, sind keine dieser Artefakte vorhanden, die protokolliert werden könnten. Mehrere wichtige Dinge bleiben unbekannt: In der Notiz werden keine Hinweise auf eine Ausnutzung in freier Wildbahn gemeldet, es wird keine Schätzung abgegeben, wie viele Bereitstellungen betroffen waren, und es wird kein Proof-of-Concept-Code beschrieben. CSA gibt offen zu, dass zwei Offenlegungen bei vier Anbietern kein branchenweites Muster belegen und dass es sich bei dem beobachteten Schweregradienten um einen Datenpunkt und nicht um eine Bewertungsregel handelt.
Was Sie als nächstes sehen sollten
Ob selbst gehostete Betreiber tatsächlich die Google- und Vercel-Paketaktualisierungen anwenden, ob ähnliche Herkunftslücken in anderen Agent-Frameworks auftauchen, ob eine offene Ausnutzung gemeldet wird und ob Anbieter auf signierte, sitzungsgebundene Autorisierungstoken für die Toolausführung umsteigen.
Die konkretste kurzfristige Frage ist die Patch-Nutzung. Der von AWS verwaltete Fix wird als bereits bereitgestellt beschrieben, ADK 2.5.0 und die beiden Vercel-Harness-Releases helfen jedoch nur Betreibern, die sie installieren. Achten Sie auf Downstream-Signale – Akzeptanzraten der Paketregistrierung, von Anbietern angebotene Forks, die das Update nie abrufen, und interne Plattform-Images, die ältere Versionen anheften. Der Hinweis empfiehlt auch eine retrospektive Prüfung: Überprüfung der Protokolle auf Toolaufrufe, die nicht mit einem entsprechenden, wohlgeformten Modellabschluss im Sitzungsdatensatz verknüpft werden können. Ob Organisationen über die Dispatch-Layer-Telemetrie verfügen, um diese Prüfung durchzuführen, ist ungeklärt.
Die zweite Frage ist der Umfang. CoreBreak deckt drei Produkte ab, aber das beschriebene Muster – das Vertrauen auf die Form einer Nutzlast oder die Befehlszeile eines Prozesses als Beweis der Modellautorisierung – ist nicht spezifisch für sie. Jedes Framework mit derselben SDK-zu-Modell-zu-Tool-Struktur könnte eine vergleichbare Lücke aufweisen. Achten Sie auf weitere Hinweise von anderen Betreuern des Agent-Frameworks und darauf, ob die Forscher nach der Black-Hat-Präsentation ausführlichere technische Details veröffentlichen. Weitere bestätigte Fälle würden das Argument der CSA untermauern, dass es sich hierbei eher um ein strukturelles Muster als um drei zufällige Fehler handelt.
Drittens: Beobachten Sie die architektonische Reaktion. Die Empfehlung von CSA besteht darin, einen kryptografischen Nachweis zu verlangen, dass ein Tool-Aufruf aus einer echten Modellvervollständigung stammt – einem signierten, sitzungsgebundenen, einmaligen Token –, anstatt die Autorisierung aus der Nachrichtenstruktur oder der Prozessidentität abzuleiten. Ob große Anbieter dieses Modell übernehmen und ob es zu etwas wird, nach dem Käufer bei der Beschaffung fragen und es überprüfen können, wird darüber entscheiden, ob diese Offenlegung Designs ändert oder nur Patches produziert. Die Bestätigungsverarbeitungslogik, die den Werkzeugbesitz, die Bestätigungsanforderung und die Argumentintegrität anhand des ursprünglich aufgezeichneten Anrufs validiert, ist die engere Version desselben Fixes.
Schauen Sie sich abschließend die Governance- und Threat-Intelligence-Tracks an. CSA verweist auf sein MAESTRO-Bedrohungsmodellierungs-Framework und die AI Controls Matrix v1.1 als Orte, an denen Ausführungskontrolle und Berechtigungsverwaltungsbewertungen nun explizit den Tool-Versand abdecken sollten, und verbindet CoreBreak mit seiner früheren GuardFall-Forschung zu Leitplankenumgehungen auf Shell-Ebene. Außerdem lohnt es sich zu überwachen: ob die NVD-Einträge oder CVSS-Scores überarbeitet werden, ob Anbieter nach dem Vorfall über die ersten Bulletins hinausgehende Details veröffentlichen und ob sich ein bestätigter Missbrauch herausstellt. Keines der vier CVEs enthält derzeit in den von der CSA zitierten Materialien einen öffentlichen Bericht über Missbrauch in freier Wildbahn, und das Fehlen solcher Berichte ist nicht dasselbe wie das Fehlen von Aktivitäten.
