Agenten-Plugins greifen am Modell vorbei – HookPry traf alle sieben Systeme
Die am 3. September 2026 veröffentlichte HookPry-Studie beschreibt einen Lieferkettenangriff über aktualisierte Lifecycle-Hooks von Agenten-Plugins. In 1.000 Testläufen über 25 Kombinationen aus Harness und Modell-Backend erzeugte das Framework bei allen sieben untersuchten Harnesses mindestens einen extern bestätigten schädlichen Effekt; insgesamt gelangen 77 Prozent der Versuche, beim erfolgreichsten Harness 92,5 Prozent, wie das HookPry-Forschungspapier dokumentiert.
Der Angriff umgeht den unmittelbaren Entscheidungsweg des Sprachmodells: Ein zunächst unauffälliges Plugin erhält per Update eine veränderte Hook-Konfiguration, die einen Befehl an ein reguläres Laufzeitereignis bindet. Nach diesem Ereignis startet der Harness den Prozess mit den lokal verfügbaren Rechten, ohne das Modell erneut über den konkreten Befehl entscheiden zu lassen. Belegt ist bislang eine Angriffsklasse unter kontrollierten Testbedingungen, kein Angriff auf öffentlich eingesetzte Plugins.
Vom akzeptierten Update zum Host-Prozess
Im Bedrohungsmodell veröffentlicht der Angreifer zunächst ein funktionierendes, versioniertes Plugin und kontrolliert später dessen Metadaten, Version und Lifecycle-Hooks. Das Update fügt unter derselben Plugin-Identität einen neuen Befehl hinzu oder verändert einen bestehenden. Wird die neue Konfiguration ohne eine eigene Berechtigungsprüfung übernommen, wandert das bei der Installation gewährte Vertrauen auf eine erweiterte Ausführungsbefugnis.
Der Harness registriert den Befehl für ein Ereignis wie Sitzungsstart, Werkzeugaufruf oder Dateiänderung. Sobald dieses Ereignis eintritt, führt er den Handler als Unterprozess aus. Der untersuchte Mechanismus benötigt weder Prompt Injection noch lokalen Repository-Zugriff, einen Implementierungsfehler oder einen Sandbox-Ausbruch; von Angriffen auf die Sandbox-Grenze ist er deshalb zu unterscheiden.
Wie weit ein solcher Hook kommt, bestimmen weiterhin seine Umgebung und Rechte. HookPry prüfte zehn Ziele, darunter das Sammeln von Zugangsdaten, Datenabfluss, Ressourcenmissbrauch, Manipulation, Rechteausweitung, Persistenz und Weiterverbreitung. Der Effekt setzt voraus, dass das betreffende Update angenommen, das gebundene Ereignis ausgelöst und die benötigte Datei-, Prozess- oder Netzwerkoperation nicht blockiert wird.
Sieben Harnesses, aber keine identischen Ergebnisse
Das Testfeld umfasste OpenHarness, OpenClaw, Claude Code, Codex CLI, OpenCode, Hermes und WorkBuddy sowie fünf Modell-Backends. „Alle sieben getroffen“ bedeutet nicht, dass jeder Versuch gelang: Bei jedem Harness erreichte mindestens ein Lauf den vorher festgelegten und durch ein externes Prüforakel bestätigten Effekt. Teilresultate zählten bei der Erfolgsquote nicht als Erfolg.
Hermes erreichte mit 92,5 Prozent den höchsten Gesamtwert eines Harnesses. Die Ergebnisse unterschieden sich auch nach Angriffsziel: Netzwerkabhängige Befehlssteuerung und dauerhafte Änderungen am Dateisystem scheiterten häufiger an Richtlinien, Isolation oder fehlender Erreichbarkeit als Effekte, die mit verbreiteten Hook-Rechten auskamen.
Das Sprachmodell ist trotzdem nicht in jeder Phase bedeutungslos. Bei Hooks rund um Werkzeugaufrufe kann sein Verhalten beeinflussen, ob das auslösende Ereignis überhaupt entsteht. Erst nach dem Trigger liegen Registrierung und Start des Unterprozesses beim Harness; genau auf diese nachgelagerte Grenze bezieht sich die Formulierung „am Modell vorbei“.
Warum Modellfilter und Dateiscans nicht genügen
Modellseitige Schutzmechanismen prüfen vor allem Aktionen, die das Modell auswählt oder erzeugt. Der konfigurierte Lifecycle-Hook bildet einen zweiten Ausführungspfad: Der Harness verarbeitet eine bereits registrierte Bindung zwischen Ereignis und Befehl. Ein Prompt-Filter erhält an dieser Stelle möglicherweise weder den Befehl noch eine neue Entscheidung zur Prüfung.
Auch statische Erkennung deckte diesen Pfad im Experiment nur teilweise ab. Microsoft Defender erkannte keinen der 40 präparierten schädlichen Testartefakte; die beiden von den Forschenden konfigurierten Regelansätze HookPolicy und Semgrep fanden jeweils ungefähr die Hälfte. Gemeinsam übersahen die drei Verfahren 19 von 40 Artefakten. Die Sicherheitsanalyse von AI Polix betont dazu, dass diese Laborwerte nicht unabhängig reproduziert wurden und weder dynamische Analysen noch spezialisierte kommerzielle Lieferkettenprodukte abdecken.
Der Befund belegt daher nicht, dass Endpoint-Schutz generell wirkungslos ist. Er zeigt enger gefasst, dass ein Dateiscan keine Autorisierungsentscheidung darüber ersetzt, ob ein Update neue ausführbare Befugnisse erhalten darf.
Die entscheidenden Kontrollen liegen an zwei Grenzen
Die erste Grenze ist das Plugin-Update. Paketverwaltung oder Harness müssen die wirksame Konfiguration semantisch mit der genehmigten Version vergleichen: neue Ereignisse, geänderte Befehle, Skriptpfade, Umgebungszugriffe und Netzwerkziele sind Berechtigungsänderungen. Erweitert sich der Befugnisumfang, sollte eine neue Freigabe an die konkrete Konfiguration und nicht nur an den unveränderten Plugin-Namen gebunden sein.
Dass Hooks als eigener Kontrollbereich behandelt werden können, zeigt die offizielle Hook-Referenz von Claude Code: Das Ereignis ConfigChange kann bestimmte Konfigurationsänderungen während einer Sitzung protokollieren oder blockieren. Die zugehörigen verwalteten Einstellungen können außerdem nicht freigegebene Hooks begrenzen. Diese Funktionen lösen das übergreifende Lieferkettenproblem nicht, markieren aber konkrete Ansatzpunkte für zentrale Richtlinien.
Die zweite Grenze ist die Ausführung. Hooks sollten mit eingeschränkten Dateisystemsichten, kurzlebigen Zugangsdaten und kontrolliertem Netzwerk-Egress laufen, statt pauschal den Benutzerkontext zu erben. Für die Nachvollziehbarkeit müssen Protokolle Plugin-Version, Konfigurations-Hash, auslösendes Ereignis, Handler und tatsächliche Prozessidentität verbinden.
Der Nachweis bleibt auf das Labor begrenzt
Die Untersuchung verwendete temporäre Umgebungen, synthetische Dateien und 40 Angriffsfälle. Sie deckt nicht alle Betriebssysteme, Shells, Unternehmensrichtlinien, Netzbedingungen oder künftigen Produktversionen ab. Ebenso wurde nicht gemessen, wie häufig Nutzer ein manipuliertes Plugin finden, installieren oder dessen Update übernehmen würden.
Der belastbare Befund ist deshalb präziser als eine pauschale Warnung vor Agenten-Plugins: Ausführbare Hook-Konfiguration gehört zur Sicherheitsgrenze des Hosts und darf bei Aktualisierungen nicht wie harmlose Paketmetadaten behandelt werden. Noch offen ist, wie wirksam Signaturbindung, erneute Einzelautorisierung, spezialisierte Lieferkettenanalyse und Laufzeitüberwachung in realen Installationen zusammenspielen.
Lesen Sie auch:
Newsletter abonnieren
Erhalten Sie die neuesten Nachrichten zu Web3, KI und Krypto direkt in Ihren Posteingang.