Axios-Lieferkettenangriff:
Wie manipulierte npm-Pakete plattformübergreifend Schadsoftware verteilten
Ein neuer Supply-Chain-Angriff zeigt, wie verwundbar selbst die bekanntesten Open-Source-Bausteine in modernen Entwicklungsumgebungen sind.
Warum dieser Vorfall so brisant ist
Axios ist kein Nischenpaket, sondern eine Kernkomponente in unzähligen Webanwendungen, APIs, internen Tools und Unternehmensprojekten. Genau das macht einen Angriff auf dieses Paket so gefährlich: Wer ein populäres Modul kompromittiert, erreicht mit vergleichsweise wenig Aufwand sehr viele Ziele gleichzeitig.
Besonders kritisch war hier, dass die manipulierten Versionen nicht über ein offensichtliches Fake-Paket verteilt wurden, sondern direkt über das offizielle Axios-Paket auf npm erschienen. Für viele Entwickler und automatisierte Systeme wirkte das Update daher zunächst vollkommen legitim.
Was genau passiert ist
Nach aktuellem Stand wurden die npm-Zugangsdaten eines wichtigen Axios-Maintainers kompromittiert. Über dieses Konto veröffentlichten die Angreifer zwei schädliche Versionen des offiziellen Pakets:
In diesen Releases wurde kein auffälliger Schadcode direkt in die bekannte Axios-Logik eingebaut. Stattdessen gingen die Täter subtiler vor und ergänzten eine zusätzliche Abhängigkeit:
Genau diese Dependency enthielt die eigentliche Schadfunktion. Wer eine der manipulierten Axios-Versionen installierte, zog im Hintergrund automatisch auch das präparierte Zusatzpaket nach. Der Angriff setzte also nicht erst bei der Nutzung von Axios an, sondern bereits beim Installieren des Pakets.
Die Technik hinter dem Angriff
Besonders perfide war die Nutzung eines klassischen npm-Mechanismus: des postinstall-Hooks. Solche Hooks dürfen beim Installieren eines Pakets automatisch Skripte ausführen. In diesem Fall wurde der Mechanismus missbraucht, um einen plattformübergreifenden RAT-Dropper zu starten.
So funktioniert der Angriff
1. Einzige Änderung in [email protected] — Eine Zeile in package.json hinzugefügt
"dependencies": {
"follow-redirects": "^1.15.11",
"form-data": "^4.0.5",
"proxy-from-env": "^2.2.0",
+ "plain-crypto-js": "^4.2.1"
npm löst plain-crypto-js auf — sein
postinstall Hook läuft automatisch
3. setup.js desobfuskierte Strings, erkennt OS, kontaktiert C2
macOS
com.apple.act.mond
Windows
wt.exe + versteckte PowerShell
Linux
/tmp/ld1.py
4. Selbstzerstörung — löscht setup.js, tauscht sauberer package.json ein
👉 Die Angreifer veröffentlichten die bösartige Dependency zunächst in einer harmlosen Version und schoben erst später die manipulierte Fassung nach – ein klar strukturierter, geplanter Angriff.
Welche Systeme potenziell betroffen waren
Der Schaden beschränkt sich nicht auf lokale Entwickler-PCs. Potenziell betroffen waren alle Umgebungen, die in dem kurzen Zeitfenster eine frische Installation der schädlichen Axios-Versionen durchgeführt haben.
Entwicklerrechner
Lokale Maschinen mit npm install
Build-Server
Jenkins, GitLab Runner, GitHub Actions
CI/CD-Pipelines
Automatisierte Build- und Deployment-Prozesse
Container-Builds
Docker-Images mit npm-Dependencies
Testumgebungen
Staging-Systeme mit frischen Installationen
Deployment-Prozesse
Automatisierte Rollouts in Produktion
Die kritischen Versionen im Überblick
Kompromittiert
axios 1.14.1
axios 0.30.4
+ plain-crypto-js 4.2.1
Sichere Alternativen
axios 1.14.0
axios 0.30.3
Die bösartigen Versionen sowie die schädliche Zusatzabhängigkeit wurden inzwischen aus npm entfernt. Systeme, die die Pakete bereits installiert hatten, bleiben jedoch potenziell kompromittiert.
Zeitlicher Ablauf des Angriffs
Vorbereitung
plain-crypto-js 4.2.0 veröffentlicht
Unauffällige Version des Hilfspakets wird auf npm publiziert.
Manipulation
plain-crypto-js 4.2.1 mit Schadfunktion
Die Angreifer ersetzen das Paket durch eine Version mit postinstall-Hook und RAT-Dropper.
00:21 UTC
axios 1.14.1 veröffentlicht
Erste kompromittierte Axios-Version mit plain-crypto-js als Dependency.
01:00 UTC
axios 0.30.4 veröffentlicht
Zweiter Release-Zweig wird ebenfalls kompromittiert.
03:29 UTC
Schädliche Versionen entfernt
npm entfernt die manipulierten Pakete. Zeitfenster: ca. 3 Stunden.
Warum der Angriff so effektiv war
Der eigentliche Erfolg dieses Angriffs lag nicht nur in der Schadsoftware selbst, sondern in der Vertrauensposition, die ausgenutzt wurde. Entwickler, Build-Systeme und Security-Scanner vertrauen beliebten Paketen oft stillschweigend.
Wenn ein Update aus dem offiziellen npm-Feed kommt, wird es häufig automatisch oder zumindest ohne tiefere Prüfung übernommen. Genau diese Routine wurde hier missbraucht.
Schon das bloße Installieren reichte aus – keine Benutzerinteraktion nötig.
Was Unternehmen jetzt sofort tun sollten
Installationen prüfen
Kontrolliere package-lock.json, CI-Logs und Container-Builds auf die Versionen 1.14.1 und 0.30.4 sowie die Dependency plain-crypto-js.
Betroffene Systeme isolieren
Kompromittierte Hosts nicht nur updaten, sondern als potenziell kompromittiert behandeln und forensisch untersuchen.
Secrets rotieren
Alle Zugangsdaten auf betroffenen Systemen als abgeflossen betrachten: API-Keys, Cloud-Credentials, SSH-Keys, Build-Secrets.
Logs und Netzwerk auswerten
Build-Logs, EDR-Ereignisse, Shell-Historien und auffällige Verbindungen prüfen. C2-Bezüge forensisch analysieren.
Sichere Versionen pinnen
Bekannte sichere Axios-Versionen fixieren und automatische Upgrades ohne Freigabe vermeiden.
Lehren aus dem Vorfall
Der Axios-Fall ist ein Musterbeispiel dafür, dass Software-Sicherheit heute nicht mehr an der eigenen Codebasis endet. Besonders kritisch sind dabei:
⚠️ Kompromittierte Maintainer-Konten als Einstiegsvektor
⚠️ Automatisch ausgeführte Installationsskripte (postinstall-Hooks)
⚠️ Unkontrollierte Dependency-Updates in Build-Systemen
⚠️ Fehlende Absicherung von CI/CD-Pipelines und Build-Servern
⚠️ Zu weitreichender Zugriff von Secrets in Pipeline-Umgebungen
Fazit
Der kompromittierte Axios-Release zeigt in aller Deutlichkeit, wie effektiv moderne Supply-Chain-Angriffe geworden sind. Die Angreifer mussten keine Benutzer täuschen, keine Makros verschicken und keine Zero-Day-Lücke ausnutzen.
Sie nutzten das Vertrauen in ein offizielles Open-Source-Paket und kombinierten es mit automatischer Codeausführung während der Installation.
Wer Axios in seinen Projekten verwendet, sollte jetzt unverzüglich prüfen, ob die kompromittierten Versionen jemals in der eigenen Umgebung gelandet sind. In diesem Fall reicht ein simples Update nicht aus – dann geht es um Incident Response, forensische Prüfung und das konsequente Erneuern aller potenziell betroffenen Zugangsdaten.
Wasacon Insight
Wenn ein einziges npm install ausreicht, um Schadcode einzuschleusen, ist nicht mehr nur die Anwendung die Angriffsfläche – sondern die gesamte Entwicklungs- und Bereitstellungskette. Wer seine Dependencies nicht aktiv kontrolliert, riskiert den Zugriff auf seine gesamte Infrastruktur.
Ist deine Software-Lieferkette abgesichert?
Lass uns gemeinsam prüfen, ob deine Build-Systeme, CI/CD-Pipelines und Dependency-Prozesse gegen Supply-Chain-Angriffe geschützt sind.
Wasacon in deiner Region
Wasacon unterstützt Unternehmen in Heinsberg (52525), Erkelenz, Hückelhoven, Geilenkirchen, Aachen, Mönchengladbach, Jülich, Düren Rheydt (41236), Linnich (52441) und Krefeld bei der Absicherung gegen Supply-Chain-Angriffe und Software-Lieferkettenrisiken. Ob Dependency-Audits, CI/CD-Sicherheit oder Incident Response – wir helfen dir vor Ort und remote, deine Entwicklungs- und Build-Infrastruktur widerstandsfähig zu machen.
Häufig gestellte Fragen
Diskussion
0 Beiträge
IT-Budget Quick-Check
Wie viel sollte Ihr Unternehmen jährlich in IT investieren?
Risiko-Level: Mittel · Multiplikator: 1.2×
Richtwerte auf Basis von BSI/NIST/ENISA-Branchenbenchmarks. Keine verbindliche Empfehlung.
Das könnte Sie auch interessieren
IT-Sicherheitpm-energy gehackt? Qilin listet „Die Solarexperten“ aus Reesdorf im Darknet
Seit dem 9. August 2026 führt die Ransomware-Gruppe Qilin die pm-energy GmbH aus Reesdorf (Schleswig-Holstein) auf ihrer Leak-Seite. Was belegt ist, was Täterbehauptung bleibt – und warum Photovoltaik-Projektdaten besonders sensibel sind.
IT-SicherheitClausing Tiefbau gehackt? Qilin listet Osnabrücker Infrastruktur-Spezialisten im Darknet
Seit dem 8. August 2026 führt die Ransomware-Gruppe Qilin die Clausing GmbH Tiefbauunternehmen aus Osnabrück auf ihrer Darknet-Leak-Seite. Was belegt ist, was Täterbehauptung bleibt – und warum die digitalisierten Bauprozesse den Fall brisant machen.
IT-SicherheitThe Gentlemen listet INKA Group: Hinter der unscheinbaren Münchner Immobilienholding steckt ein weit größeres Firmengeflecht
Seit dem 7. August 2026 führt die Ransomware-Gruppe The Gentlemen die Münchner INKA Group GmbH & Co. KG als mutmaßliches Opfer. Register- und Konzerndaten zeigen ein verzweigtes Immobiliennetz – bis hin zur Hasen-Immobilien AG mit 230,5 Mio. € Bilanzsumme.
Haftungsausschluss: Die auf Wasacon bereitgestellten Inhalte dienen nur zu Informationszwecken. Wir garantieren nicht die Qualität, Genauigkeit oder Vollständigkeit der Informationen aus Drittquellen.
Sind Zugangsdaten Ihres Unternehmens bereits im Umlauf?
Wir prüfen Ihre Domain kostenlos gegen bekannte Infostealer- und Leak-Datenbanken – vertraulich und unverbindlich.
Bekannt aus
