TrapDoor: Koordinierter Supply-Chain-Angriff auf npm, PyPI und Crates – was CI/CD-Teams jetzt prüfen
7 Min. Lesezeit
Am 22. Mai 2026, 20:20 UTC, lud ein PyPI-Account das Paket eth-security-auditor 0.1.0 hoch. Bis Socket die Welle als TrapDoor klassifiziert hatte, lagen 34 weitere Pakete in npm, PyPI und Crates.io. Mediane Erkennungszeit pro Release: 5 Minuten 27 Sekunden. Wer in dieser Spanne ein CI/CD-Run startet, hat ein Problem, das kein Vendor-Demo erklärt.
Das Wichtigste in Kürze
- Koordinierter Multi-Registry-Angriff. Socket dokumentiert 34 Pakete in mehr als 384 Versionen, parallel auf npm, PyPI und Crates.io über den Account asdxzxc, alle mit demselben Marker P-2024-001.
- AI-Coding-Konfigurationen werden zur Angriffsfläche. TrapDoor schreibt mit Zero-Width-Unicode versteckte Anweisungen in cursorrules- und CLAUDE.md-Dateien, damit Cursor oder Claude Code falsche Security-Scans starten.
- CI/CD-Pipelines sind das Ziel, nicht der Entwickler-Laptop. Wer postinstall, build.rs und Python-Import-Hooks nicht im Build deaktiviert hat, hat einen ungepatchten Lieferkettenpfad, der unter NIS2 Artikel 21 und DORA-ICT-Risk-Management dokumentationspflichtig ist.
Verwandt:NIS2 trifft CLOUD Act / NIS2-Compliance im Mittelstand
Warum diese Welle nicht aussieht wie Typosquatting
Was ist TrapDoor? TrapDoor ist die Bezeichnung der Sicherheitsforscher von Socket für einen koordinierten Supply-Chain-Angriff im Mai 2026, bei dem über 34 bösartige Pakete parallel in npm, PyPI und Crates.io eingeschleust wurden, um Wallet-Keystores, SSH-Keys, Cloud-Credentials und KI-Editor-Konfigurationen zu stehlen. Der Cluster trägt den internen Marker P-2024-001 und ist über den GitHub-Account ddjidd564 sowie den npm-Account asdxzxc verknüpft.
Die üblichen Typosquat-Kampagnen leben von Zufall. Jemand vertippt sich beim npm install, ein Paket mit ähnlich klingendem Namen liefert eine versteckte Payload. TrapDoor arbeitet anders. Die Pakete tragen Namen wie prompt-engineering-toolkit, solidity-deploy-guard und defi-threat-scanner. Sie posieren als Werkzeuge für genau die Zielgruppe, die der Angreifer abschöpfen will: Entwicklerinnen in Krypto-, DeFi-, Solana- und KI-Umgebungen.
Der zweite Bruch zur normalen npm-Wave ist die Registry-Breite. Drei Paket-Manager gleichzeitig, mit demselben Threat-Actor-Fingerprint, demselben GitHub-Account ddjidd564 und demselben Marker. Das ist ein Operations-Setup, kein Skriptkiddie-Lauf.
Und es ist schnell. Socket meldet eine mediane Erkennungszeit von 5 Minuten 27 Sekunden über 381 Release-Datensätze mit vollständigen Zeitstempeln. Der schnellste Fund lag 58 Sekunden nach Publikation. Wer in einem dieser Fenster ein npm install oder pip install in einem unkontrollierten CI-Runner anstößt, hat Pech.
Wie der Angriff sich pro Registry verzweigt
Die Pakete teilen sich eine Zielarchitektur, aber unterschiedliche Trigger pro Ecosystem. In npm hängt die Payload an postinstall, in Rust wird der Code über build.rs gezogen, in Python feuert sie zur Import-Zeit. Diese Trennung ist relevant, weil sie genau die drei Punkte trifft, an denen Build-Systeme automatisch fremden Code ausführen, ohne dass der Anwender ihn explizit startet.
Eingesammelt werden SSH-Keys, AWS-Credentials, GitHub-Tokens, Browser-Login-Datenbanken, Wallet-Keystores für Sui, Solana und Aptos, Environment-Variablen, API-Keys und lokale Dev-Konfigurationen. Das ist die komplette Lieferanten-Sicht eines durchschnittlichen Entwicklerinnen-Workstation-Profils, einschließlich aller Cloud-Persistenzen.
Wo TrapDoor wirklich neu wird: KI-Coding-Konfigurationen
Der Angriff hat einen Vektor, den üblicher Supply-Chain-Schadcode nicht hat. TrapDoor manipuliert die Konfigurationsdateien von Cursor und Claude Code direkt. Konkret: cursorrules und Projekt-CLAUDE.md werden mit Zero-Width-Unicode-Zeichen versehen, die dem Reviewer im Editor unsichtbar bleiben, aber vom KI-Assistenten als Prompt interpretiert werden.
Das Resultat ist eine getarnte Anweisung, die den Assistenten dazu bringt, eigene Security-Scans oder Diagnose-Routinen auszuführen, die in Wahrheit Daten aus dem Projekt-Kontext exportieren. Wer mit einem KI-gestützten Editor arbeitet und die Repository-Konfigurations-Dateien nicht versioniert kontrolliert, hat einen Pfad, den die übliche Endpoint-Detection nicht sieht. Das ist die erste dokumentierte Supply-Chain-Welle, die KI-Agenten als Mitausführungs-Layer benutzt.
Wer das im Team ernst nimmt, behandelt cursorrules und Projekt-CLAUDE.md ab heute wie Build-Skripte. Diff-Reviews pro Commit, Encoding-Prüfung auf Unicode-Anomalien, kein Mergen ohne zwei Augen.
CI/CD-Mitigationen: was trägt, was bricht
Was bricht
- Build-Runner mit Internet-Zugriff und ohne Egress-Filter
- npm install ohne –ignore-scripts in CI
- Lock-Files ohne Hash-Prüfung beim Restore
- Geteilte Service-Accounts über mehrere Projekte
- cursorrules und Projekt-CLAUDE.md ungetrackt im Workspace
Was trägt
- npm ci –ignore-scripts, pip –no-build-isolation kontrolliert
- SBOM-Erstellung pro Build, signiert
- Allowlist statt Denylist auf Registries
- Kurzlebige Build-Credentials über OIDC, kein statisches Token
- Reproducible Builds mit Hash-Vergleich gegen letzten Green-Run
Egress-Filter sind der unterschätzte Hebel. Selbst wenn ein bösartiges postinstall im Build läuft, hat es ohne ausgehende Verbindung in Drittnetze kein Ziel für die Credentials. Wer seinen GitHub-Actions-Runner oder GitLab-Executor heute noch in einem flachen VPC ohne Egress-Regelwerk betreibt, kommt mit npm audit nicht weiter.
Der zweite stille Gewinner ist OIDC. Ein Build, der seinen kurzlebigen AWS-Token erst zur Ausführungszeit aus dem CI-OIDC-Issuer holt, hat keinen langlebigen Cloud-Key, den TrapDoor stehlen könnte. Das verschiebt das Angriffsfenster vom permanenten Secret zur Build-Dauer.
NIS2 und DORA: wo das Thema heute schon dokumentationspflichtig ist
NIS2 Artikel 21 listet die Lieferkettensicherheit als eine der Mindest-Risikomanagementmassnahmen, die ein wesentlicher oder wichtiger Anbieter umsetzen muss. Konkret: dokumentierte Bewertung der direkten Lieferanten und Diensteanbieter, einschließlich der Software-Abhängigkeiten. Eine npm-Dependency in einem produktiv eingesetzten Build ist juristisch nicht weniger Lieferant als ein extern bezogenes Steuerungsmodul.
DORA verlangt für den Finanzsektor in Artikel 28 und 30 einen vollständigen Bestand der ICT-Drittparteien plus dokumentierte Konzentrationsrisiken. Wer als Bank oder Finanzdienstleister ein npm-Repo mit hunderten transitiven Abhängigkeiten einsetzt, ohne diese in der ICT-Drittpartei-Registrierung zu führen, hat im nächsten Audit eine offene Flanke.
Beide Regelwerke verlangen keinen vollständigen Schutz gegen Zero-Day-Pakete, aber sie verlangen einen nachvollziehbaren Prozess. Genau hier liegt der NIS2- und DORA-Hebel für Sicherheitsverantwortliche: TrapDoor wird zum konkreten Beispielfall, an dem sich die eigenen Lieferkettenprozesse messen lassen.
Vier Wochen sind ein realistisches Fenster, wenn das Sicherheitsteam die Tickets schreibt und das Plattform-Team baut. Die Reihenfolge ist absichtlich asymmetrisch: Egress vor SBOM vor OIDC vor AI-Konfig. Wer in dieser Reihenfolge fällt, schliesst zuerst die Wege, über die TrapDoor Daten ausleitet und kümmert sich danach um die strukturellen Themen.
Was bleibt offen
Socket beschreibt einen Angreifer, der sehr viel über moderne Build-Systeme und KI-Editoren weiß. Die nächste Welle wird wahrscheinlich nicht in pep- und npm-Paketen liegen, sondern in Helm-Charts, Container-Base-Images oder direkt in GitHub-Action-Workflows. Wer also TrapDoor nur als npm-Vorfall abhakt, plant am nächsten Vektor vorbei.
Es lohnt sich, ab heute die eigene CI/CD-Plattform wie ein laufendes Produktionssystem zu behandeln, nicht wie ein Hilfsmittel. Mit allem, was das bedeutet: Hardening-Baseline, Monitoring, Incident-Playbook, dokumentierte Verantwortlichkeiten.
Häufige Fragen
Welche Pakete sind aktuell als bösartig markiert?
Socket dokumentiert 34 Pakete und mehr als 384 Versionen über npm, PyPI und Crates.io. Einzelne Beispiele aus dem Socket-Bericht sind prompt-engineering-toolkit, solidity-deploy-guard und defi-threat-scanner. Eine vollständige, fortlaufend aktualisierte Liste führt Socket im Original-Blogpost. Eigene Build-Bestände sollten gegen diese Liste gespiegelt werden.
Bin ich betroffen, wenn ich npm install lokal laufen lasse?
Lokal ist das Risiko hoch, weil postinstall ohne weitere Restriktionen feuert. In CI/CD ist es noch höher, weil Build-Runner häufig Zugriff auf langlebige Cloud-Credentials und SSH-Keys haben. Wer in beiden Umgebungen ohne Egress-Filter, ohne npm ci –ignore-scripts und ohne SBOM-Vergleich arbeitet, sollte heute die Logs der letzten 72 Stunden durchsehen.
Was ist mit Cursor und Claude Code konkret zu tun?
Konfigurationsdateien wie cursorrules und Projekt-CLAUDE.md sollten in jedem Repository versioniert sein. Ein Pre-Commit-Hook, der die Datei auf Zero-Width-Unicode-Zeichen prüft, verhindert die offensichtlichste Variante des Angriffs. Daneben gehört die Frage, welche externe Quellen ein KI-Editor zur Laufzeit einliest, in jedes Onboarding-Dokument.
Wie passt TrapDoor in die NIS2-Risikobewertung?
Artikel 21 NIS2 verlangt eine dokumentierte Bewertung der Lieferketten-Risiken. Eine Open-Source-Dependency mit unklarem Maintainer ist juristisch ein Lieferant. Wer keinen Prozess hat, der Pakete vor Aufnahme bewertet und nach Aufnahme überwacht, hat ein klares Audit-Finding.
Lohnt sich der Schwenk auf private Registry-Mirrors?
Für Teams mit hoher Build-Frequenz und produktionsnaher Codebasis ja. Ein interner Mirror mit Allowlist und Hash-Prüfung verschiebt das Vertrauensmodell weg von der öffentlichen Registry. Der Aufwand ist real, aber der Schutz ist verifizierbar und auditfähig, was unter NIS2 und DORA explizit zählt.
Lesetipps der Redaktion
Mehr aus dem MBF Media Netzwerk
Quelle Titelbild: Pexels / Markus Winkler (px:30901557)
