Angriff auf das Herz der Software-Supply-Chain : Phishing-Kampagne kompromittiert npm-Projekte : Cyberangriff auf Open-Source-Ökosystem: Angreifer schleusen Schadcode über gestohlene Maintainer-Tokens in populäre npm-Pakete ein – ohne Spuren im Quellcode.
Ein hochgradig koordinierter Angriff auf die Open-Source-Infrastruktur des npm-Ökosystems zeigt eindrucksvoll, wie verwundbar selbst etablierte Softwareprojekte gegenüber Phishing und Supply-Chain-Angriffen sind: Fünf kompromittierte npm-Pakete wurden über gestohlene Zugangstokens direkt mit Schadcode manipuliert – ohne jegliche Spuren in den GitHub-Repositories der jeweiligen Projekte.
Im Zentrum des Vorfalls steht eine Phishing-Kampagne, bei der Projektverantwortliche E-Mails erhielten, die vermeintlich vom offiziellen npm-Support stammten. Unter dem Vorwand, die E-Mail-Adresse verifizieren zu müssen, wurden sie auf eine täuschend echt gestaltete Fake-Seite unter der Adresse „npnjs[.]com“ gelotst. Diese Seite war darauf ausgelegt, die npm-Zugangsdaten der Maintainer abzugreifen.
Mit den so erlangten Tokens konnten Angreifer ohne weitere Autorisierung direkt neue Versionen auf das npm-Register hochladen. Die GitHub-Repositories der betroffenen Pakete blieben dabei unberührt – eine gezielte Umgehung gängiger Kontrollmechanismen.
Betroffen sind laut dem auf Software-Lieferkettensicherheit spezialisierten Unternehmen Socket unter anderem die folgenden Pakete:
- eslint-config-prettier (Versionen 8.10.1, 9.1.1, 10.1.6, 10.1.7)
- eslint-plugin-prettier (Versionen 4.2.2, 4.2.3)
- synckit (Version 0.11.9)
- @pkgr/core (Version 0.2.8)
- napi-postinstall (Version 0.3.1)
Der eingeschleuste Schadcode versuchte unter anderem, auf Windows-Systemen eine Dynamic Link Library (DLL) auszuführen, die Remote Code Execution ermöglichen könnte – ein hohes Risiko für alle Nutzer, die diese Versionen unbemerkt installiert haben.
Folgen für Entwickler: Dringender Handlungsbedarf
Alle Entwickler und Teams, die auf eines der betroffenen Pakete setzen, sollten umgehend die installierten Versionen prüfen und gegebenenfalls auf sichere Versionen zurückgehen. Zudem raten Sicherheitsexperten dringend zur Aktivierung der Zwei-Faktor-Authentifizierung für npm-Accounts sowie zur Verwendung von Scoped Tokens statt Passwörtern für Veröffentlichungen.
Die Schwachstelle zeigt, wie schnell ein gezielter Angriff auf Projektverantwortliche das gesamte Software-Ökosystem destabilisieren kann. Jeder npm-Token, der kompromittiert wird, ist ein potenzieller Angriffsvektor auf Tausende Downstream-Projekte – oft ohne sofort sichtbare Anzeichen.
Parallelaktivitäten: Protestware und kompromittierte AUR-Pakete
Zeitgleich wurde eine weitere Kampagne bekannt, bei der 28 npm-Pakete gezielt Funktionen enthielten, die Websites mit russischen oder belarussischen Domains manipulierten. Betroffen waren nur Nutzer mit russischsprachigen Browsereinstellungen – unter bestimmten Bedingungen wurde die Mauskontrolle deaktiviert und die ukrainische Nationalhymne abgespielt. Laut Sicherheitsanalystin Olivia Brown zeigt diese Protestware, wie tiefgreifend sich solche Funktionen über verschachtelte Abhängigkeiten verbreiten können – oft unbemerkt über Tage oder Wochen.
Auch das Arch-Linux-Projekt war jüngst betroffen: Drei Pakete im Arch User Repository („librewolf-fix-bin“, „firefox-patch-bin“, „zen-browser-patched-bin“) installierten eine Chaos-RAT-Schadsoftware aus einem GitHub-Repository. Die Maintainer warnten ausdrücklich vor der weiteren Nutzung und empfehlen, betroffene Systeme unverzüglich auf Kompromittierung zu prüfen.
Fazit: Software-Lieferketten unter Dauerbeschuss
Die aktuellen Vorfälle unterstreichen, wie dringend notwendig ein durchgängiges Sicherheitsverständnis in der Software-Lieferkette ist – nicht nur in der Entwicklung, sondern auch im Veröffentlichungsprozess und im Paketmanagement. Besonders im Open-Source-Bereich sind dezentrale Wartungsmodelle und fehlende Prüfmechanismen eine Schwachstelle, die Angreifer gezielt ausnutzen.
Organisationen sollten ihre Abhängigkeitsbäume regelmäßig überprüfen, bekannte Bedrohungen zentral überwachen und technische Schutzmaßnahmen – wie Signierung von Releases, 2FA und automatisiertes Dependency-Scanning – konsequent umsetzen. Denn jeder Token, jedes Paket und jeder Commit kann zur Schwachstelle werden, wenn die Kontrolle fehlt.
