TrapDoor-Angriff: Wie Kriminelle npm, PyPI und Crates.io für Datendiebstahl missbrauchen

Koordinierte Supply-Chain-Attacke bedroht Entwickler weltweit – und was NIS2-pflichtige Unternehmen jetzt tun müssen

Einleitung: Ein Angriff, der die gesamte Softwarelieferkette ins Visier nimmt

Ende Mai 2026 haben Sicherheitsforscher eine großangelegte, koordinierte Angriffskampagne aufgedeckt, die unter dem Namen TrapDoor bekannt geworden ist. Die Angreifer verteilten credential-stealing Malware – also Schadsoftware, die gezielt Zugangsdaten stiehlt – über gleich drei der meistgenutzten Open-Source-Paketrepositories der Welt: npm (JavaScript), PyPI (Python) und Crates.io (Rust).

Die Dimension ist bemerkenswert: Mehr als 34 bösartige Pakete in über 384 Versionen wurden in koordinierten Wellen veröffentlicht. Die erste dokumentierte Aktivität wurde am 22. Mai 2026 um 20:20 Uhr UTC registriert – ein Hinweis auf eine professionell geplante Operation.

Für deutsche IT-Verantwortliche und Geschäftsführer ist dieser Vorfall aus mehreren Gründen alarmierend: Nahezu jedes moderne Softwareprojekt nutzt Abhängigkeiten aus genau diesen Repositories. Wer betroffen ist, muss unter Umständen Meldepflichten nach NIS2 und DSGVO erfüllen – und das innerhalb enger Fristen.

Technischer Hintergrund: So funktioniert TrapDoor

Die Angriffstechnik: Typosquatting und Dependency Confusion

TrapDoor kombiniert zwei bewährte Angriffsvektoren der Software-Supply-Chain:

• Typosquatting: Pakete werden mit Namen veröffentlicht, die legitimen, weit verbreiteten Bibliotheken täuschend ähnlichsehen (z. B. reqests statt requests). Entwickler, die sich vertippen oder Copy-paste-Code aus dem Internet übernehmen, installieren unwissentlich die Schadsoftware.
• Dependency Confusion: Schädliche Pakete erhalten höhere Versionsnummern als ihre legitimen internen Gegenstücke in Unternehmensregistries. Build-Systeme laden dann automatisch die vermeintlich „neueste" Version – die bösartige.

Was die Malware tut

Einmal installiert, agiert die Malware als klassischer Infostealer:

1. Sie durchsucht das System nach gespeicherten Credentials (Browser-Passwörter, SSH-Keys, API-Tokens, Cloud-Konfigurationsdateien wie .aws/credentials)
2. Sie liest Umgebungsvariablen aus – ein besonders gefährlicher Angriffsvektor in CI/CD-Pipelines, wo oft Secrets wie Datenbankpasswörter oder Deployment-Keys hinterlegt sind
3. Die gesammelten Daten werden an externe Command-and-Control-Server exfiltriert

Warum drei Ökosysteme gleichzeitig?

Die parallele Veröffentlichung über npm, PyPI und Crates.io ist kein Zufall. Sie maximiert die Reichweite und erschwert die Attribution. Unternehmen, die Pakete aus allen drei Ökosystemen nutzen, müssen potenziell alle Projekte und Build-Umgebungen auf Kompromittierung prüfen.

Auswirkungen auf Deutschland und die NIS2-Relevanz

Wer ist betroffen?

In Deutschland sind potenziell alle Unternehmen betroffen, die:

• JavaScript/Node.js, Python oder Rust in ihrer Softwareentwicklung einsetzen
• Open-Source-Pakete aus öffentlichen Repositories beziehen
• CI/CD-Pipelines mit automatisierten Dependency-Downloads betreiben
• Softwareprodukte entwickeln, die als Teil einer Lieferkette an andere Unternehmen weitergegeben werden

Das betrifft nicht nur Tech-Unternehmen. Auch Banken, Versicherungen, Industrieunternehmen und Behörden, die interne Softwareentwicklung betreiben, sind potenzielle Opfer.

NIS2-Pflichten: Was jetzt gilt

Die NIS2-Richtlinie (umgesetzt in deutsches Recht durch das NIS2UmsuCG, das BSIG in seiner novellierten Form) verpflichtet betroffene Einrichtungen zu konkreten Maßnahmen:

Wichtig für die Praxis: Wenn durch einen TrapDoor-infizierten Build personenbezogene Daten abgeflossen sind, besteht zusätzlich eine Meldepflicht nach Art. 33 DSGVO gegenüber der zuständigen Datenschutzbehörde – ebenfalls innerhalb von 72 Stunden.

BSI-Empfehlungen zur Software-Supply-Chain

Das BSI hat im Rahmen seines IT-Grundschutzkompendiums (Baustein CON.10 „Entwicklung von Webanwendungen" und OPS.1.1.6 „Software-Tests und Freigaben") bereits Maßnahmen für den sicheren Umgang mit externen Abhängigkeiten definiert. TrapDoor zeigt, dass diese Empfehlungen keine theoretischen Vorsichtsmaßnahmen sind – sie sind praktisch relevant.

