Der nächste Vorfall in Sachen Lieferkettenangriff ist gerade passiert. Seit dem gestrigen 8. Sept. 2025 gibt es Berichte, dass npm-Pakete kompromittiert seien. Nun kristallisiert sich heraus, dass das Konto eines Entwicklers durch simples Phishing gehackt wurde. Die Hacker konnten 18 npm-Pakete kompromittieren, die auf Millionen wöchentliche Downloads kommen. Dort werden Krypto-Transaktionen manipuliert und umgeleitet.
Was ist npm?
Zuerst eine kurze Einordnung: npm (Node Package Manager) ist ein Paketmanager für die JavaScript-Laufzeitumgebung Node.js, über den Javascript-Pakete verteilt werden. Das Ganze wurde 2010 von Isaac Schlueter als Mitarbeiter der kalifornischen Cloud-Plattform-Anbieters Joyent programmiert. Die Wikipedia merkt an, dass die npm Registry, wie jedes Repository, dafür anfällig ist, dass Pakete mit Schadcode eingestellt werden. Werden solche Pakete via Abhängigkeiten in einem Softwareprojekt verwendet, können verschiedenste Supply-Chain-Angriffe ausgeführt werden. In der Vergangenheit wurden Attacken via Typo-Squatting und Social Engineering bekannt. Am Beitragsende finden sich einige Artikellinks im Umfeld von npm.
Der neue npm-Vorfall
Es dürfte ein größeres Desaster werden, nachdem die Kompromittierung eines npm-Entwickler-Kontos bekannt wurde.
Einfacher Phishing-Angriff genügte
Es war ein arg simpler Phishing-Angriff auf npm-Entwickler, der den Stein ans Rollen brachte. Nachfolgender Screenshot zeigt die Phishing-Nachricht.
Dort wird mit npm-Logo von einer "support"-Adresse behauptet, dass man zur Kontenabsicherung seiner Nutzer die Zweifaktor-Authentifizierung (2FA) aktualisieren wolle. Der Empfänger der Nachricht wird darüber informiert, dass er seit mindestens 12 Monaten kein "2FA-Update" mehr vorgenommen habe.
Zur Erhaltung der Sicherheit und Integrität des npm-Kontos wurde der Empfänger freundlich gebeten, bei nächstmöglicher Gelegenheit doch bitte seinen Zugang zu aktualisieren. Natürlich wurde ein Link Update 2FA Now zur "Aktualisierungsseite" mitgeliefert und die Drohung nachgeschoben, dass nicht bis zum 10. September 2025 verifizierte npm-Konten temporär gesperrt würden, um unautorisierte Zugriffe zu verhindern.
Wer sich die Nachricht genauer angeschaut hat, erkannte, dass diese von einem obskuren Absender kam. Und es wird auch gewarnt, einen Link in einer Nachricht anzuklicken, um auf eine Zugangsseite geleitet zu werden. Der nachfolgende Tweet gibt an, dass der populäre Entwickler qix (Josh Junon) aber auf diese Phishing-Masche hereingefallen sei (qix hat das hier bestätigt).
Er hat wohl seine Zugangsdaten auf der Phishing-Seite eingegeben, wodurch die Angreifer sein Konto übernehmen konnten.
18 npm-Pakete kompromittiert
Das Unheil nahm seinen Lauf, denn in verschiedene npm-Pakete wurde bösartiger Code eingeschleust, der nun Kryptotransaktionen (Etherum SOLANA-Transaktionen) bei der Signierung kapert. Die Empfänger-Adressen bei ETH/SOL-Transaktionen werden ausgetauscht, so dass die Kryptogelder bei den Angreifern landen.
Florian Roth hat gestern (8. Sept. 2025) gegen 20:00 Uhr den obigen Tweet mit einer Warnung geteilt. Der größte Angriff auf die Lieferkette in der Geschichte von npm, Inc. sei gerade passiert, heißt es. Pakete mit insgesamt 2 Milliarden Downloads pro Woche wurden mit bösartigem Code versehen.
Der Tweet verweist auf einen LinkedIn-Post von Mackenzie Jackson (Aikido-Security), der die infizierten Pakete auflistet. Sicherheitsforscher von Aikido weisen in diesem Post darauf hin, dass die folgenden npm-Pakete mit bösartigem Code versehen wurden.
- backslash (0.26m downloads per week)
- chalk-template (3.9m downloads per week)
- supports-hyperlinks (19.2m downloads per week)
- has-ansi (12.1m downloads per week)
- simple-swizzle (26.26m downloads per week)
- color-string (27.48m downloads per week)
- error-ex (47.17m downloads per week)
- color-name (191.71m downloads per week)
- is-arrayish (73.8m downloads per week)
- slice-ansi (59.8m downloads per week)
- color-convert (193.5m downloads per week)
- wrap-ansi (197.99m downloads per week)
- ansi-regex (243.64m downloads per week)
- supports-color (287.1m downloads per week)
- strip-ansi (261.17m downloads per week)
- chalk (299.99m downloads per week)
- debug (357.6m downloads per week)
- ansi-styles (371.41m downloads per week)
Die obigen Pakete wurden aktualisiert und enthalten nun einen böswilligen Code, der auf dem Client einer Website ausgeführt wird. Dieser böswillige Code fängt laut Aikido unbemerkt Krypto- und Web3-Aktivitäten im Browser ab, manipuliert Wallet-Interaktionen und schreibt Zahlungsziele um, sodass Gelder und Genehmigungen ohne erkennbare Anzeichen für den Benutzer auf vom Angreifer kontrollierte Konten umgeleitet werden.
Der verlinkte Aikido-Beitrag enthält eine detaillierte Analyse des Sachverhalts. Die Verwendung von npm-Paketen gleiche inzwischen "Russischem Roulette" schreibt der Sicherheitsanbieter. Um zu vermeiden, dass Projekte durch solche Pakete kompromittiert werden, habe man die Aikido Safe-Chain entwickelt. Das sei ein sicherer Wrapper für npm, npx und yarn, der sich in den aktuellen Workflow einfügt und jedes Paket vor der Installation auf Malware überprüft. Die Safe-Chain schützt Projekte in Echtzeit vor Dependency Confusion, Backdoors, Typosquatting und anderen Bedrohungen in der Lieferkette, ohne den Workflow im Projekt zu verändern.
Ergänzung: Der finanzielle Gewinn der Hacker war begrenzt, siehe npm-Hack: Angreifer schauen weitgehend in die Röhre.
Ähnliche Artikel:
Populäre npm- und JavaScript-Bibliotheken gehackt
Entwickler sabotiert Open Source Module colors.js und faker.js in NPM, betrifft Tausende Projekte
Microsoft kauft JavaScript-Entwickler-Plattform npm, GitHub-Integration kommt
Schwere npm-Update-Panne bei Linux-Systemen
MVP: 2013 – 2016
wenn mans genau nimmt :…Milliarden Downloads…. ;)
Viele Millionen Downloads gibt auch Milliarden ;-)
Wieso fällt mir da jetzt dieser eine Forist ein, der "hilft bei der Migration von geschlossenen, proprietären zu offenen, freien Technologien"? Offen und frei heisst eben leider auch allzu oft 'Wir können alles ausser Lieferkette'. Insofern ist 'offen statt frei' de facto 'Pest statt Cholera'. Mehr Dedigitaliserung wagen!
Was für ein Unfug. Die Lieferkettenproblematik betrifft auch geschlossene, unfreie Technologien…
Ja, aber weniger. Ich sage: Heartbleed, Log4j, xz. Jetzt Du drei 'ebenbürtige' Closed Source Beispiele, in denen Fehler Dritter übernommen wurden. Ich rede nicht von Böcken in Code der unternehmenseigenen Entwickler und natürlich auch nicht von Lücken, die durch Integration von offenem Code in Closed Source aufgerissen wurden.
> Jetzt Du drei 'ebenbürtige' Closed Source Beispiele…
Oh boy… finde den Fehler Deiner kruden Logik. Ebenbürtige Closed Source Beispiele wirst Du nicht finden, weil es closed Source ist.
NPM ist unbestritten Dreck. Das vermeidet man, wo nur möglich. Die Probleme liegen eher bei super hippen, agilen, vibe Script-Kiddies, die das Programmieren nie richtig erlernt haben und jetzt husch, husch mit begrenzter Zeit und Ressourcen und viel KI irgendwelche Software dahinrotzen. Das passiert unabhängig davon, ob was Open oder Closed Sourced ist.
Betr. "Beispiele wirst Du nicht finden, weil es closed Source ist.":
Jakobs, besinn' er sich. Auch wenn Sie Ihr Geld mit Informationssicherheit nur auf der Ebene von Managementsystemen verdienen, sollte Ihnen doch Verifysofts CodeSentry (https://www.verifysoft.com/en_codesentry.html) bekannt sein. Closed Source Third Party Software in Closed Source Applikationen zu identifizieren ist machbar, falls Sie das mit Ihrem Statement in Abrede stellen wollten. Wer suchet der findet – auch ohne Quellcode. Fakt ist und bleibt, dass über erfolgreiche Angriffe auf Closed Source Applikationen wegen in Third Party Codeteilen enthaltener Lücken nach Nachrichtenlage (z. B. auch in diesem Blog) nichts bekannt ist, obwohl für jeden von einem Angriff betroffenen Applikationshersteller ein 'sorry, Lücke war im Code eines Zulieferers' eine gern genommene und an die Fachpresse weitergegebene Entschuldigung wäre.
Microsoft/ Citrix so ungefähr einmal pro Monat?
Was denn genau? Herrn Jakobs zufolge ist das doch garnicht möglich "weil es closed Source ist.".
Okay, Josh Junon hätte gerade als Entwickler bei so etwas viel vorsichtiger sein müssen. Aber solche Fälle würden auch seltener vorkommen, wenn die Firmen nicht laufend wirklich genau so ein Security-Theater veranstalten würden.
Ist doch Open Source da darfst das nicht so ernst nehmen… open eben wörtlicher genommen ;-P … Scheunentor weit offen ;-P
Open Source/Linux ?
Nein!
Doch!
Ooh!
Gibt mir mal wieder recht dass alles nur noch aus Librarys und Frameworks zusammen geflickt wird und keiner mehr richtig alles selber macht. Und das nennt sich dann "Full Depp äh Stack Developer".