Ich mag Tools, die einfach funktionieren. Axios war lange so ein Kandidat: unspektakulär, weit verbreitet, zuverlässig. Eben die Art Bibliothek, über die man im Alltag kaum nachdenkt.
Aber wenn ausgerechnet eine Standard-Komponente in der Software-Lieferkette kompromittiert wird, zeigt sich brutal: Die größte Gefahr kommt nicht immer mit Blaulicht, Totenkopf und dramatischer Hacker-Musik. Manchmal kommt sie als ganz normales Update daher.
Am 31. März 2026 wurde die npm-Version von Axios Ziel eines Supply-Chain-Angriffs. Ein Angreifer kompromittierte den npm-Zugang des Haupt-Maintainers und veröffentlichte zwei manipulierte Versionen: axios@1.14.1 und axios@0.30.4. Diese Releases brachten eine zusätzliche, zuvor nicht vorhandene Abhängigkeit mit: plain-crypto-js@4.2.1.
Dieses Paket nutzte wiederum ein postinstall-Skript, um plattformübergreifend Schadcode nachzuladen. Betroffen waren damit Entwicklerrechner und potenziell auch Build-Systeme, CI/CD-Pipelines und produktive Umgebungen.
Für Nicht-Entwickler lässt sich das so übersetzen: Deine Anwendungen bestehen aus sehr vielen Bausteinen, die du nicht alle selbst schreibst. Stattdessen greifst du auf Open-Source-Pakete zurück. Das ist normal, sinnvoll und effizient. Problematisch wird es, wenn eines dieser Pakete manipuliert wird und die Schadfunktion automatisch mitinstalliert wird - quasi wie ein Ersatzteil, in dem schon ein Dietrich steckt.
Im Axios-Fall lief es genauso ab. Die manipulierten Versionen wurden nur ca. 3 Stunden lang über npm verteilt. Das klingt kurz, ist in der Praxis aber eine Ewigkeit, wenn Systeme automatisiert Abhängigkeiten aktualisieren oder Builds regelmäßig neue Pakete ziehen.
Huntress beobachtete erste Infektionen bereits 89 Sekunden nach Veröffentlichung der schädlichen Version. Insgesamt registrierte Huntress in diesem kurzen Zeitfenster mindestens 135 Endpunkte mit Kontakt zur Command-and-Control-Infrastruktur des Angreifers.
Weil er zeigt, dass moderne Angriffe nicht mehr zwingend deine Perimeter direkt angreifen. Sie gehen den Umweg über Vertrauen. Wenn ein populäres Paket in der Lieferkette kompromittiert wird, hebeln Angreifer genau den Prozess aus, den Teams aus guten Gründen automatisiert haben: schnell, effizient, standardisiert deployen.
Das ist der eigentliche Business-Schmerzpunkt. Nicht nur die Frage „Wurde Malware installiert?“, sondern auch:
Wer hat sie wann in welche Umgebung gezogen?
Welche Secrets könnten betroffen sein?
Welche Build-Artefakte wurden damit erstellt?
Und wie viele Systeme gelten danach nicht mehr als vertrauenswürdig?
Besonders heikel: Laut Huntress wurde die normale CI/CD-Publishing-Kette umgangen. Der Angreifer veröffentlichte direkt per npm-CLI unter Nutzung eines langlebigen Tokens. Selbst ein Maintainer mit aktivierter MFA war also nicht automatisch geschützt. Der genaue Weg der Kompromittierung war zum Veröffentlichungszeitpunkt noch unklar.
Laut Briefing und Huntress-Analyse war der Schadcode plattformübergreifend ausgelegt. Windows, Linux und macOS haben jeweils passende Payloads nachgeladen. Ziel war ein Remote-Access-Trojaner.
Oder vereinfacht gesagt: Fernsteuerung für Angreifer.
Die Malware konnte Systeme inventarisieren, Verbindungen zu einem C2-Server aufbauen, weitere Payloads starten und auf Dateien oder Prozesse zugreifen. Auf Windows wurden zusätzlich Persistenzmechanismen beobachtet.
Windows-Varianten arbeiteten mit verschleierten PowerShell-Aufrufen und sich unter anderem über wt.exe tarnten. Für Linux wurde ein Python-basierter Remote‑Access‑Trojaner (RAT) beschrieben, für macOS ein kompiliertes Binary.
Das ist wichtig, weil es zeigt: Der Angriff war nicht auf einen exotischen Spezialfall begrenzt, sondern auf breite Verwendbarkeit ausgelegt.
Kurz gesagt: Jede Umgebung, die in diesem Zeitfenster ein npm install oder automatisches Dependency-Update ausgeführt und dabei eine der kompromittierten Axios-Versionen gezogen hat.
Das betrifft nicht nur Entwickler-Laptops, sondern ebenso Build-Server, Testumgebungen, Runner in CI/CD-Pipelines und im schlimmsten Fall produktive Systeme.
Das macht Supply-Chain-Angriffe so unerquicklich: Sie treffen die komplette digitale Werkbank.
Der Fall ist kein Argument gegen Open Source. Er ist ein Argument gegen blindes Vertrauen in automatisierte Lieferketten. Open Source bleibt enorm wertvoll.
Aber: „Weit verbreitet“ ist kein Synonym für „unangreifbar“. Im Gegenteil. Je verbreiteter ein Paket ist, desto attraktiver wird es für Angreifer. Axios ist genau deshalb so interessant gewesen, weil es in unzähligen Projekten steckt - direkt oder transitiv.
Für IT-Entscheider heißt das: Supply-Chain-Security ist kein Nischenthema für Entwicklerromantiker mit Terminal-Fetisch. Es ist ein Governance-, Risiko- und Resilienzthema.
Wenn Systeme jede neue Paketversion ungeprüft mitnehmen, reicht ein kurzer Angriffszeitraum aus. Lockfiles begrenzen genau dieses Risiko, weil sie reproduzierbare Abhängigkeiten erzwingen. Huntress verweist ausdrücklich darauf, Lockfiles und Abhängigkeitslisten auf axios@1.14.1, axios@0.30.4 und plain-crypto-js zu prüfen.
Viele Unternehmen schützen produktive Server besser als ihre Build-Pipelines. Das ist ein Fehler. Wenn Schadcode bereits im Build landet, wird Sicherheit nachgelagert schnell zur Schadensbegrenzung. Der Axios-Fall zeigt, wie schnell kompromittierte Pakete in automatisierten Prozessen ausgeführt werden können.
Drei Stunden reichen locker. In hochautomatisierten Umgebungen sogar mehr als locker. Der erste beobachtete Treffer nach 89 Sekunden ist ein ziemlich deutlicher Hinweis darauf, wie wenig Reaktionszeit heute zwischen Veröffentlichung und Ausführung liegt.
Huntress empfiehlt, betroffene Systeme als kompromittiert zu behandeln. Das bedeutet: Secrets rotieren, Logs prüfen, IOCs nutzen, C2-Kommunikation untersuchen und betroffene Systeme notfalls neu aufsetzen statt kosmetisch „sauber zu klicken“.
Cybersecurity ist leider kein Bereich, in dem ein Neustart Charakterbildung ersetzt.
Ein paar praktische Fragen, die du mit deinem Team sofort klären solltest:
Wenn du auf mehrere dieser Fragen gerade mit „Äh, prinzipiell schon bestimmt irgendwo“ antwortest, ist das kein Weltuntergang. Aber ein ziemlich guter Anlass, das Thema jetzt sauber anzugehen.
Huntress empfiehlt, umgehend auf sichere Versionen zurückzugehen - konkret auf axios@1.14.0 für die 1.x-Linie beziehungsweise axios@0.30.3 für die 0.x-Linie - und zusätzlich Overrides oder Resolutions zu setzen, damit auch transitive Abhängigkeiten nicht wieder auf die schädlichen Versionen auflösen.
Außerdem sollte node_modules/plain-crypto-js entfernt und anschließend mit deaktivierten Skripten neu installiert werden. Werden RAT-Artefakte gefunden, lautet die Empfehlung ausdrücklich: nicht „in place“ bereinigen, sondern aus vertrauenswürdigen Images neu aufbauen.
Der Axios-Vorfall ist ein Weckruf, aber kein Grund zur Panik. Er zeigt, wie stark moderne IT auf Vertrauen in Software-Lieferketten basiert - und wie wichtig es ist, dieses Vertrauen technisch abzusichern.
Wer heute Cloud, Entwicklung und Betrieb zusammendenkt, muss auch Abhängigkeiten, Build-Prozesse und Secrets als Teil seiner Sicherheitsarchitektur behandeln.
Oder etwas weniger förmlich gesagt: Nicht jedes Update ist böse. Aber jedes Update verdient einen wachen Blick.
Gerade für IT-Entscheider liegt hier die eigentliche Chance. Wer jetzt Transparenz schafft, Prozesse vereinfacht und Sicherheitskontrollen sinnvoll in Entwicklung und Betrieb verankert, gewinnt mehr als nur Schutz. Er gewinnt Handlungsfähigkeit. Und die ist in der Cloud bekanntlich ziemlich viel wert.