TrapDoor: Über Nacht sind 34 Pakete verdorben, eine 3-Tage-Regel hätte das verhindert

Ende Mai 2026 deckten Sicherheitsforscher eine Supply-Chain-Kampagne auf, die später unter dem Namen TrapDoor bekannt wurde. Mehr als 34 bösartige Pakete erschienen fast zur gleichen Zeit auf PyPI, npm und Crates.io. Sie waren nicht kaputt oder fehlerhaft. Sie waren gebaut, um in dem Moment bösartigen Code auszuführen, in dem man sie installierte oder importierte. Dabei griffen sie SSH-Schlüssel und Anmeldedaten vom Rechner ab und schickten sie an die Angreifer (berichtet von The Hacker News , 25. Mai 2026).

Falls Du Dich je gefragt hast, warum es die 5bats-Tools gibt: Das ist die kurze Antwort. TrapDoor ist der Angriff, als Reaktion auf den das Toolset entstand. Und das Unangenehme daran ist, wie gewöhnlich er war. Kein zero-day, kein raffinierter Exploit. Nur Pakete, ganz normal veröffentlicht, die ein ganz normaler Installationsbefehl direkt auf die Rechner der Entwickler holte.

Was auf dem Rechner wirklich passierte

Stell Dir den Ablauf aus Sicht der Entwicklerin vor. Du installierst ein Paket, das Du brauchst, oder ein Update für eines, das Du schon nutzt. Der Paketmanager lädt es und führt sein Setup aus. In diesem Setup, auf einem ganz normalen Laptop oder Build-Server, erledigen ein paar zusätzliche Zeilen ihre Arbeit. Sie suchen nach den Dateien, die eine Entwicklerin fast immer hat: den privaten SSH-Schlüssel in ~/.ssh, die Cloud-Tokens in den Umgebungsvariablen, die von anderen Tools zwischengespeicherten Anmeldedaten. Sie schicken still und leise Kopien an einen Server, den der Angreifer kontrolliert. Kein Fenster geht auf. Die Installation endet und meldet Erfolg. Du machst mit der nächsten Sache weiter.

Der Diebstahl ist da schon passiert und nichts auf dem Bildschirm sagt es Dir. So sah jedes Paket im TrapDoor-Set aus: kein Fehler, der später ausgelöst wird, sondern eine Handlung, die während der Installation abgeschlossen wird.

Wie konnte das durchrutschen?

Hier ist das entscheidende Detail: Als die Forscher es entdeckten, war jedes einzelne der bösartigen PyPI-Pakete weniger als 72 Stunden alt. Das ist kein Zufall. Das ist die ganze Strategie. Eine brandneue release lebt in einem toten Winkel. Die Sicherheitsdatenbanken, gegen die Tools prüfen, kennen sie noch nicht, also gibt es kein CVE, keine Sicherheitswarnung, nichts zum Anschlagen. Bis das Ökosystem aufholt und das Paket entfernt, ist es längst auf jedem Rechner gelaufen, der es in diesen ersten Stunden installiert hat.

Deshalb hilft der übliche Ratschlag, „scanne Deine dependencies auf bekannte Schwachstellen", hier nicht. Es gab nichts Bekanntes, wonach man hätte suchen können. Und Post-Install-Scanner laufen, nachdem der Code des Pakets bereits ausgeführt wurde, was bei einem Angriff, der schon bei der Installation zündet, viel zu spät ist. Die Verteidiger waren nicht langsam oder nachlässig. Sie spielten ein Spiel, in dem der Angreifer zuerst zieht und die Anzeigetafel zuletzt aktualisiert wird.

Der zweite Trick: Dein Assistent wird gegen Dich gewendet

TrapDoor hatte einen zweiten Trick, bei dem es sich zu verweilen lohnt, weil er zeigt, wohin die Reise geht. Manche payloads versteckten verborgene Anweisungen in CLAUDE.md- und .cursorrules-Dateien, also der Konfiguration, die KI-Programmierassistenten steuert. Für sich genommen tut das nichts. Aber sobald die Entwicklerin ihren Assistenten das nächste Mal öffnete, las er diese Dateien als vertrauenswürdige Projektanweisungen und handelte danach: holte weiteren Code, gab weitere Geheimnisse preis oder schwächte still eine Schutzmaßnahme. Und das alles, während es aussah, als täte er, was die Entwicklerin wollte.

