Axios Supply-Chain-Angriff: Was passiert ist, was Sie jetzt tun sollten — und wie wir unsere Projekte schützen

Nein, das ist leider kein Aprilscherz. Am 31. März 2026 wurde das npm-Paket Axios — eine der meistgenutzten JavaScript-Bibliotheken mit über 100 Millionen wöchentlichen Downloads — durch einen gezielten Supply-Chain-Angriff kompromittiert. Innerhalb von nur dreieinhalb Stunden wurden zwei manipulierte Versionen veröffentlicht, die einen plattformübergreifenden Remote Access Trojan (RAT) auf betroffene Systeme installierten. Google Threat Intelligence ordnet den Angriff der nordkoreanischen Gruppe UNC1069 zu.

Dieser Artikel fasst zusammen, was passiert ist, wie Sie prüfen können, ob Sie betroffen sind, welche Sofortmaßnahmen nötig sind — und welche langfristigen Maßnahmen die Angriffsfläche nachhaltig reduzieren.

Was ist passiert?

Ein Angreifer hat den npm-Account des Axios-Hauptmaintainers übernommen — nicht durch Typosquatting oder einen Fake-Fork, sondern durch einen gestohlenen, langlebigen Access Token. Mit diesem Zugang wurden zwei manipulierte Versionen direkt im offiziellen Paket veröffentlicht:

Kompromittierte Version	Sichere Version
axios 1.14.1	1.14.0
axios 0.30.4	0.30.3

Der Angriff war methodisch vorbereitet: Rund 18 Stunden vor der eigentlichen Attacke wurde ein harmloses Decoy-Paket plain-crypto-js@4.2.0 veröffentlicht. Kurz vor dem Angriff folgte die manipulierte Version 4.2.1 — die dann als neue Abhängigkeit in die kompromittierten Axios-Versionen eingefügt wurde.

Das Besondere: plain-crypto-js wurde nirgends im Axios-Quellcode importiert. Der einzige Zweck war ein postinstall-Script (setup.js), das beim npm install automatisch ausgeführt wurde. Dieses Script installierte einen plattformübergreifenden RAT — auf macOS, Windows und Linux — der alle 60 Sekunden an einen Command-and-Control-Server berichtete.

Nach der Ausführung löschte sich das Script selbst und stellte eine sauber aussehende Dateistruktur wieder her — ein bewusstes Anti-Forensik-Vorgehen.

Die Sicherheitsfirma Socket.dev erkannte die Malware rund sechs Minuten nach Veröffentlichung. Insgesamt waren die manipulierten Versionen etwa dreieinhalb Stunden im npm-Registry verfügbar (23:59 bis 03:30 UTC).

Sind Sie betroffen?

Prüfen Sie die folgenden Punkte:

1. Lockfile prüfen

Suchen Sie in Ihrem package-lock.json, pnpm-lock.yaml oder yarn.lock nach den Versionen 1.14.1 oder 0.30.4 von Axios.

2. Malicious Dependency prüfen

Existiert ein Verzeichnis node_modules/plain-crypto-js in Ihrem Projekt? Dieses Paket sollte in keinem legitimen Projekt vorhanden sein.

3. RAT-Artefakte prüfen

Je nach Betriebssystem könnten folgende Dateien auf eine Infektion hinweisen:

• macOS: Prüfen Sie mit ls -la /Library/Caches/com.apple.act.mond ob die RAT-Binary vorhanden ist
• Windows: Prüfen Sie mit dir "%PROGRAMDATA%\wt.exe" und dir "%PROGRAMDATA%\system.bat" ob RAT-Artefakte vorhanden sind. Zusätzlich prüfen Sie, ob ein persistenter Registry-Eintrag angelegt wurde: reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v MicrosoftUpdate
• Linux: Prüfen Sie mit ls -la /tmp/ld.py ob das RAT-Script vorhanden ist

4. Netzwerk-Logs prüfen

Suchen Sie nach ausgehenden Verbindungen zu sfrclak[.]com auf Port 8000.

Wenn einer dieser Punkte zutrifft, behandeln Sie das betroffene System als vollständig kompromittiert.

Sofortmaßnahmen bei Betroffenheit

1. Betroffene Systeme sofort isolieren — Netzwerkverbindung trennen
2. Axios auf eine sichere Version downgraden — 1.14.0 bzw. 0.30.3
3. Malicious Dependency entfernen — node_modules/plain-crypto-js löschen
4. Alle Credentials rotieren — npm-Tokens, AWS-Keys, SSH-Schlüssel, CI/CD-Secrets, API-Keys, Cloud-Zugangsdaten
5. CI/CD-Logs prüfen — Wurden die kompromittierten Versionen in Ihren Pipelines installiert?
6. Systeme neu aufsetzen — Bei einem RAT reicht ein In-Place-Cleanup nicht aus. Betroffene Systeme sollten von einem sauberen Snapshot neu aufgebaut werden

Langfristiges Hardening

Die gute Nachricht: Es gibt konkrete Maßnahmen, die diesen Angriff verhindert oder seine Auswirkungen drastisch reduziert hätten. Diese Empfehlungen gelten für jedes Projekt mit npm-Abhängigkeiten.

Minimum Release Age — die „Quarantäne" für neue Pakete

Mehrere Paketmanager unterstützen mittlerweile eine Mindest-Veröffentlichungsdauer. Pakete, die innerhalb dieses Zeitfensters veröffentlicht wurden, werden nicht installiert. Bei einem Angriffsfenster von dreieinhalb Stunden hätte eine 3-Tage-Quarantäne den Angriff vollständig blockiert.

