Axios npm-Paket kompromittiert – Was Entwickler jetzt wissen müssen

Am 31. März 2025 wurde bekannt, dass zwei Versionen des beliebten npm-Pakets axios kompromittiert wurden. Betroffen sind die Versionen axios@1.14.1 und axios@0.30.4, die über einen gehackten Maintainer-Account auf npm veröffentlicht wurden. Die schadhaften Versionen enthielten einen versteckten Remote Access Trojan (RAT), der über eine manipulierte Abhängigkeit eingeschleust wurde.

Wichtig vorab: Wir bei Codana haben umgehend alle unsere Kundenprojekte geprüft und können Entwarnung geben – nach aktuellem Stand sind keine unserer Projekte betroffen. Wir nutzen axios in einigen Projekten, setzen jedoch auf gelockte Versionen und kontrollierte Update-Prozesse, die genau solche Szenarien abfangen.

In diesem Beitrag ordnen wir den Vorfall sachlich ein, erklären was passiert ist und welche Maßnahmen Entwicklerteams jetzt ergreifen sollten.

Axios ist mit über 60 Millionen wöchentlichen Downloads eines der meistgenutzten JavaScript-Pakete weltweit. Umso gravierender ist der Vorfall: Angreifer haben das npm- und GitHub-Konto des Lead-Maintainers jasonsaayman kompromittiert und darüber zwei manipulierte Versionen veröffentlicht.

Zeitlicher Ablauf:

• 30. März, 05:57 UTC – Das Paket plain-crypto-js@4.2.0 wird auf npm veröffentlicht (saubere Version als Tarnung)
• 30. März, 23:59 UTC – Die schadhafte Version plain-crypto-js@4.2.1 wird nachgeschoben
• 31. März, 00:21 UTC – axios@1.14.1 erscheint mit plain-crypto-js als versteckter Abhängigkeit
• 31. März, 01:00 UTC – axios@0.30.4 folgt 39 Minuten später
• 31. März, ca. 03:15 UTC – npm entfernt beide axios-Versionen
• 31. März, 04:26 UTC – npm ersetzt plain-crypto-js durch einen Sicherheits-Stub

Der Angriff wurde bewusst in den späten Nachtstunden (US-Zeit) durchgeführt, um die Reaktionszeit der npm-Administration zu verzögern.

Die Angreifer gingen mit bemerkenswerter Raffinesse vor. Der Ablauf im Detail:

1. Phantom-Abhängigkeit einschleusen

Die manipulierten axios-Versionen enthielten eine neue Abhängigkeit namens plain-crypto-js, die in keiner legitimen axios-Version jemals existierte. Dieses Paket wurde nie im Quellcode importiert – es diente ausschließlich dazu, bei der Installation einen postinstall-Hook auszulösen.

2. Plattform-spezifische Schadsoftware

Der postinstall-Hook startete ein verschleiertes Script (setup.js), das das Betriebssystem erkannte und plattformspezifische Payloads von einem Command-and-Control-Server (sfrclak.com:8000) nachlud:

• macOS: RAT wurde als /Library/Caches/com.apple.act.mond getarnt (imitiert Apple-Systemprozess)
• Windows: PowerShell-Kopie unter %PROGRAMDATA%\wt.exe (getarnt als Windows Terminal)
• Linux: Python-basierter RAT unter /tmp/ld.py

3. Spurenverwischung

Nach erfolgreicher Ausführung löschte sich setup.js selbst und ersetzte die manipulierte package.json durch eine saubere Version. Eine Inspektion von node_modules nach der Installation zeigte dadurch keinerlei Auffälligkeiten – ein besonders perfider Aspekt dieses Angriffs.

Da die Schadsoftware ihre Spuren verwischt, reicht ein Blick in node_modules nicht aus. Folgende Schritte helfen bei der Analyse:

1. Lockfile prüfen

Durchsuchen Sie Ihre package-lock.json oder yarn.lock nach plain-crypto-js. Wenn dieses Paket auftaucht, wurden Sie potenziell betroffen:

grep "plain-crypto-js" package-lock.json yarn.lock

2. Installierte axios-Version prüfen

npm ls axios

Falls Version 1.14.1 oder 0.30.4 angezeigt wird, handeln Sie umgehend.

3. Systemspuren prüfen

Untersuchen Sie Ihr System auf die bekannten RAT-Artefakte:

• macOS: /Library/Caches/com.apple.act.mond
• Windows: %PROGRAMDATA%\wt.exe
• Linux: /tmp/ld.py

4. Netzwerkverkehr analysieren

Prüfen Sie Firewall- und DNS-Logs auf Verbindungen zu sfrclak.com oder der IP 142.11.206.73.

Falls Artefakte gefunden werden: Rotieren Sie umgehend alle Zugangsdaten – npm-Tokens, SSH-Keys, Cloud-Credentials und API-Schlüssel.

Wenn Ihr Projekt die betroffenen Versionen verwendet hat, empfehlen wir folgende Schritte:

1. Auf sichere Version wechseln

npm install axios@1.14.0

Für Legacy-Projekte mit 0.x:

npm install axios@0.30.3

2. Schadhafte Abhängigkeit entfernen

rm -rf node_modules/plain-crypto-js

3. Versionen pinnen

Ergänzen Sie in Ihrer package.json unter overrides (npm) bzw. resolutions (yarn):

