Der Axios npm Supply Chain Hack: Was passiert ist, ob du betroffen bist und warum "just use fetch" zu kurz gedacht ist

Am 31. März 2026 wurde der npm-Account des Axios-Hauptmaintainers kompromittiert. Der Angreifer veröffentlichte innerhalb von 39 Minuten zwei vergiftete Versionen: axios@1.14.1 und axios@0.30.4. Betroffen war also nicht irgendein Fork oder ein dubioses Drittpaket, sondern das offizielle Paket auf npm.

Der eigentliche Axios-Code wurde dabei nicht verändert. Stattdessen wurde unauffällig eine neue Abhängigkeit in die package.json aufgenommen: plain-crypto-js@4.2.1. Das war ein Typosquat, der wie eine legitime Crypto-Bibliothek wirkte, in Wahrheit aber Schadcode nachlud.

Wie der Angriff funktionierte

Wer in dem betroffenen Zeitfenster npm install ausführte, zog nicht nur Axios, sondern auch die manipulierte Zusatzabhängigkeit. Diese enthielt ein postinstall-Script, das noch vor dem ersten eigenen Anwendungscode ausgeführt wurde und je nach Plattform einen passenden Dropper startete. Auf macOS lief die Auslieferung über AppleScript, auf Windows über PowerShell und auf Linux über ein per Shell nachgeladenes Python-Skript.

Besonders perfide war, dass sich die Malware nach der Ausführung selbst wieder aus dem Projekt entfernte. setup.js wurde gelöscht, Dateien wurden überschrieben und eine unauffällige Stub-Version blieb zurück. Dadurch sieht ein späterer Blick in node_modules oft sauber aus, obwohl das System bereits kompromittiert wurde.

Bin ich betroffen?

Wenn du herausfinden willst, ob du selbst betroffen warst, reicht es nicht, einfach in den installierten Dateien nachzusehen. Der erste sinnvolle Check ist das Lockfile. Tauchen dort axios@1.14.1 oder axios@0.30.4 auf, ist das ein klares Warnsignal. Zusätzlich solltest du prüfen, ob Builds oder lokale Installationen zwischen 00:21 und 03:15 UTC am 31. März 2026 gelaufen sind, denn genau in diesem Zeitfenster waren die bösartigen Versionen verfügbar.

Auch transitive Abhängigkeiten sind wichtig. Selbst wenn du Axios nicht direkt installiert hast, kann es über andere Pakete ins Projekt gekommen sein. Dazu kommt, dass in mehreren Analysen beschrieben wurde, dass auch abhängige Pakete als Einfallstor relevant waren.

Ebenso wichtig sind Netzwerk- und CI-Logs. Verbindungen zu packages.npm.org/product* sind ein starker Hinweis auf eine tatsächliche Ausführung der Payload. Wenn du solche Verbindungen siehst, solltest du den Vorfall wie einen echten Credential-Diebstahl behandeln und nicht wie einen bloßen Fehlalarm.

Falls du betroffen bist, hilft kein halbherziges Aufräumen. Das betroffene System gehört isoliert, und anschließend müssen alle möglicherweise exponierten Geheimnisse rotiert werden: API-Keys, SSH-Keys, Cloud-Credentials, npm-Tokens und GitHub-Tokens. Wichtig ist dabei nicht nur das Ändern, sondern das echte Revoken und Neuausstellen.

Sichere Axios-Versionen sind alle außer 1.14.1 und 0.30.4. Wer auf 1.14.0 oder 1.13.x gepinnt war, war nach den bisherigen Analysen nicht von der manipulierten Veröffentlichung betroffen.

Schneller Check

# npm
grep -E '"axios"' package-lock.json | grep -E '1\.14\.1|0\.30\.4'

# yarn
grep -E 'axios@' yarn.lock | grep -E '1\.14\.1|0\.30\.4'

# Suche nach der nachgeladenen Abhängigkeit
find node_modules -name "plain-crypto-js" -type d

