HookPry kapert alle sieben getesteten KI-Agenten-Frameworks
Das am 3. September 2026 eingereichte HookPry-Preprint meldet 770 erfolgreiche Angriffe in 1.000 Laborläufen über sieben KI-Agenten-Harnesses, fünf Modell-Backends und 25 getestete Kombinationen. Damit lag die mikro-gemittelte Erfolgsrate bei 77,0 Prozent; jedes der sieben Systeme zeigte mindestens einmal einen extern überprüften schädlichen Effekt. Eine am 6. September veröffentlichte Einordnung von AI Polix bestätigt den berichteten Versuchsrahmen, weist aber darauf hin, dass die Messwerte autorengemeldet und noch nicht unabhängig reproduziert sind.
Der Befund vom 3. September rechtfertigt das starke Verb „kapert“ nur innerhalb dieses Laborszenarios. Er bedeutet weder, dass sieben Produkte denselben Programmfehler enthalten, noch dass beliebige Installationen aus der Ferne übernommen werden können. Untersucht wurde ein gemeinsamer Lieferkettenpfad: Ein zunächst unauffälliges Plugin erhält später ein Update, das neue oder veränderte Lifecycle-Hooks an reguläre Ereignisse der Agentensitzung bindet.
Der Hook führt Befehle neben dem Modellpfad aus
Lifecycle-Hooks automatisieren Aktionen an festgelegten Punkten, etwa beim Sitzungsstart, vor oder nach einem Werkzeugaufruf oder nach einer Konfigurationsänderung. Sobald Ereignis und Filter zusammenpassen, kann der jeweilige Agenten-Harness den hinterlegten Handler starten. Das Sprachmodell muss diesen konkreten Befehl dann weder neu auswählen noch beurteilen.
Die Hook-Dokumentation von Claude Code beschreibt dafür automatisch ausgelöste Shell-Befehle, HTTP-Aufrufe, MCP-Werkzeuge, Modell-Prompts und Subagenten; Plugin-Hooks können gemeinsam mit einer Erweiterung bereitgestellt werden. Sie dokumentiert zugleich ein Ereignis namens ConfigChange, mit dem bestimmte Konfigurationsänderungen während einer Sitzung protokolliert oder blockiert werden können. Das ist eine konkrete Produktsemantik, keine Aussage darüber, dass alle sieben untersuchten Systeme Hooks identisch laden oder absichern.
HookPry nutzt die zeitliche Trennung zwischen Vertrauensentscheidung und späterer Ausführung. Nach dem Bedrohungsmodell veröffentlicht der Angreifer zunächst eine funktionsfähige Plugin-Version und kontrolliert anschließend Metadaten, Versionierung und Hook-Konfiguration eines Updates. Er kann die Installation nicht erzwingen, benötigt weder Prompt-Injection noch Zugriff auf das lokale Projekt und muss auch nicht aus einer Sandbox ausbrechen. Der Angriff wird erst wirksam, wenn das Update angenommen, ein passendes Ereignis ausgelöst und der Hook mit ausreichenden Rechten ausgeführt wird.
77 Prozent messen die Laborwirkung, nicht jedes Produkt gleich
Die 77,0 Prozent bezeichnen den Anteil vollständig bestätigter Ende-zu-Ende-Effekte über alle 1.000 Versuche. Teilresultate zählten nicht als Erfolg. Die Werte der einzelnen Harnesses unterschieden sich deutlich: Der höchste Gesamtwert lag bei 92,5 Prozent, während einzelne Angriffskategorien und Konfigurationen erheblich schlechter abschnitten.
Damit belegt die Studie einen über mehrere Implementierungen tragfähigen Architekturpfad, aber keine einheitliche Schwachstelle mit identischen Voraussetzungen. Ereignisnamen, Konfigurationsformate, Update-Verfahren, Bestätigungsdialoge, Netzwerkregeln und Prozessrechte unterscheiden sich. Auch das Modell-Backend kann beeinflussen, ob ein modellabhängiges Ereignis überhaupt eintritt; nach dem Auslösen übernimmt jedoch der Harness die Bindung und Ausführung des registrierten Befehls.
Die Formulierung „alle sieben“ bedeutet deshalb präzise: OpenHarness, OpenClaw, Claude Code, Codex CLI, OpenCode, Hermes und WorkBuddy erzeugten in der beschriebenen Versuchsanordnung jeweils mindestens einen erfolgreichen, durch einen externen Prüfmechanismus bestätigten Effekt. Sie bedeutet nicht, dass jeder Angriff gegen jedes System gelang oder dass die durchschnittliche Produktionswahrscheinlichkeit 77 Prozent beträgt.
Die reale Eintrittswahrscheinlichkeit bleibt unbekannt
Die Experimente fanden in kurzlebigen Testumgebungen mit synthetischen Dateien und vorgegebenen Prüfpunkten statt. Sie deckten 40 Angriffsfälle ab, aber nicht sämtliche Betriebssysteme, Shells, Produktversionen, Unternehmensrichtlinien und Netzwerkbedingungen. Reale Zugangsdaten oder Nutzerdaten wurden nach Darstellung der Forschenden nicht eingesetzt.
Vor allem misst HookPry nicht, wie häufig ein manipuliertes Plugin gefunden, installiert oder später aktualisiert würde. Das Bedrohungsmodell setzt die Annahme des Updates voraus; ebenso müssen das gebundene Ereignis eintreten und die Rechte des gestarteten Unterprozesses für das Angriffsziel ausreichen. Diese drei Bedingungen trennen die demonstrierte technische Wirkung von der bislang unbekannten Wahrscheinlichkeit eines realen Vorfalls.
Öffentlich belegt ist daher eine Angriffsklasse, keine laufende Angriffswelle. Es gibt bislang weder eine unabhängige Wiederholung der Erfolgsraten noch einen Nachweis, dass HookPry in verbreiteten Plugin-Marktplätzen gegen reale Nutzer eingesetzt wurde. Auch herstellerspezifische Reaktionen oder abgeschlossene Fehlerbehebungen sind noch nicht für alle sieben Harnesses dokumentiert.
Kontrollen müssen die neue Hook-Autorität sichtbar machen
Die zentrale Schutzmaßnahme liegt am Übergang vom alten zum neuen Plugin-Zustand. Signaturen und festgeschriebene Hashes können Herausgeber, Paketversion und ausgeliefertes Artefakt miteinander verbinden. Sie reichen allein aber nicht aus: Ein kompromittierter Herausgeber könnte einen schädlichen Stand korrekt signieren. Zusätzlich muss deshalb die effektive Hook-Konfiguration vor und nach einem Update verglichen werden.
Ein solcher semantischer Vergleich sollte neue Ereignisbindungen, veränderte ausführbare Befehle, zusätzliche Skriptpfade, Netzwerkziele und Zugriffe auf sensible Umgebungsvariablen hervorheben. Erweitert ein Update die ausführbare Autorität, sollte die Freigabe erneut und bezogen auf diese konkrete Differenz erfolgen. Eine pauschale Zustimmung zum unveränderten Plugin-Namen beantwortet nicht, welche Befehle die neue Version tatsächlich ausführen darf.
Bestätigungsdialoge sind nur belastbar, wenn sie den aufgelösten Befehl und die betroffenen Ressourcen verständlich anzeigen. Für unbeaufsichtigte Systeme lässt sich dieselbe Entscheidung als Richtlinie abbilden, die unerwartete Hook-Änderungen blockiert oder einer manuellen Prüfung zuführt. Protokolle sollten mindestens Plugin-Version, Konfigurationshash, auslösendes Ereignis, gestarteten Handler und Ausführungsidentität festhalten.
Eine zweite Schutzschicht begrenzt die Folgen nach einer Fehlfreigabe: Hooks sollten mit minimalen Betriebssystemrechten, eingeschränkter Dateisicht, kontrolliertem Netzwerkzugang und kurzlebigen Zugangsdaten laufen. Der aktuelle Stand bleibt damit zweigeteilt: HookPry hat den Lieferkettenpfad in allen sieben getesteten Harnesses erfolgreich aktiviert, doch das Ausmaß außerhalb des Labors ist offen. Entscheidend werden unabhängige Reproduktionen, produktspezifische Korrekturen und Tests unter realen Unternehmensrichtlinien sein.
Lesen Sie auch:
Newsletter abonnieren
Erhalten Sie die neuesten Nachrichten zu Web3, KI und Krypto direkt in Ihren Posteingang.