Praktische Schutzmaßnahmen: Was Sie jetzt konkret tun sollten

1. Software-Composition-Analysis (SCA) einführen

Setzen Sie Tools wie OWASP Dependency-Check, Snyk, Mend (ehem. WhiteSource) oder Trivy ein, um alle verwendeten Pakete automatisch auf bekannte Schwachstellen und Anomalien zu prüfen. SCA-Tools erkennen verdächtige Paketnamen und unerwartete Versionssprünge.

2. Private Package-Registries mit explizitem Allowlisting nutzen

Richten Sie eine interne Paketregistry (z. B. Nexus Repository, Artifactory oder Azure Artifacts) ein. Konfigurieren Sie Build-Systeme so, dass ausschließlich geprüfte und freigegebene Pakete bezogen werden. Dependency-Confusion-Angriffe laufen ins Leere, wenn der Zugriff auf öffentliche Registries kontrolliert oder gesperrt ist.

3. Package-Integritätsprüfung aktivieren

• Verwenden Sie npm audit, pip-audit und cargo's eingebaute Prüfmechanismen als Mindeststandard
• Aktivieren Sie Subresource Integrity (SRI) und Package-Lock-Dateien (package-lock.json, requirements.txt mit gehashten Einträgen, Cargo.lock)
• Prüfen Sie kryptografische Signaturen, wo verfügbar (npm Provenance, PyPI Trusted Publishers)

4. CI/CD-Pipelines absichern und Secrets schützen

Infostealer wie TrapDoor zielen bevorzugt auf Secrets in Build-Umgebungen. Maßnahmen:

• Secrets niemals als Klartext in Umgebungsvariablen speichern – nutzen Sie Secrets-Manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault)
• Prinzip der minimalen Rechte (Least Privilege) für alle Build-User und Service-Accounts
• Netzwerkisolation für Build-Agenten: Egress-Traffic auf bekannte Ziele beschränken
• Regelmäßige Rotation aller Credentials, die in Build-Umgebungen verwendet werden

5. Incident-Response-Plan für Supply-Chain-Vorfälle vorbereiten

Viele Unternehmen haben keinen spezifischen Plan für kompromittierte Abhängigkeiten. Definieren Sie:

• Erkennungsregeln (SIEM-Alerts bei unbekannten ausgehenden Verbindungen aus Build-Systemen)
• Isolationsverfahren (welche Systeme werden bei Verdacht sofort getrennt?)
• Meldekette für BSI-Meldungen und DSGVO-Notifications
• Verantwortlichkeiten (wer entscheidet über Meldepflicht, wer informiert die Geschäftsleitung?)

6. Regelmäßiges Software-Inventory und SBOM erstellen

Eine Software Bill of Materials (SBOM) listet alle verwendeten Komponenten und Abhängigkeiten vollständig auf. Das BSI und die ENISA empfehlen SBOMs ausdrücklich als Best Practice für Supply-Chain-Sicherheit. Mit einer aktuellen SBOM können Sie im Ernstfall in Minuten feststellen, ob Ihre Umgebung ein betroffenes Paket enthält.

Fazit: Supply-Chain-Sicherheit ist keine Kür mehr – sie ist Pflicht

TrapDoor ist keine isolierte Einzelaktion, sondern Ausdruck eines anhaltenden Trends: Angreifer wissen, dass die eigentliche Verteidigung in vielen Unternehmen gut aufgestellt ist – und greifen daher die Lieferkette an. Open-Source-Ökosysteme bieten eine riesige Angriffsfläche, die oft unzureichend überwacht wird.

Für NIS2-pflichtige Unternehmen gilt: Supply-Chain-Sicherheit ist kein optionaler Baustein, sondern explizit in Art. 21 NIS2 als Pflichtmaßnahme verankert. Wer jetzt nicht investiert, riskiert neben dem eigentlichen Schaden durch einen Vorfall auch empfindliche Bußgelder (bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes für wesentliche Einrichtungen) und Reputationsverluste.

Ihr nächster Schritt: NIS2-Compliance strukturiert angehen

Die Umsetzung aller NIS2-Anforderungen – von der Risikoanalyse über Meldeprozesse bis hin zum Lieferkettenmanagement – ist komplex und ressourcenintensiv. NIS2-Compliance-Softwarelösungen können dabei helfen, Pflichten zu strukturieren, Nachweise zu dokumentieren und Meldeprozesse zu automatisieren. Tools wie diese ermöglichen es IT-Teams und Geschäftsführern, den Überblick zu behalten, Zuständigkeiten klar zuzuweisen und im Ernstfall nachweislich compliant zu handeln. Wenn Sie noch kein dediziertes Tool im Einsatz haben: Jetzt ist der richtige Zeitpunkt, sich einen Überblick zu verschaffen.

Quellen: The Hacker News (25.05.2026), BSI IT-Grundschutzkompendium, ENISA Threat Landscape 2025, NIS2-Richtlinie (EU) 2022/2555, BSIG (novelliert)