- Was geschah beim npm-Angriff auf Axios?
- Wie eine einzige Zeile in der Datei „package.json“ zum Angriffsvektor wurde
- Warum der Angriff auf Axios bei der herkömmlichen Codeüberprüfung unentdeckt blieb
- Warum der Explosionsradius alles umfasst, was das Paket berührt
- Welche Sicherheitsmaßnahmen hätten den Ausgang verändert?
- Erfahren Sie mehr überSupply Chain Software Supply Chain
- Häufig gestellte Fragen
Das Hijacking von NPM-Paketen ist ein Angriff auf die Software-Lieferkette, bei dem das Vertrauen in ein Paket zum Angriffsweg wird. Angreifer müssen den Code im Repository nicht verändern, wenn sie die Kontrolle über das Konto haben, das das Paket veröffentlicht.
Genau das macht vertrauenswürdige npm-Pakete zu einer so gefährlichen Angriffsfläche. Wenn ein Betreiberkonto kompromittiert wird, kann jedes Projekt, das das betroffene Paket installiert, durch eine routinemäßige Aktualisierung der Abhängigkeiten gefährdet werden. Der Axios-Vorfall im März 2026 hat gezeigt, wie ein einziges kompromittiertes npm-Konto mehr als 100 Millionen wöchentliche Downloads gefährden konnte, ohne dass der Quellcode von Axios in irgendeiner sichtbaren Weise verändert wurde.
Das Verständnis der Funktionsweise von npm-Paket-Hijacking hilft Sicherheitsteams dabei, Kontrollmechanismen zu entwickeln, die den tatsächlichen Angriffspfad abdecken, anstatt sich nur auf die Quelldateien zu konzentrieren, die von den meisten Teams überprüft werden.
Was geschah beim npm-Angriff auf Axios?
Bei dem Axios-npm-Angriff handelte es sich um eine Übernahme des Betreiberkontos, durch die ein vertrauenswürdiges Paket zu einem Mechanismus zur Verbreitung von Malware wurde. Der Angreifer verschaffte sich Zugriff auf das npm-Konto des Hauptbetreibers von Axios, änderte die registrierte E-Mail-Adresse in eine vom Angreifer kontrollierte Adresse und sperrte den rechtmäßigen Betreiber aus.
Die Aktion war sorgfältig geplant und durchdacht. Etwa 18 Stunden vor der Aktivierung der Schadcode-Ladung wurde ein Scheindatei veröffentlicht, wodurch ein Veröffentlichungsverlauf entstand, der zunächst keinen Verdacht weckte. Anschließend veröffentlichte der Angreifer innerhalb von etwa 39 Minuten zwei schädliche Versionen: „axios 1.14.1“ für den modernen Release-Zweig und „axios 0.30.4“ für den Legacy-Zweig.
Beide Release-Zweige wurden zeitgleich veröffentlicht, um eine maximale Reichweite zu erzielen. Diese Entscheidung erhöhte die Wahrscheinlichkeit, dass sowohl aktuelle als auch ältere Umgebungen das manipulierte Paket im Rahmen des üblichen Update-Verhaltens herunterladen würden.
Wie eine einzige Zeile in der Datei „package.json“ zum Angriffsvektor wurde
Eine einzige Änderung an einer Abhängigkeit in der Datei „package.json“ kann bei einem npm-Supply-Chain-Angriff den gesamten Angriffspfad ausmachen. Im Fall von Axios mussten keine Axios-Quelldateien geändert werden, da das böswillige Verhalten durch eine neue Abhängigkeit eingeschleust wurde.
Diese Abhängigkeit wurde über einen npm-Postinstall-Hook ausgeführt. Sobald auf einem Entwickler-Arbeitsplatz, in einer CI/CD-Pipeline oder in einem Build-System der Befehl „npm install“ ausgeführt wurde, konnte das schädliche Paket Kontakt zu einem vom Angreifer kontrollierten Server aufnehmen, eine betriebssystemspezifische Payload abrufen und mit der Ausführung beginnen.
Die Payloads wurden für macOS, Windows und Linux vorbereitet. Der Angriff war von vornherein plattformübergreifend ausgelegt. Nach der Ausführung löschte der Dropper alle Spuren seiner eigenen Existenz und ersetzte die echte „package.json“-Datei durch eine gefälschte Version, was eine spätere forensische Untersuchung erheblich erschwerte.
Warum der Angriff auf Axios bei der herkömmlichen Codeüberprüfung unentdeckt blieb
Die herkömmliche Codeüberprüfung dient dazu, Änderungen am Quellcode innerhalb eines Repositorys zu überprüfen, doch dieser Angriffspfad befand sich nicht im Quellcode von Axios. Der Axios-Angriff stützte sich nicht auf sichtbare Änderungen im Repository, da sich die bösartige Logik nicht im Quellcode von Axios, sondern in einer separaten Abhängigkeit befand.
Dieser Unterschied ist entscheidend. Ein Prüfer, der sich das Paket-Update ansieht, würde kaum mehr als eine neue Zeile mit einer Abhängigkeit in der Datei „package.json“ erkennen. Das eigentliche böswillige Verhalten trat erst dann zutage, wenn die Abhängigkeit aufgelöst und installiert wurde.
Aus diesem Grund lassen sich Angriffe über vertrauenswürdige Pakete allein durch diff-basierte Überprüfungen nur schwer aufdecken. Der Angriffspfad liegt außerhalb der Quelldateien, die die meisten Teams überprüfen, obwohl das Paket weiterhin legitim genug erscheint, um routinemäßige Entwicklungsabläufe zu durchlaufen.
Warum der Explosionsradius alles umfasst, was das Paket berührt
Der Schadensradius eines kompromittierten npm-Pakets ist nicht das Paket selbst. Der Schadensradius umfasst alles, womit das Paket in Berührung kommt.
Für die meisten Unternehmen umfasst dies CI/CD-Pipelines mit erweiterten Berechtigungen, Entwickler-Endpunkte mit SSH-Schlüsseln und Cloud-Tokens, Build-Server mit Schreibzugriff auf Artefakt-Repositorys sowie Deployment-Tools, die mit Produktionssystemen verbunden sind. Ein bösartiges Paket muss sich nicht im Abhängigkeitsbaum befinden, um Schaden anzurichten. Es benötigt lediglich einen vertrauenswürdigen Ausführungspunkt.
Deshalb ist der Axios-Vorfall nicht nur für die Verwaltung von JavaScript-Paketen von Bedeutung. Eine Kompromittierung über „postinstall“ kann dazu führen, dass ein normales Installationsereignis zum Diebstahl von Anmeldedaten, zu lateraler Bewegung oder zum Zugriff auf nachgelagerte Infrastruktur führt.
Strukturelle Schwachstellen, die der Axios-Angriff aufgedeckt hat
Der Vorfall bei Axios hat strukturelle Schwachstellen offenbart, die in modernen Softwareentwicklungsumgebungen weit verbreitet sind. Dabei handelt es sich nicht um seltene Ausnahmefälle, sondern um gängige Annahmen in vielen Unternehmen.
Vertrauen in die Identität von Paketbetreuern
Das Vertrauen in ein npm-Paket ist oft an das Konto des Betreuers gebunden, der das Paket veröffentlicht. Wird dieses Konto gestohlen oder durch Phishing kompromittiert, erhält der Angreifer dieselben Veröffentlichungsrechte wie der rechtmäßige Betreuer.
Variable Versionen von Abhängigkeiten
Versionen mit schwebenden oder nur locker verknüpften Versionsnummern erhöhen das Risiko durch böswillige Veröffentlichungen. Eine neu veröffentlichte kompromittierte Version kann automatisch in eine Umgebung gelangen, ohne dass ein bewusster Genehmigungsschritt erforderlich ist.
Nicht überwachte Skripte nach der Installation
npm-Postinstallationsskripte können beliebigen Code mit den Berechtigungen des Installationsprozesses ausführen. Viele Unternehmen überprüfen oder beschränken Lebenszyklus-Skripte nicht, bevor diese ausgeführt werden.
CI/CD-Pipelines mit eingeschränkter Laufzeit-Transparenz
CI/CD-Pipelines verfügen häufig über weitreichende Zugriffsrechte auf interne Systeme, die Build-Infrastruktur und Cloud-Umgebungen. Diese Pipelines genießen oft standardmäßig das Vertrauen der Verantwortlichen und werden bei der Installation selten auf bösartiges Verhalten von Paketen überprüft.
Entwickler-Endpunkte außerhalb des vollständigen Sicherheitsschutzes
Auf Entwicklerrechnern werden wertvolle Ressourcen gespeichert, darunter SSH-Schlüssel, Cloud-Anmeldedaten und Unternehmenstoken. Entwickler-Endpunkte sind zudem häufige Angriffsziele, da sie oft weniger gut überwacht werden und über weniger Laufzeitsicherungen verfügen als Produktionssysteme.
Speicher für Anmeldedaten ohne Auslöser für eine schnelle Erneuerung
Ein Angriff auf die Software-Lieferkette führt häufig dazu, dass Zugangsdaten offengelegt werden. Viele Teams verfügen nach wie vor nicht über zuverlässige Arbeitsabläufe, mit denen potenziell gefährdete Geheimnisse identifiziert und umgehend geändert werden können.
Welche Sicherheitsmaßnahmen hätten den Ausgang verändert?
Drei Kategorien von Sicherheitsmaßnahmen hätten die Auswirkungen des Axios-Angriffs erheblich gemindert. Jede dieser Maßnahmen zielt auf einen anderen Punkt in der Angriffskette ab: die Ausführung von Paketen, die Offenlegung von Anmeldedaten und die Transparenz von Abhängigkeiten.
1. Überprüfung auf Malware auf Paketebene vor der Installation
Das Scannen von Paketen auf Malware hilft dabei, schädliche Abhängigkeiten zu stoppen, bevor sie ausgeführt werden. Dies ist bei npm-Angriffen von Bedeutung, da Postinstall-Hooks während der Installation ausgeführt werden, was nach dem Herunterladen des Pakets kaum Zeit für eine manuelle Überprüfung lässt.
Durch das Scannen von Paketen, Abhängigkeiten und Lebenszyklus-Skripten vor der Installation lassen sich bekannte Malware, verdächtige Verhaltensweisen, Schwachstellen und fest codierte Geheimnisse erkennen, bevor das Paket einen Entwickler-Endpunkt oder eine CI/CD-Umgebung erreicht.
MetaDefender Software Supply Chain ist die Software-Lieferkettensicherheitslösung OPSWATzur Validierung von Softwarekomponenten, Anbietern und Build-Pipelines. Sie nutzt eine Multi-Engine-Bedrohungserkennung, einschließlich des Metascan-Multiscans über mehr als 30 Antiviren-Engines, um Pakete auf Malware, Schwachstellen und fest codierte Geheimnisse zu überprüfen, bevor sie in den Entwicklungszyklus gelangen.
2. Proaktives Geheimnismanagement mit Auslösebedingungen für die Rotation
Ein proaktives Geheimnis-Management mindert den Nutzen eines erfolgreichen Angriffs. Wenn ein verdächtiges Paket identifiziert wird, benötigen die Teams einen Reaktionsplan, der lokale Anmeldedaten, SSH-Schlüssel, Tokens und Pipeline-Geheimnisse als potenziell kompromittiert behandelt und diese umgehend aktualisiert.
Die Erkennung fest codierter Geheimnisse dient demselben Zweck. Ein bösartiges Paket kann Geheimnisse aus dem Speicher oder von der Festplatte stehlen, doch offen gelegte Geheimnisse, die bereits im Code oder in Abhängigkeiten vorhanden sind, stellen ein zusätzliches, vermeidbares Risiko dar.
3. Supply Chain und Überwachung von Abhängigkeiten
Durch Transparenz in der Lieferkette können Teams unerwartete Änderungen an Paketen erkennen, bevor diese zu Problemen in nachgelagerten Prozessen führen. Sicherheitsteams müssen wissen, welche Pakete installiert sind, welche Versionen festgehalten werden, welche neuen Abhängigkeiten hinzugekommen sind und wo diese Komponenten ausgeführt werden.
Ohne Transparenz und Überwachung der Abhängigkeiten kann das erste Anzeichen für eine Kompromittierung der Sicherheit der Missbrauch von Anmeldedaten oder der Infrastruktur sein, lange nachdem die ursprüngliche Installation bereits abgeschlossen ist.
Erfahren Sie mehr überSupply Chain Software Supply Chain
Die Sicherheit der Software hängt davon ab, dass Pakete vor der Ausführung überprüft, neue Abhängigkeiten überwacht und das Risiko eines Zugriffs auf Anmeldedaten nach einer Kompromittierung eines Pakets minimiert werden.
Sehen Sie sich das On-Demand-Webinar an:Supply Chain Software Supply Chain – Die Schwachstellen, die Angreifer ausnutzen
Häufig gestellte Fragen
Was ist ein npm-Supply-Chain-Angriff?
Ein npm-Lieferkettenangriff ist die Einschleusung von Schadcode über das npm-Ökosystem im Rahmen der normalen Softwareentwicklung. Angreifer erreichen dies in der Regel, indem sie ein Betreuerkonto kompromittieren, ein betrügerisches Paket veröffentlichen oder Schadcode in Abhängigkeiten einschleusen, die von Entwicklern und CI/CD-Systemen automatisch installiert werden.
Wie haben Angreifer das Axios-npm-Paket kompromittiert?
Angreifer haben das npm-Konto des Hauptbetreuers von Axios kompromittiert und diesen Veröffentlichungszugriff genutzt, um bösartige Versionen sowohl im 1.x- als auch im 0.x-Release-Zweig zu veröffentlichen. Außerdem änderten die Angreifer die E-Mail-Adresse des Kontos in eine von ihnen kontrollierte Adresse, wodurch sie die Kontrolle über das Paket behalten konnten.
Was hat die Malware beim Angriff auf Axios angerichtet?
Die Malware beim Axios-Angriff nutzte einen Postinstall-Hook, der während des Befehls „npm install“ ausgeführt wurde. Der Hook stellte eine Verbindung zu einem vom Angreifer kontrollierten Server her, lud einen Fernzugriffstrojaner für macOS, Windows oder Linux herunter, startete diesen und versuchte anschließend, Spuren zu verwischen, indem er die Metadaten des Pakets durch gefälschte Inhalte ersetzte.
Warum wurde der Angriff auf die Lieferkette von Axios bei der Codeüberprüfung nicht entdeckt?
Die Codeüberprüfung hat den Axios-Angriff nicht erkannt, da die bösartige Logik nicht in den Axios-Quellcode eingebaut wurde. Die sichtbare Änderung auf Repository-Ebene war ein Eintrag in der `package.json`-Datei, während die eigentliche Malware über ein externes Paket bereitgestellt wurde, das außerhalb des normalen Umfangs der Quellcodeüberprüfung lag.
Wie können Unternehmen bösartige npm-Pakete vor der Installation erkennen?
Unternehmen können bösartige npm-Pakete vor der Installation erkennen, indem sie den Inhalt der Pakete, die Abhängigkeitsstrukturen und die Lebenszyklus-Skripte vor der Ausführung überprüfen. Wirksame Kontrollmaßnahmen kombinieren Malware-Scans, Abhängigkeitsanalysen, die Durchsetzung von Richtlinien und die Integration in CI/CD-Prozesse, sodass verdächtige Pakete blockiert werden können, bevor sie Entwickler- oder Build-Umgebungen erreichen.
Verhindert die Versionsfestlegung Angriffe auf die npm-Lieferkette?
Das Festlegen von Versionen verringert das Risiko durch neu veröffentlichte schädliche Versionen, da es automatische Upgrades einschränkt. Das Festlegen von Versionen beseitigt jedoch nicht das Risiko in der Lieferkette, da eine festgelegte Version möglicherweise bereits kompromittiert ist oder andere Vertrauensverletzungen weiterhin bestehen können. Das Festlegen von Versionen funktioniert am besten in Kombination mit Integritätsprüfungen, Paketüberprüfungen und Laufzeitkontrollen.
