axios kompromittiert: Remote-Access-Trojaner in einer der meistgenutzten JS-Bibliotheken
Ende März wurden über ein gekapertes Maintainer-Konto manipulierte Versionen der HTTP-Bibliothek axios veröffentlicht, die einen Remote-Access-Trojaner installierten. Wir erklären, was passiert ist, wie Sie Ihre Projekte prüfen und wie Sie Ihre npm-Installationen dauerhaft absichern.
Was ist passiert?
Am 31. März 2026 erschienen auf npm die Versionen axios@1.14.1 und axios@0.30.4. Veröffentlicht wurden sie über das Konto eines der Hauptmaintainer, das die Angreifer zuvor übernommen hatten. Laut StepSecurity wurde die hinterlegte E-Mail-Adresse auf eine ProtonMail-Adresse der Angreifer geändert; die Pakete wurden manuell veröffentlicht, am regulären CI/CD-Prozess des Projekts vorbei. Nach dem Post-Mortem des Maintainers ging der Übernahme gezieltes Social Engineering voraus.
Am Quellcode von axios selbst änderte sich nichts. Die manipulierten Versionen fügten lediglich eine neue Abhängigkeit hinzu: plain-crypto-js@4.2.1. Deren postinstall-Skript lud je nach Betriebssystem einen Trojaner für macOS, Windows oder Linux nach und verwischte anschließend seine Spuren, indem es die eigene package.json durch eine saubere Version ersetzte. Eine harmlose Vorversion des Pakets war bereits rund 18 Stunden vorher veröffentlicht worden, um unauffälliger zu wirken.
npm entfernte die beiden axios-Versionen nach etwa zwei bis drei Stunden. Laut Techzine wird axios wöchentlich mehr als 300 Millionen Mal heruntergeladen – selbst ein kurzes Zeitfenster reicht also für eine große Zahl betroffener Installationen.
Warum betrifft Sie das?
axios steckt in unzähligen Web-Frontends, Node.js-Backends und Build-Werkzeugen, oft auch als indirekte Abhängigkeit. Der Schadcode lief bereits während npm install – auf Entwicklerrechnern ebenso wie in CI-Pipelines. Dort liegen typischerweise genau die Daten, die Angreifer suchen: npm-Tokens, Cloud-Zugangsdaten, SSH-Schlüssel und Deployment-Secrets.
Was Sie jetzt tun sollten
- Lockfiles prüfen: Suchen Sie in allen Repositories nach den betroffenen Versionen und nach dem Paket
plain-crypto-js:
# Installierte axios-Versionen (auch indirekte) anzeigen
npm ls axios plain-crypto-js --all
# Lockfiles nach dem Schadpaket durchsuchen
grep -rn "plain-crypto-js" \
--include=package-lock.json --include=yarn.lock --include=pnpm-lock.yaml .
- Spuren suchen: Ein Verzeichnis
node_modules/plain-crypto-jszeigt laut StepSecurity, dass der Dropper ausgeführt wurde – auch wenn diepackage.jsondarin harmlos aussieht. - Zurück auf sichere Versionen: Verwenden Sie
axios@1.14.0bzw.axios@0.30.3und erzwingen Sie diese bei Bedarf peroverridesin derpackage.json. - Betroffene Systeme als kompromittiert behandeln: Wurde eine der Versionen installiert, sollten Sie den Rechner neu aufsetzen und sämtliche dort verfügbaren Zugangsdaten von einem sauberen System aus rotieren. Bei CI-Runnern betrifft das alle Secrets des jeweiligen Laufs.
- Install-Skripte in CI abschalten: Viele Projekte brauchen keine
postinstall-Skripte. Installieren Sie in Pipelines reproduzierbar aus dem Lockfile:
npm ci --ignore-scripts
- Wartezeit für neue Versionen einführen: Manipulierte Releases werden meist innerhalb von Stunden entdeckt. Eine Mindestwartezeit („Cooldown") verhindert, dass brandneue Versionen sofort installiert werden. In pnpm etwa per
pnpm-workspace.yaml(Angabe in Minuten):
minimumReleaseAge: 10080 # 7 Tage
Vergleichbare Einstellungen gibt es laut StepSecurity auch für npm, Yarn und Bun; Dependabot und Renovate lassen sich ebenfalls so konfigurieren, dass neue Versionen erst nach einigen Tagen vorgeschlagen werden.
Fazit
Der axios-Vorfall zeigt erneut, dass ein einziges gekapertes Maintainer-Konto genügt, um Millionen Projekte zu gefährden. Feste Versionen im Lockfile, deaktivierte Install-Skripte in der Pipeline und eine Wartezeit für neue Releases senken das Risiko deutlich – und kosten im Alltag kaum Aufwand. Wenn Sie Ihre JavaScript-Projekte und Build-Prozesse entsprechend absichern möchten, sprechen Sie uns an.