Warum "just use fetch" zu kurz gedacht ist

Die reflexhafte Reaktion "just use fetch" ist dummes Geschwätz. Der Angriff hatte nichts mit der eigentlichen HTTP-Logik von Axios zu tun. Es war kein Bug in axios.get, kein Problem mit dem Request-Modell und auch kein Designfehler bei Interceptors. Der eigentliche Punkt war ein kompromittierter Publisher-Account in der npm Supply Chain. Dasselbe hätte prinzipiell jede andere populäre npm-Abhängigkeit treffen können.

Dazu kommt: Entwickler benutzen Axios nicht aus Nostalgie oder Bequemlichkeit, sondern weil es in echten Projekten konkrete Probleme sauber löst. Axios parst JSON automatisch, behandelt HTTP-Fehler sinnvoller, hat eingebaute Timeouts und bietet Interceptors als zentrales Muster für Auth, Logging, Retries und Request-Manipulation. fetch kann vieles davon auch, aber meist erst dann, wenn man sich selbst Wrapper, Helper und Fehlerbehandlung darum herum baut.

Warum Entwickler Axios benutzen

Gerade das Thema Interceptors ist in der Praxis ein Hauptgrund für Axios. In einer App mit JWT-Authentifizierung willst du den Access-Token nicht in jedem Request von Hand ergänzen. Du willst eine zentrale Stelle, an der Requests den aktuellen In-Memory-Token bekommen und bei einem 401 automatisch ein Token-Refresh passiert. Genau für solche Fälle ist Axios angenehm, weil das Muster direkt unterstützt wird.

Ein minimalistisches Beispiel sieht so aus:

const api = axios.create({ baseURL: '/api' })

api.interceptors.request.use((config) => {
  const token = getAccessToken() // In-Memory-Token, nicht localStorage
  if (token) config.headers.Authorization = `Bearer ${token}`
  return config
})

api.interceptors.response.use(
  (res) => res,
  async (error) => {
    if (error.response?.status === 401) {
      const newToken = await refreshToken()
      setAccessToken(newToken)
      error.config.headers.Authorization = `Bearer ${newToken}`
      return api.request(error.config)
    }
    return Promise.reject(error)
  },
)

Der Punkt an dem Beispiel ist nicht JWT-Architektur im Detail, sondern der praktische Nutzen: zentrale Request-Anpassung, zentrale Fehlerreaktion und weniger Boilerplate. Wer dann sagt "nimm einfach fetch", meint oft nur: bau dir das alles selbst.

Feature	`fetch`	`axios`
JSON-Parsing	Manuell mit `.json()`	Automatisch
HTTP-Fehler	`404` ist kein Exception-Fall	4xx und 5xx landen im Fehlerpfad
Interceptors	Nicht eingebaut	Direkt vorhanden
Timeout	Nur mit zusätzlicher Logik	Direkt unterstützt
Upload-Progress	Kaum praktikabel	Direkt nutzbar

Lessons Learned

Für die Praxis sind die Lessons Learned wichtiger als jede Technologiedebatte. In CI/CD sollte npm ci statt npm install laufen, damit nur exakt das aus dem Lockfile installiert wird. Für Buildumgebungen ist --ignore-scripts sinnvoll, weil damit postinstall-Hooks gar nicht erst ausgeführt werden. Kritische Dependencies sollten exakt gepinnt statt locker mit ^ oder ~ referenziert werden, und Dependency-Scanning mit Snyk, Socket.dev oder Dependabot gehört heute als fester Schritt in die Pipeline.

Die eigentliche Lehre aus dem Vorfall ist deshalb nicht "Axios schlecht, fetch gut". Die richtige Lehre ist: Supply Chain Sicherheit ist ein eigenes Thema. Wenn ein Maintainer-Account kompromittiert wird und darüber signierte Releases in den offiziellen Paketkanal gelangen, dann brauchst du Kontrollmechanismen in Build, Review und Deployment. Die Wahl der HTTP-Bibliothek löst dieses Problem nicht.