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

Ende Mai 2026 deckten Sicherheitsforscher eine supply chain-Kampagne auf, die unter dem Namen TrapDoor bekannt wurde. Mehr als 34 bösartige Pakete wurden ungefähr zur gleichen Zeit auf PyPI, npm und Crates.io veröffentlicht. Sie waren weder fehlerhaft noch defekt – sie waren so programmiert, dass sie unmittelbar nach der Installation oder dem Import bösartigen Code ausführten, SSH-Schlüssel und Anmeldedaten vom Rechner abgriffen und an die Angreifer sendeten (berichtet von The Hacker News](https://thehackernews.com/2026/05/trapdoor-supply-chain-attack-spreads.html) , 25. Mai 2026).

Falls Du Dich schon mal gefragt hast, warum es die 5bats-Tools gibt, hier ist die kurze Antwort: TrapDoor ist der Angriff, als Reaktion auf den das Toolset entwickelt wurde – und das Beunruhigende daran ist, wie alltäglich er war. Kein zero-day, kein raffinierter Exploit. Nur ganz normale, regulär veröffentlichte Pakete, die durch einen gewöhnlichen Installationsbefehl direkt auf die Rechner der Entwickler geladen wurden.

Wie konnte das durchrutschen?

Hier ist das entscheidende Detail: Als die Forscher sie 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 befindet sich in einer Sicherheitslücke. Die Sicherheitsdatenbanken, gegen die Tools prüfen, haben sie noch nicht erfasst, daher gibt es kein CVE, keine Sicherheitswarnung, nichts, was darauf hinweisen könnte. Bis das Ökosystem aufholt und das Paket entfernt, ist es bereits auf jedem Rechner gelaufen, auf dem es in diesen ersten Stunden installiert wurde.

Deshalb hilft der übliche Ratschlag – „Überprüfe Deine Abhängigkeiten auf bekannte Schwachstellen“ – hier nicht weiter. Es gab nichts Bekanntes, wonach man hätte suchen können. Und Scanner, die nach der Installation laufen, werden erst ausgeführt, nachdem der Code des Pakets bereits ausgeführt wurde – was bei einem Angriff, der schon bei der Installation ausgelöst wird, viel zu spät ist.

TrapDoor hatte noch einen zweiten erwähnenswerten Trick auf Lager: Einige payloads schmuggelten versteckte Anweisungen in CLAUDE.md- und .cursorrules-Dateien – also in die Konfiguration, die KI-Programmierassistenten steuert –, wodurch der Assistent selbst beim nächsten Durchlauf zum Komplizen wurde. Es handelte sich also sowohl um einen supply chain Angriff als auch um einen prompt injection -Angriff].

Was hätte das verhindern können?

Genau darum geht es bei so einer Zusammenfassung – nicht, um Angst zu schüren, sondern um zu zeigen, dass die Verteidigung zwar nicht besonders glamourös, aber effektiv ist.

• Ein freshness hold. pip-cve-gate weigert sich standardmäßig, eine release zu installieren, die jünger ist als drei Tage. Bei TrapDoor ist genau diese eine Regel entscheidend: jedes bösartige PyPI-Paket befand sich in diesem Zeitraum, also wären sie sofort blockiert worden – ganz ohne CVE, da gab’s nichts nachzuschlagen. Die größte Stärke des Angriffs, Gerade diese Neuheit ist es, die eine Stärke in eine Schwäche verwandelt.
• Eine Überprüfung vor der Installation, keine nach der Installation. Da das gate vor der Installation ausgeführt wird, wird der schädliche Code kommt nie dazu, ausgeführt zu werden. Das gleiche Prinzip gilt für Composer und Homebrew und – für die Pakete, die ein KI-Assistent für Dich installiert – claude-code-cve-gate .
• Eine Grenze zwischen Lesen und Laufen. Für den CLAUDE.md-Trick, claude-code-prompt-injection-gate sperrt die Dateien, auf die ein Angreifer es abgesehen hätte, Umschreiben, damit ein manipuliertes Paket Deinen Assistenten nicht unbemerkt umprogrammieren kann.

Das Fazit

TrapDoor war nicht der erste Angriff dieser Art und wird auch nicht der letzte sein – das ist die eigentliche Lehre daraus. Man kann sich nicht darauf verlassen, rechtzeitig gewarnt zu werden, denn die gefährlichsten Pakete sind diejenigen, vor denen noch niemand gewarnt wurde. Eine festgelegte Regel, die einfach ein paar Tage abwartet und vor der Installation eine Überprüfung durchführt, benötigt keine Warnung. Das ist der Unterschied zwischen der Abwehr bereits bekannter Angriffe und der Abwehr des nächsten Angriffs.

Eine ausführliche Erklärung, wie diese Angriffe funktionieren, findest Du im Leitfaden zu Angriffen auf die supply chain .