Axios-Bibliothek: Cyberangriff trifft Millionen von Anwendungen
01.04.2026 - 03:48:55 | boerse-global.de
Ein gehacktes Maintainer-Konto ermöglichte es Angreifern, Schadcode in die populäre JavaScript-Bibliothek Axios einzuschleusen. Die kompromittierten Versionen waren für etwa drei Stunden online und stellen eine der schwerwiegendsten Supply-Chain-Attacken der letzten Jahre dar. Sie unterstreicht die systemische Verwundbarkeit der Open-Source-Infrastruktur.
Präziser Angriff auf Entwickler-Werkzeuge
Am 31. März 2026 gelang es einem unbekannten Angreifer, sich Zugang zum npm-Konto von Jason Saayman, dem Haupt-Maintainer von Axios, zu verschaffen. Der Angreifer änderte die registrierte E-Mail-Adresse und veröffentlichte zwei manipulierte Versionen der Bibliothek: axios@1.14.1 und axios@0.30.4. Damit wurden sowohl aktuelle als auch ältere Projekte ins Visier genommen. Die npm-Sicherheitsteams zogen die Pakete nach etwa drei Stunden offline.
Der aktuelle Angriff auf Axios verdeutlicht, wie verwundbar die IT-Infrastruktur selbst bei etablierten Tools ist. Erfahren Sie in diesem Experten-Report, wie mittelständische Unternehmen effektive Strategien gegen Cyberkriminelle entwickeln, ohne dass die Kosten explodieren. Effektive Schutzstrategien im Experten-Report entdecken
Das Besondere an diesem Angriff war seine chirurgische Präzision. Der eigentliche Quellcode von Axios blieb unberührt. Stattdessen fügten die Angreifer in der Datei package.json eine neue, bösartige Abhängigkeit namens plain-crypto-js@4.2.1 ein. Diese "Phantom-Abhängigkeit" wurde nie vom Axios-Code aufgerufen und blieb so bei oberflächlichen Code-Reviews unsichtbar.
Hochgefährliche Malware mit Selbstzerstörungsfunktion
Beim Installieren der kompromittierten Axios-Versionen wurde ein Post-Install-Skript aktiviert. Dieses lud, abhängig vom Betriebssystem des Entwickler-Rechners oder Servers, eine plattformspezifische Schadsoftware von einem Command-and-Control-Server herunter. Das finale Ziel: Ein Remote Access Trojaner (RAT), der SSH-Schlüssel, Cloud-Zugangsdaten (AWS, GCP, Azure), Kubernetes-Tokens und Kryptowallet-Daten ausspähte.
Um Spuren zu verwischen, verfügte die Malware über einen Selbstzerstörungsmechanismus. Nach erfolgreicher Infektion löschte sie die bösartigen Artefakte und ersetzte die manipulierte package.json durch eine saubere Version. Diese forensische Säuberung macht es Sicherheitsteams schwer, eine Kompromittierung nachträglich festzustellen.
Warum etablierte Sicherheitsmaßnahmen versagten
Der Angriff umging geschickt moderne Sicherheitsvorkehrungen. Der Angreifer nutzte die direkten npm-Veröffentlichungsrechte des Maintainers und veröffentlichte die Pakete manuell über die Kommandozeile. Dadurch wurde der offizielle, gesicherte Veröffentlichungsprozess über GitHub Actions mit OpenID Connect (OIDC) umgangen. Es gab keinen entsprechenden Commit oder Tag im offiziellen GitHub-Repository – ein klares Warnsignal, das viele automatisierte Tools jedoch nicht in Echtzeit erkennen.
Während Supply-Chain-Angriffe technisch komplexer werden, hinkt die Vorbereitung in vielen Betrieben hinterher. Dieser kostenlose Leitfaden zeigt Geschäftsführern und IT-Verantwortlichen, wie sie die IT-Sicherheit ihres Unternehmens mit proaktiven Maßnahmen nachhaltig stärken. Kostenlosen Sicherheits-Leitfaden jetzt herunterladen
Die Geschwindigkeit war atemberaubend: Die erste Infektion auf einem überwachten System wurde bereits 89 Sekunden nach der Veröffentlichung des bösartigen Pakets registriert.
Staatliche Akteure im Verdacht
Die hohe Professionalität und die Infrastruktur deuten auf staatlich geförderte Angreifer hin. Sicherheitsfirmen wie Google Threat Intelligence und Elastic Security Labs bringen die Attacke mit der mutmaßlich nordkoreanischen Gruppe UNC1069 in Verbindung. Diese ist für Angriffe auf die Krypto- und Softwareentwicklungsbranche bekannt. Der Vorfall folgt kurz auf einen ähnlichen Angriff auf das Python-Paket LiteLLM und könnte Teil einer größeren Kampagne gegen Open-Source-Maintainer sein.
Konsequenzen für die Software-Entwicklung
Der Vorfall zwingt die Community zum Umdenken. Sicherheitsexperten raten dringend dazu:
* Dependencies strikt festzuzurren (Pinning in Lockfiles) und nicht dynamisch aufzulösen.
* Regelmäßige Audits des Dependency-Baums auf unerwartete Pakete durchzuführen.
* Systeme, die während des dreistündigen Fensters die betroffenen Versionen installiert haben, als vollständig kompromittiert zu betrachten.
Die notwendigen Schritte sind radikal: Infizierte Maschinen isolieren, von vertrauenswürdigem Images neu aufsetzen und alle Zugangsdaten und Secrets rotieren, die während der Infektionszeit zugänglich waren. Die Branche wird den Druck erhöhen, manuelle Veröffentlichungen bei kritischen Paketen einzuschränken und OIDC-signierte Herkunftsnachweise zur Pflicht zu machen. Der Axios-Angriff zeigt: Selbst das vertrauenswürdigste Werkzeug in der Toolbox kann zur Waffe werden.
So schätzen die Börsenprofis Aktien ein!
Für. Immer. Kostenlos.
