ChainDrop: Was PatchPilot geblockt hätte — und was nicht

Am 4. August 2026 kaperte der ChainDrop-Worm — ein Nachfolger von Shai-Hulud — den Maintainer-Account hinter keyv, cacheable, flat-cache und file-entry-cache und schob frisch veröffentlichte Versionen mit einem "preinstall": "node setup.mjs"-Dropper in über 400 Pakete mit zusammen mehr als einer Milliarde monatlicher Downloads. Die Payload stahl npm-, GitHub-, AWS- und AI-Tool-Credentials und pflanzte Persistenz-Hooks in .vscode/tasks.json und .claude/settings.json.

Der letzte Teil verdient einen zweiten Blick: Der Worm verankert sich in den Claude-Settings. Er zielt explizit auf Menschen, die mit AI-Agenten programmieren. Während die bösartigen Versionen live waren, existierte kein einziges CVE.

Ich baue PatchPilot, einen Claude-Code-Hook, der Pakete prüft, bevor der Agent sie installiert. Die naheliegende Frage — die ich jedem Anbieter eines Security-Tools nach so einem Vorfall stellen würde — lautet: Hätte es diesen Angriff wirklich erkannt?

Security-Tools, die zu viel versprechen, sind gefährlich. Also habe ich es getestet — und veröffentliche das vollständige Ergebnis, inklusive des unbequemen Teils.

Der Test

Ich habe den Registry-Zustand von npm aus dem Angriffsfenster rekonstruiert — keyv@6.0.0 als latest getaggt, zwei Stunden alt, mit dem preinstall-Hook des Worms — und ihn durch PatchPilots unveränderten Produktionscode geschickt. Das Ergebnis:

DECISION: deny
Just-published version that runs install scripts — possible compromised release.
keyv@6.0.0 was published 2 hours ago (within 72h quarantine window).
Consider using keyv@5.6.0 instead.

Harter Block. Die Kombinationsregel aus Versions-Quarantäne und Install-Script-Erkennung — gebaut nach dem Axios-Angriff im März 2026, ausgeliefert seit v0.4.0 — feuert bei ChainDrop identisch: innerhalb des Zero-Day-Fensters, bevor irgendein OSV-Advisory existierte. Sie braucht kein CVE, weil sie nicht nach bekannter Bösartigkeit sucht, sondern nach der Form eines kompromittierten Releases: eine Version, die wenige Stunden alt ist und bei der Installation Code ausführt.

Das Szenario ist inzwischen ein permanenter Regressionstest im Repo (src/chaindrop.test.ts, seit v0.5.0). Der Test rekonstruiert die Registry-Metadaten relativ zur Test-Uhr, damit die 72-Stunden-Quarantäne-Bedingung an jedem Ausführungsdatum reproduzierbar bleibt.

Der ehrliche Geltungsbereich

Hier ist die Aussage, exakt so, wie ich sie auf jedem Kanal treffe:

PatchPilot hätte den Direct-Install-Vektor von ChainDrop im Zero-Day-Fenster geblockt. Der transitive Pfad ist noch nicht abgedeckt — und hier ist der Plan dafür.

Drei Dinge gehören unter diesen Satz.

Was es blockt: den direkten Vektor — npm install keyv (oder jedes betroffene Paket, gepinnt oder nicht), solange die bösartige Version live ist, plus das Blocken bekannter Malware via OSV, sobald MAL-*-Advisories eintreffen.

Was die Validierung aufgedeckt hat: npm update keyv lief in v0.4.0 komplett am Parser vorbei — und Updates waren ChainDrops wichtigster direkter Vektor. v0.4.0 hat Update-Kommandos schlicht nicht geprüft. Genau diese Art von Loch findet man nur, wenn man einen echten Angriff gegen das eigene Tool nachspielt, statt die eigene Feature-Liste zu bewundern. Ab v0.5.0 gefixt: npm/pnpm update|up|upgrade, yarn upgrade|up, bun update und poetry update werden wie Installationen geprüft, mit Regressionstests.

Was es nicht abdeckt, in keiner Version: transitive Abhängigkeiten — bei ChainDrop der dominante Infektionspfad. Zwei unterschiedliche Fälle: npm install und npm update lösen Semver-Ranges neu auf und können eine frisch vergiftete transitive Version ziehen, die PatchPilot nie zu sehen bekommt (ein nacktes npm install nennt überhaupt keine Pakete). npm ci installiert nur die exakt im Lockfile festgehaltenen Versionen — zieht also kein neues Gift herein, installiert aber treu eine kompromittierte Version, die dort bereits steht. Die Design-Evaluation, um diese Lücke zu schließen (Lockfile-Diff-Prüfung), liegt seit v0.5.0 im Repo (plans/transitive-dependency-coverage.md). Und: PatchPilot schützt Claude-Code-Sessions — nicht das freie Terminal und nicht die CI.

Warum das mit AI-Agenten mehr zählt

Ein Angriff, der Persistenz-Hooks in .claude/settings.json pflanzt, zielt auf genau die Menschen, für die PatchPilot existiert. Die Ökonomie des agentischen Programmierens schneidet in beide Richtungen: Der Agent installiert Pakete in Maschinengeschwindigkeit — also installiert er auch ein zwei Stunden altes, kompromittiertes Release in Maschinengeschwindigkeit, ohne das kurze Zögern, das ein Mensch vor einer heute Morgen veröffentlichten Dependency vielleicht hätte.

Das ist das Argument für ein deterministisches Gate vor dem Agenten. Kein schlaueres Modell, keine Policy im Prompt — ein Pre-Execution-Hook, der jedes Mal dieselben Prüfungen fährt, sich nicht überreden lässt und geschlossen ausfällt, wenn seine Datenquelle down ist.

Was in v0.5.0 steckt

• Update-Kommandos werden wie Installationen geprüft — der Bypass ist geschlossen, durch den ChainDrops wichtigster direkter Vektor marschiert wäre
• Die ChainDrop-Regressionssuite — das Angriffsfenster ist jetzt ein permanenter Test; diese Schutzklasse kann nicht mehr still regressieren
• Der Transitive-Coverage-Plan — Evaluation abgeschlossen, Lockfile-Diff-Prüfung als Ansatz gewählt, Umsetzung für das nächste Minor-Release geplant

Wenn dein AI-Agent Pakete installiert, stell ihm ein Gate vor die Tür:

npm install -g patchpilot

Quellen zu den Angriffsfakten: Microsoft Security Blog, Elastic Security Labs, Datadog Security Labs, StepSecurity.