TrapDoor war also zugleich ein Supply-Chain-Angriff und ein Prompt-Injection -Angriff. Der erste Einbruch stahl Anmeldedaten. Der zweite machte Deine eigenen Tools beim nächsten Durchlauf zum Komplizen. Je mehr wir KI-Assistenten erlauben, in unserem Namen Dinge zu installieren und auszuführen, desto weniger ist diese Kombination eine Kuriosität und desto mehr wird sie zur Hauptsache.

Was hätte das verhindert?

Genau darum geht es bei so einer Rückschau. Nicht, um Angst zu schüren, sondern um zu zeigen, dass die Verteidigung unspektakulär und wirksam ist.

• Ein freshness hold. pip-cve-gate weigert sich standardmäßig, eine release zu installieren, die jünger als drei Tage ist. Gegen TrapDoor ist diese eine Regel entscheidend: jedes bösartige PyPI-Paket lag in diesem Zeitfenster, also wären sie schlicht blockiert worden, ohne CVE, ohne dass man etwas hätte nachschlagen müssen. Die größte Stärke des Angriffs, seine Neuheit, ist genau das, was ein freshness hold in eine Schwäche verwandelt. Du wartest drei Tage, die Menge findet die schlechte release und Du ziehst sie nie.
• Eine Prüfung vor der Installation, keine danach. Weil das gate vor der Installation läuft, bekommt der bösartige Code seinen Moment nie. Ein Scanner, der ein Problem meldet, nachdem das Setup-Skript gelaufen ist, schreibt den Vorfallsbericht, nicht seine Verhinderung. Dasselbe Prinzip deckt Composer und Homebrew ab. Für die Pakete, die ein KI-Assistent für Dich installiert, gibt es claude-code-cve-gate .
• Eine Grenze zwischen Lesen und Ausführen. Für den CLAUDE.md-Trick sperrt claude-code-prompt-injection-gate die Dateien, die ein Angreifer umschreiben möchte, sodass ein manipuliertes Paket Deinen Assistenten nicht unbemerkt umprogrammieren kann. Diese Dateien zum Kontext zu lesen, ist in Ordnung. Einem ungeprüften Paket zu erlauben, sie zu bearbeiten, nicht.

Warum das immer wieder passiert

Man sollte ehrlich sein, warum Angriffe wie TrapDoor leicht durchzuführen sind. Öffentliche Registries sind bewusst offen. Jeder kann veröffentlichen. Updates erscheinen sofort und weltweit. Und Millionen Rechner sind so eingestellt, dass sie automatisch die neueste Version ziehen. Diese Offenheit macht das open-source-Ökosystem produktiv und ist zugleich die Angriffsfläche. Du kannst sie nicht schließen, ohne genau das kaputtzumachen, was sie nützlich macht.

Was Du ändern kannst, ist Deine eigene Voreinstellung: brandneuen releases nicht auf den ersten Blick vertrauen und prüfen, bevor Du ausführst, statt danach. TrapDoor brauchte keinen Fehler in einer dieser Registries. Es nutzte sie einfach so, wie sie gedacht sind, nur schneller, als irgendjemand reagieren konnte.

Das Fazit

TrapDoor war nicht der erste Angriff seiner Art und wird nicht der letzte sein. Das ist die eigentliche Lehre. Du kannst Dich nicht darauf verlassen, rechtzeitig gewarnt zu werden, denn die gefährlichsten Pakete sind die, vor denen noch niemand gewarnt hat. Eine feste Regel, die einfach ein paar Tage wartet und vor der Installation prüft, braucht die Warnung nicht. Das ist der Unterschied zwischen der Abwehr bereits bekannter Angriffe und der Abwehr des nächsten.

Die ausführliche Erklärung, wie diese Angriffe funktionieren, findest Du im Leitfaden zu Software-Supply-Chain-Angriffen .