Ein neuer Phishing-Angriff auf das populäre NPM-Ökosystem hat die Entwicklergemeinde aufgeschreckt. Besonders perfide: Die Angreifer nutzten Social Engineering und typosquatting, um legitime JavaScript-Projekte zu kompromittieren. Der Vorfall wirft ein grelles Licht auf die verwundbare Software Supply Chain – und ist ein dringender Appell zum Umdenken.
Ein Überblick: Der Phishing-Fall bei NPM
Im Juni 2025 berichtete GitHub über einen ausgeklügelten Phishing-Angriff, der auf NPM-Entwickler abzielte. Die Täter setzten kompromittierte E-Mails ein, um gezielt Maintainer populärer Pakete zu täuschen. Ziel war es, Zugänge zu offiziellen NPM-Konten zu erhalten und anschließend Schadcode in legitim wirkende Bibliotheken einzuschleusen.
Laut dem offiziellen Sicherheitsbericht von GitHub betraf der Angriff unter anderem ein beliebtes Paket namens eslint-scope. Die Angreifer registrierten typosquatted Versionen wie es-lintscope und eslint_sc0pe, um jene auszunutzen, die versehentlich zur falschen Bibliothek griffen.
Besonders brisant: Der eingeschleuste Schadcode sammelte Umgebungsvariablen und API-Tokens und versuchte, weitere Malware über Command-and-Control-Server nachzuladen. Die legitime Projektseite wurde manchmal täuschend echt nachgebildet – inklusive GitHub-Profilerstellung und Releasenummern.
Software Supply Chain – ein wachsendes Risiko
Diese gezielte Attacke auf JavaScript-Pakete unterstreicht ein wachsendes Muster in der Bedrohungslandschaft: Angriffe auf die Software Supply Chain. Da moderne Anwendungen Dutzende bis Hunderte von Open-Source-Abhängigkeiten integrieren, kann eine einzige kompromittierte Komponente verheerende Auswirkungen haben.
Laut einer Studie von Sonatype zur Software Supply Chain von 2024 wurden allein im letzten Jahr über 245.000 bösartige Pakete in öffentlichen Code-Registries wie NPM, PyPI und Maven gefunden – ein Anstieg von 130 % im Vergleich zum Vorjahr (Quelle: Sonatype State of the Software Supply Chain Report 2024).
Der wirtschaftliche Schaden steigt entsprechend: IBM beziffert in seinem „Cost of a Data Breach Report 2024“ den durchschnittlichen Schaden durch einen Angriff über Drittabhängigkeiten auf 4,76 Millionen US-Dollar pro Vorfall (Quelle: IBM Security).
Die perfide Methode: Typosquatting & Social Engineering
Anders als bei klassischen Malware-Angriffen setzen moderne Phishing-Strategien wie Typosquatting auf menschliche Fehler. Durch minimale Änderungen an Paketnamen – etwa ein Buchstabe zu viel oder ein Sonderzeichen – führen sie Entwickler in die Irre. Diese Techniken werden oft mit Social Engineering kombiniert, etwa durch gefälschte Support-Mails, Pull Requests oder Einladungen zu offenen Projekten.
Im aktuellen Fall nutzten die Angreifer legitime E-Mail-Adressen, die zuvor über geleakte Datenbanken kompromittiert wurden. Sie baten unter dem Vorwand einer kritischen Sicherheitsüberprüfung um Mitarbeit, um anschließend schädliche Merges in das Projekt einzuschleusen.
Wie kann sich die Entwickler-Community schützen?
In Anbetracht der zunehmenden Komplexität moderner Softwarearchitekturen und des hohen Automatisierungsgrads beim Deployment sind Sicherheitsvorkehrungen unabdingbar. Die Community sowie Plattformen wie GitHub und NPM haben begonnen, Maßnahmen zu ergreifen – etwa durch 2FA-Pflicht für Maintainer oder automatisierte Paketüberprüfung.
Dennoch liegt ein erheblicher Teil der Verantwortung bei den Entwicklern selbst. Folgende Maßnahmen helfen bei der Absicherung der eigenen Projekte:
- Multi-Faktor-Authentifizierung aktivieren: Projekte auf Plattformen wie GitHub, NPM oder GitLab sollten zwingend MFA nutzen – idealerweise mit einem Hardware-Token statt nur per SMS.
- Paketquellen validieren: Vor der Installation neuer Dependencies sollte stets die Quelle, der Maintainer und die Repository-Historie geprüft werden. Ungeprüfte Typosquatting-Pakete sollten sofort gemeldet werden.
- Security-Scans automatisieren: Werkzeuge wie npm audit, Snyk oder GitHub Dependabot helfen, Sicherheitslücken frühzeitig zu erkennen. Automatisierte CVE-Checks sind für Continuous Integration Pflicht.
Darüber hinaus empfiehlt die OWASP Foundation, regelmäßig sogenannte „Software Bill of Materials“ (SBOMs) zu erstellen. Sie dokumentieren präzise, welche Pakete und Versionen in einem Projekt verwendet werden – und stellen eine wichtige Grundlage für Incident Response dar.
Neue Verteidigungslinien: Tools & Prävention
Unternehmen und Open-Source-Communities reagieren zunehmend auf diese Bedrohungen. GitHub hat beispielsweise mit „npm package provenance“ eine Funktion eingeführt, die kryptografisch prüfbare Verifizierungen von Paketquellen ermöglicht. Auch das Tool Sigstore, initiiert durch die Linux Foundation, ermöglicht digitale Signaturen von Binärdateien und Code-Artefakten.
Ein weiteres Beispiel: Microsoft hat mit dem Open-Source-Tool OSV-Scanner eine Lösung geschaffen, die Projekte auf bekannte Schwachstellen im Abhängigkeitsbaum prüft. Solche Werkzeuge werden in Zukunft zur Grundausstattung sicherer Softwareentwicklung gehören.
Initiativen wie „OpenSSF Secure Software Scorecard“ ermöglichen es, beliebte Open-Source-Projekte anhand objektiver Kriterien in puncto Sicherheit zu bewerten – darunter Commit-Aktivität, Review-Qualität und verwendete Sicherheitsmechanismen.
Eine Kultur der Sicherheit etablieren
Phishing-Angriffe wie dieser sind nicht nur ein technisches, sondern auch ein kulturelles Problem. Viel zu oft wird Sicherheit als nachgelagerte Aufgabe betrachtet. Dabei muss Security „Shift Left“ – also frühzeitig im Entwicklungsprozess – gedacht und gelebt werden.
Besonders Projekt-Maintainer und Core-Teams sind gefordert, durch klare Richtlinien, Code Reviews und ein gesundes Misstrauen gegenüber externen Vorschlägen für mehr Resilienz zu sorgen. Gleichzeitig sollten große Plattformen weiter in Mechanismen investieren, die verdächtige Verhaltensmuster proaktiv erkennen – wie z. B. ungewöhnliche Download-Spitzen bei neu veröffentlichten Paketen.
Fazit: Community-Wachsamkeit als Rückgrat der Supply Chain
Der jüngste Phishing-Fall bei NPM ist ein Weckruf – kein singuläres Ereignis. Die Software Supply Chain ist heute eine Hauptangriffsfläche für Cyberkriminelle geworden. Entwicklern obliegt eine wachsende Verantwortung, nicht nur funktionalen, sondern auch sicheren Code zu schreiben.
Sicherheit in der modernen Softwareentwicklung ist Teamarbeit. Nur durch eine Kombination aus Tools, Prozessen, Aufklärung und Aufmerksamkeit kann der Wildwuchs verhindert werden. Teilen Sie Ihr Wissen, auditieren Sie Ihre Projekte und unterstützen Sie weniger erfahrene Maintainer. Jeder Commit zählt.