{
  "overrides": {
    "axios": "1.14.0"
  }
}

4. C2-Domain blockieren

Blockieren Sie sfrclak.com und 142.11.206.73 in Ihrer Firewall und Ihren DNS-Einstellungen.

5. CI/CD absichern

Erwägen Sie --ignore-scripts in Ihren CI/CD-Pipelines, um postinstall-Hooks zu unterbinden, die nicht explizit benötigt werden.

Dieser Vorfall reiht sich in eine wachsende Liste von Supply-Chain-Angriffen auf das npm-Ökosystem ein. Die Angriffsfläche ist enorm: Moderne JavaScript-Projekte haben typischerweise hunderte bis tausende transitive Abhängigkeiten. Jede einzelne davon ist ein potenzieller Angriffsvektor.

Was diesen Angriff besonders macht:

• Kompromittierung eines Top-10-Pakets: Axios gehört zu den am häufigsten installierten npm-Paketen überhaupt
• Account-Übernahme statt Typosquatting: Der Angriff nutzte einen echten, vertrauenswürdigen Maintainer-Account
• Mehrstufige Spurenverwischung: Selbstlöschende Scripts, gefälschte Paketmanifeste und plattformspezifische Payloads
• Gezieltes Timing: Veröffentlichung in den Nachtstunden, um das Zeitfenster bis zur Entdeckung zu maximieren

Die gute Nachricht: Die Community hat schnell reagiert. Innerhalb weniger Stunden waren die schadhaften Versionen entfernt und die betroffenen Pakete durch Sicherheits-Stubs ersetzt.

Aus diesem Vorfall lassen sich wichtige Lehren für die Absicherung von Softwareprojekten ableiten:

Dependency Management

• Versionen pinnen: Nutzen Sie exakte Versionsnummern statt Ranges ("axios": "1.14.0" statt "axios": "^1.14.0"). So verhindern Sie, dass kompromittierte Patch-Versionen automatisch installiert werden.
• Lockfiles committen: package-lock.json und yarn.lock gehören ins Repository. Sie stellen sicher, dass alle Teammitglieder und CI/CD-Pipelines identische Abhängigkeiten installieren.
• Regelmäßige Audits: Nutzen Sie npm audit und Tools wie Snyk oder Socket zur kontinuierlichen Überwachung.

CI/CD-Härtung

• Verwenden Sie npm ci statt npm install in Build-Pipelines (installiert exakt die Versionen aus dem Lockfile)
• Erwägen Sie Tools wie StepSecurity Harden-Runner, die verdächtige Netzwerkaktivitäten während des Builds erkennen
• Implementieren Sie einen Review-Prozess für Dependency-Updates

Organisatorische Maßnahmen

• Aktivieren Sie Zwei-Faktor-Authentifizierung für alle npm- und GitHub-Accounts
• Nutzen Sie npm-Organisationen mit granularen Zugriffsrechten
• Definieren Sie eine Richtlinie für den Umgang mit Security-Advisories

Transparenz ist uns wichtig – deshalb kommunizieren wir diesen Vorfall offen, auch wenn unsere Projekte nach aktuellem Kenntnisstand nicht betroffen sind.

Unser Vorgehen bei diesem Vorfall:

1. Sofortige Prüfung aller aktiven Projekte auf die betroffenen axios-Versionen und die schadhafte Abhängigkeit plain-crypto-js
2. Analyse der Lockfiles und Dependency-Trees in allen Kundenprojekten
3. Überprüfung der CI/CD-Pipelines auf mögliche Kompromittierung
4. Proaktive Kommunikation an unser Entwicklerteam mit konkreten Handlungsanweisungen

Ergebnis: Wir haben derzeit keinen Hinweis darauf, dass ein Kundenprojekt von Codana betroffen ist.

Wir nutzen in unseren Projekten konsequent gepinnte Versionen und gelockte Abhängigkeiten, was genau für solche Szenarien eine effektive Schutzschicht bildet. Zusätzlich setzen wir auf kontrollierte Update-Zyklen, bei denen Abhängigkeitsupdates manuell geprüft werden, bevor sie in Produktionscode einfließen.

Sollten bei der weiteren Analyse neue Erkenntnisse auftauchen, werden wir betroffene Kunden selbstverständlich umgehend und direkt informieren.

Der axios-Vorfall zeigt einmal mehr, wie wichtig ein professionelles Dependency Management ist. Supply-Chain-Angriffe sind kein theoretisches Risiko – sie treffen reale Projekte und können erheblichen Schaden anrichten.

Die wichtigsten Takeaways:

• Keine Panik, aber Sorgfalt: Prüfen Sie Ihre Projekte auf die betroffenen Versionen und handeln Sie bei Bedarf
• Versionen pinnen: Automatische Updates von Abhängigkeiten sind bequem, aber gefährlich
• Lockfiles ernst nehmen: Sie sind Ihr erster Schutzschild gegen Supply-Chain-Angriffe
• Security als Prozess: Regelmäßige Audits und ein definierter Umgang mit Advisories schützen langfristig

Als Softwareagentur sehen wir es als unsere Verantwortung, nicht nur funktionale, sondern auch sichere Software zu entwickeln. Wenn Sie Fragen zur Sicherheit Ihrer Projekte haben oder eine Überprüfung Ihrer Abhängigkeiten wünschen, sprechen Sie uns gerne an.