Paketmanager	Konfiguration	Einstellung
npm (ab v11.10)	.npmrc	min-release-age=3d
pnpm (ab v10.16)	.npmrc	minimum-release-age=3d
Yarn (ab v4.10)	.yarnrc.yml	npmMinimalAgeGate: "3d"
Bun (ab v1.3)	bunfig.toml	minimumReleaseAge = 259200

Postinstall-Scripts in CI deaktivieren

Der gesamte Angriff basierte darauf, dass npm beim Installieren automatisch das postinstall-Script ausführte. In CI/CD-Pipelines sollten Sie diese Scripts grundsätzlich deaktivieren:

Paketmanager	Befehl
npm	npm ci --ignore-scripts
pnpm	pnpm install --frozen-lockfile --ignore-scripts
Yarn	yarn install --immutable --mode=skip-build
Bun	bun install --ignore-scripts

Keine Script-Ausführung bedeutet: Selbst wenn eine kompromittierte Dependency aufgelöst wird, kann sie keinen Schadcode ausführen.

Lockfile-Enforcement

Verwenden Sie in CI immer npm ci oder pnpm install --frozen-lockfile statt npm install. So wird exakt das installiert, was im Lockfile steht — nicht das, was latest gerade auflöst.

Cooldown für automatisierte Dependency-Updates

Automatisierte Dependency-Update-Tools wie Dependabot oder Renovate können so konfiguriert werden, dass sie nicht sofort PRs für frisch veröffentlichte Versionen erstellen:

# .github/dependabot.yml
cooldown:
  default: 3

// renovate.json
{
  "minimumReleaseAge": "3 days"
}

Das schafft ein Zeitfenster, in dem kompromittierte Versionen erkannt und zurückgezogen werden können, bevor sie automatisch in Ihr Projekt gelangen.

OIDC Trusted Publishing — aber richtig

Ein bemerkenswertes Detail dieses Angriffs: Das Axios-Projekt hatte OIDC Trusted Publishing konfiguriert — der Publish-Workflow übergab aber gleichzeitig einen NPM_TOKEN als Umgebungsvariable. Wenn beides vorhanden ist, verwendet npm den Token und umgeht OIDC komplett. Die Lehre: Langlebige Tokens vollständig entfernen, wenn OIDC konfiguriert ist.

Wie wir bei HAINTZ IT-SOLUTIONS die Angriffsfläche reduzieren

Die oben genannten Maßnahmen sind ein solides Fundament. In unseren Projekten gehen wir darüber hinaus und setzen auf mehrere Ebenen:

Isolierte Entwicklungsumgebungen mit DevContainers

Unsere Entwicklungsumgebungen laufen in DevContainers — standardisierte, isolierte Container, die den gesamten Entwicklungskontext kapseln. Das bedeutet: Selbst wenn ein Postinstall-Script ausgeführt wird und Schadcode enthält, bleibt der Schaden auf den Container beschränkt. Der RAT aus dem Axios-Angriff versuchte, Dateien in Systempfade wie /Library/Caches/ oder %PROGRAMDATA% zu schreiben — in einem DevContainer gibt es diese Pfade nicht, und der Container wird beim nächsten Rebuild ohnehin verworfen.

Secrets nur zur Laufzeit — mit 1Password CLI

Ein zentraler Zweck des Axios-RAT war das Abgreifen von Credentials. Viele Projekte speichern Secrets in .env-Dateien oder als dauerhafte Umgebungsvariablen — ein leichtes Ziel für jede Malware, die Umgebungsvariablen auslesen oder das Dateisystem durchsuchen kann.

Wir verwenden stattdessen die 1Password CLI, die Secrets erst zur Laufzeit in den jeweiligen Prozess injiziert. Secrets berühren nie die Festplatte, liegen nie in .env-Dateien und sind nicht als dauerhafte Umgebungsvariablen verfügbar. Das reduziert das Exfiltrations-Risiko erheblich.

SBOMs und Dependency Track — wissen, was man ausliefert

Eine Software Bill of Materials (SBOM) ist ein maschinenlesbares Inventar aller Komponenten und Abhängigkeiten, die in einer Software enthalten sind. In Kombination mit einem Tool wie Dependency Track entsteht ein kontinuierliches Monitoring: Wenn eine Abhängigkeit als kompromittiert gemeldet wird, wissen wir innerhalb von Minuten, welche unserer Projekte betroffen sind — und können gezielt reagieren, statt tagelang manuell durch Repositories zu suchen.

Fazit

Supply-Chain-Angriffe wie der auf Axios zeigen, dass die größte Schwachstelle oft nicht im eigenen Code liegt, sondern in den Abhängigkeiten. Kein Setup ist perfekt — aber mit den richtigen Maßnahmen lässt sich die Angriffsfläche erheblich reduzieren und die Reaktionszeit von Wochen auf Stunden verkürzen.

Die in diesem Artikel beschriebenen Hardening-Maßnahmen sind ein guter Ausgangspunkt. Wenn Sie darüber hinaus Unterstützung bei der Absicherung Ihrer Entwicklungspipeline benötigen — von DevContainer-Setups über Secret Management bis hin zu SBOM-Integration — sprechen Sie uns an. Wir helfen bei der Analyse und Umsetzung.

---

Quellen: Huntress · Snyk · Socket.dev · Google Cloud Threat Intelligence · StepSecurity