Mehrere Sicherheitslücken in der Agent-Infrastruktur von AWS, Google und Vercel zeigen ein gefährliches Muster: Agent-Fehler Tools ohne Modellaufruf konnten dazu führen, dass Anweisungen an Agent-Tools gelangen, ohne dass das zuständige Modell überhaupt einen autorisierenden Schritt ausführen musste. In einigen Angriffsvarianten wurde der Modellaufruf übersprungen – damit konnten Systemprompts, Inhaltsfilter und modellbasierte Schutzmechanismen nicht rechtzeitig eingreifen.
Die betroffenen Produkte unterscheiden sich dabei in Details, erfordern aber jeweils eine Form von Zugriff auf den relevanten Ausführungs- oder Autorisierungsweg. Wichtig: Das Risiko ist begrenzt auf das, was der Agent ohnehin bereits ausführen darf. Wer keine sensiblen Tools angebunden hat, gewinnt durch den Angriff nicht automatisch neue Möglichkeiten.
Warum das Überspringen des Modellaufrufs so kritisch ist
Im normalen Ablauf eines Agentensystems übergibt das SDK der Modellschicht die Nutzeranfrage, den Systemprompt, die Konversation sowie die verfügbaren Tool-Definitionen. Das Modell entscheidet dann, ob ein Tool aufgerufen werden soll, und liefert eine strukturierte Anweisung zurück – inklusive Toolname und Argumenten. Erst danach führt die Laufzeitkomponente den Toolaufruf aus.
In den fraglichen Pfaden fehlte jedoch die Verknüpfung („Provenance“) zwischen dem Modellresultat und dem späteren Tool-Dispatch. Die Laufzeit behandelte Daten, die wie ein Tool-Aufruf aussahen, als ausreichend legitim, obwohl kein echter Modellturn vorlag. Genau hier setzt die Idee hinter CoreBreak an: Angreifer müssen nicht das Modell dazu bringen, Regeln zu brechen, sondern müssen den relevanten Übergang erreichen, bevor das Modell überhaupt dran ist.
Welche Komponenten betroffen sind – und wie gepatcht wurde
Obwohl die Lücken unterschiedliche Bedingungen hatten, lassen sich die Fixes auf eine gemeinsame Linie zurückführen: Tool-Autorisierung muss an überprüfbare Ereignisse im Agentenfluss gebunden sein, nicht an die bloße Form von eingehenden Daten.
- AWS: Betroffen war die Amazon Bedrock AgentCore Harness-API InvokeHarness. AWS meldete einen Fix serverseitig für Fälle, in denen ein Tool-Use-Block im finalen Request-Message-Teil direkt in die Ereignisverarbeitung gelangte.
- Google: In der Agent Development Kit (ADK) für Python gab es mehrere Pfade. Google adressierte die Probleme in ADK 2.5.0 (CVE-2026-18236) durch zusätzliche Prüfungen in der Autorisierung bzw. beim Umgang mit user-authored Events.
- Vercel: In Vercel AI SDK Harness-Komponenten für Codex und OpenCode wurden Lücken in der „Harness Relay“-Verarbeitung geschlossen. Betroffene Versionen wurden durch Releases von @ai-sdk/harness-codex und @ai-sdk/harness-opencode aktualisiert.
Die konkreten Patchstände lagen zeitlich unterschiedlich, wurden aber jeweils in den jeweiligen Bibliotheken bzw. Services implementiert.
AWS: Tool-Use-Blocks ohne erneute Modellentscheidung
Bei AWS ordnete das Unternehmen die Schwachstelle als CVE-2026-18830 ein (CVSS v4.0: 8.6) und verwies auf unzureichende Eingabevalidierung im AgentCore Harness. In einem beschriebenen Szenario konnte ein authentifizierter Remote-Client im finalen Nachrichtenblock eines InvokeHarness-Requests einen Tool-Use-Content-Block platzieren. Danach konnte die Event-Loop das benannte Tool direkt dispatchen, ohne zuvor den Modellpfad abzuwarten.
AWS gab an, dass die Lücke das managed InvokeHarness-API-Umfeld bis vor dem 31. Juli 2026 betraf und dann serverseitig durch Validierung behoben wurde. Laut Hersteller wurde die Gegenmaßnahme automatisch ausgerollt und erforderte keine Kundenaktionen.
Gleichzeitig gilt: Der Fix für den managed Service deckte nicht automatisch eine vergleichbare Code-Passage in Strands (Python, Open Source) ab. Dort existierte ein Shortcut in der Event-Loop: Wenn die letzte Nachricht einen Tool-Use-Block enthielt, wurde die Modellausführung übersprungen. Diese Logik war (Stand der Berichterstattung) in der Repository-Hauptlinie noch vorhanden.
Forscher erklärten, dass die generelle Fernausnutzbarkeit vom konkreten App-Design abhängt: Entscheidend ist, ob ein Angreifer untrusted Caller-Nachrichten strukturieren, gespeicherte Historien beeinflussen oder Tool-Use-Blöcke an die Stelle bringen kann, die die Event-Loop als „letzte Nachricht“ konsumiert. AWS veröffentlichte hierzu zudem Dokumentation, statt einen separaten CVE-Fix für standalone Strands Deployments zu liefern.
Google ADK: Confirmation-Fälschungen und ein Umgehen über Resumable Mode
In Googles Agent Development Kit für Python traten mehrere Varianten auf. Der erste gemeldete Pfad wurde als CVE-2026-18236 (CVSS v4.0: 9.3) beschrieben. Dort ging es um Mechanismen, bei denen bestimmte Tools eine Bestätigung durch eine Person benötigen. Ein Angreifer, der Session-Historie-Events manipulieren oder injizieren konnte, konnte dadurch eine gefälschte Genehmigung erzeugen und so ein Tool ausführen, obwohl keine echte Freigabe vorlag.
Der Bestätigungsprozessor prüfte zunächst nicht ausreichend, ob das bestätigte Zieltool zur ausführen Instanz gehörte, ob das Tool überhaupt eine Bestätigung benötigte und ob Toolname sowie Argumente zu dem ursprünglich protokollierten Aufruf in der Session passten. In der Aktualisierung fügte Google genau diese Checks hinzu.
Zusätzlich enthielt ADK 2.5.0 eine weitere, zusammenhängende Absicherung. In sogenannten resumable-mode Abläufen wurden user-authored Events akzeptiert, die Teile einer function_call enthalten konnten. Dadurch konnte es so aussehen, als seien das Anweisungen zur Ausführung registrierter Tools – ohne den vorgesehenen LLM-Schritt. Google hat daraufhin function calls in user-authored Nachrichten abgelehnt.
Die Veröffentlichung machte auch deutlich, dass beide Findings nicht als einheitliche Gesamtkennzeichnung verstanden werden sollten: Die öffentliche CVE-Akte deckte dabei nur einen Teilpfad ab, während die resumable-mode Variante separat in den Release-Notes behandelt wurde.
Vercel: „Relay“-Autorisierung fiel auf Sandbox-Code herein
Bei Vercel lag der Schwerpunkt auf der Harness-Relay-Logik. Betroffen waren @ai-sdk/harness-codex (CVE-2026-64650) sowie @ai-sdk/harness-opencode (CVE-2026-64651). Beide wurden mit CVSS v4.0: 6.3 bewertet.
Die Relay-Komponente vertraute bei der Tool-Weitergabe auf einen Prozesspfad, der in der Command Line des Runtimes enthalten war. Der Angreifer musste allerdings keine entfernte Request-Manipulation in derselben Form nachstellen: Für die Ausnutzung war lokaler Code innerhalb einer Linux-Sandbox erforderlich, der bereits lief – etwa durch einen bösartigen Dependency-Tree, Build-Skripte oder Lifecycle-Hooks.
Dieser Sandbox-Code konnte dann die Prüfung für den Prozesspfad erfüllen und host-exponierte Tools anstoßen. Dazu zählten laut Beschreibung auch Aktionen wie geheime Abfragen, Deployments und Cloud-API-Aufrufe – allerdings nur, wenn solche Tools im Harness bereits vorhanden waren.
Der Patch ersetzte das Prozesspfad-Vertrauen durch eine engere Bindung: Die Relay akzeptierte Aufträge nur noch, wenn sie zu einer kurzlebigen, einmaligen Autorisierung passten, die wiederum an ein beobachtetes Modellereignis gekoppelt war. Zusätzlich erwähnte der Bericht, dass weitere Härtungen schon früher gelandet waren, unter anderem gegen client-forged Approvals und mit neuem Design für Tool-Approval-Mechanismen.
Gemeinsame Erkenntnis: Autorisierung gehört in die Tool-Ausführung
Unabhängig von AWS, Google und Vercel verdichten sich die Maßnahmen zu einem Steuerprinzip: Agent-Fehler Tools ohne Modellaufruf entstehen dort, wo die Laufzeit die Gestalt von Eingabedaten als ausreichende „Begründung“ für Tool-Aufrufe interpretiert. Systemprompts oder reine Modellantworten helfen dann nicht mehr, weil der Modellturn im angreifbaren Pfad gar nicht passiert.
Die drei konkreten Gegenmaßnahmen laufen konzeptionell zusammen:
- Google: Bestätigung muss gegen Tool und Argumente geprüft werden, die in der Session dokumentiert sind.
- Vercel: Relay-Anfragen werden an eine one-time Autorisierung gebunden, die an ein beobachtetes Modellereignis geknüpft ist.
- AWS: Tool-Use-Blocks aus dem Caller-Kontext werden vor dem Event-Loop-Dispatch serverseitig verworfen.
Damit verschwindet der Kernfehler: Nicht die „Form“ der eingehenden Daten entscheidet über Toolzugriff, sondern das nachweisbare Zustandekommen über den korrekten Modell- und Autorisierungsablauf.
Was Sie jetzt praktisch tun sollten
Die Berichte nennen mehrere konkrete Schritte, die über die Hersteller-Patches hinaus im eigenen Agent-Setup sinnvoll sind:
- Betroffene Bibliotheken aktualisieren: Für Google ADK für Python mindestens 2.5.0. Für die Vercel Harness-Pakete entsprechend @ai-sdk/harness-codex ab 1.0.29 sowie @ai-sdk/harness-opencode ab 1.0.28.
- Caller-authored Tool-Aufrufe als untrusted behandeln: Gesprächshistorien, resumable Events, bestätigungsbezogene Rückmeldungen und strukturierte Tool-Use-Blöcke sollten als potenziell manipuliert gelten, sobald sie eine externe Grenze überschreiten.
- Autorisierung erst beim Ausführen verifizieren: Jeder Toolaufruf sollte an den exakten Modell-Event, Toolname, Argumente, Session-Kontext und den Zustand der Autorisierung gekoppelt sein.
- Inherited Authority reduzieren: Geben Sie Agenten nur die Tools, Cloud-Rollen, Credentials und Schreibrechte, die für die konkrete Aufgabe wirklich nötig sind.
Zusätzlich ist es ratsam, Ihre Agentenlogik auf den Umgang mit „letzten Nachrichten“, Resume-Mechanismen und Tool-Dispatch-Shortcuts zu prüfen. Genau solche Übergänge sind in den beschriebenen Pfaden der Hebel.
Fazit
Die gemeldeten Vorfälle verdeutlichen, dass Agent-Fehler Tools ohne Modellaufruf ein strukturelles Risiko darstellen können: Wenn das Agenten-Runtime Toolcalls akzeptiert, ohne den korrekten Modell- und Autorisierungskontext nachzuweisen, reichen gefälschte oder injizierte Daten bis in die Ausführung. AWS, Google und Vercel haben jeweils gepatcht und ihre Prüfungen verschärft – die übergreifende Lehre bleibt jedoch: Tool-Autorisierung muss überprüfbar und zum Ausführungsvorgang selbst verankert sein.
Quelle: https://thehackernews.com/2026/08/aws-google-and-vercel-patch-agent-flaws.html
