Supply-Chain-Angriffe: Vertrauen ist gut, Lockfile ist besser

axios ist ein HTTP-Client für JavaScript mit über hundert Millionen Downloads pro Woche Am 31. März 2026, um 00:21 UTC, erschien axios@1.14.1 lautlos im npm-Registry, diese Version war kompromittiert. Laut der offiziellen axios-Stellungnahme hatte der Angreifer zuvor mit einer Social-Engineering-Kampagne und RAT-Malware Zugriff auf den PC des Lead-Maintainers bekommen und so dessen npm-Zugangsdaten gestohlen. Drei Stunden später lud jede Build-Pipeline der Welt, die npm install gegen das neueste Release laufen ließ, einen nordkoreanischen RAT herunter. Die schädliche axios-Version blieb 174 Minuten auf npm. Wer in dieser Zeit nicht zum Opfer wurde, hat das oft einem unscheinbaren Detail zu verdanken: Dem Unterschied zwischen npm install und npm ci.

Diese drei Stunden fassen die Supply-Chain-Security 2025/2026 ganz gut zusammen. Kein Zero-Day, kein Buffer Overflow. Es genügen ein Mensch, ein vertrauenswürdiger Account und eine Registry, die fremden Code bei der Installation ausführt. Allein in den letzten sechs Monaten haben Angreifer axios, @bitwarden/cli, die komplette @tanstack/*-Familie, das offizielle mistralai-SDK auf npm und PyPI, Aqua Securitys Trivy-Scanner, die checkmarx/ast-github-action und hunderte weitere Pakete kompromittiert, die der selbstreplizierende Shai-Hulud-Wurm eingesammelt hat.

Dieser Artikel ist die Langfassung eines Webinars von uns. Die Aufzeichnung ist unten eingebettet, der Text danach geht tiefer ins Detail:

Inhalt

1. Warum die Lieferkette der neue Perimeter ist
2. Warum npm der gefährlichste Vertreter ist
3. Die Welle 2025/2026
4. Wie man die Angriffe verhindert
5. Jetzt / Bald / Später

1. Warum die Lieferkette der neue Perimeter ist

Die meisten Teams arbeiten immer noch mit der Annahme „wir patchen das, was in unserem Repo liegt". Die typische produktive Node.js-Anwendung besteht aber aus nur rund 3 % eigenem Code und 97 % Open-Source-Abhängigkeiten, oft hunderte Pakete tief. Die eigentliche Angriffsfläche liegt damit nicht mehr im Repository, sondern im Vertrauensgraph, der dort endet.

Die Mechanik eines modernen Supply-Chain-Angriffs passt problemlos in ein Diagramm:

Jeder einzelne Schritt ist banal. Kombiniert umgehen sie jede Perimeter-Kontrolle der Organisation, weil kein einzelner Traffic-Anteil bösartig aussieht: Die Entwicklerin hat ein bekanntes Paket aus einer bekannten Registry über TLS gezogen, einen bekannten Build-Befehl ausgeführt, und die Installation lief ohne Fehler durch. Das erste Signal, dass etwas schief läuft, ist meistens ein Credential, das irgendwo auftaucht, wo es nicht hingehört.

Genau hier versagt klassisches Dependency-Tooling. npm audit und OSV-Scanner sind reaktiv und schlagen bekannte Advisories nach. In allen Vorfällen 2026, die wir gleich aufzeigen, existierte stundenlang nach dem Upload der schädlichen Version gar kein Advisory. Geschützt waren nur Teams, die sich vorab entschieden hatten, fremden Code nicht automatisch auszuführen.

2. Warum npm besonders angreifbar ist

Jeder moderne Paketmanager hat eine Variante dieses Problems. pip führt setup.py zur Installationszeit aus, NuGet startet MSBuild-Targets, Maven lädt Plugins, GitHub Actions injiziert Shell-Skripte in die Pipeline. Folgende Eigenschaften machen npm zu einem besonders attraktiven Angriffsziel:

• 3 Millionen+ Pakete, mit Milliarden Downloads pro Woche.
• Lifecycle-Skripte (preinstall, install, postinstall) laufen ohne Bestätigung, ohne Sandbox und mit den vollen Rechten dessen, der npm aufgerufen hat. Oft ist das ein CI-Runner mit Cloud-Credentials.
• Floating Versions als Default. ^1.14.0 löst zum Installations- zeitpunkt auf, was gerade aktuell ist, inklusive eines schädlichen Releases, das vor sechs Minuten gepusht wurde.
• Hunderte transitive Abhängigkeiten hinter jeder direkten. Der Median liegt bei rund 83 Paketen für eine Node-App (arXiv 2512.14739). Niemand liest die alle, niemand kann das.

Zum Vergleich Go-Module: keine Install-Hooks (go build kompiliert nur), die Registry ist immutable (proxy.golang.org cacht Versionen für immer, Takedowns ändern die Historie nicht), und mit sum.golang.org gibt es ein globales Transparency-Log, gegen das go mod verify jede Manipulation nachweist. Gleiches Problem, völlig andere Lösung. Sicherheit ist eben eine Design-Entscheidung, und npm hat die gegenteilige getroffen.

Der Sonatype Open Source Malware Index Q2 2025 weist einen Anstieg bösartiger Open-Source-Pakete um +188 % gegenüber dem Vorjahr aus. Dieser Anstieg taucht in den Schlagzeilen 2026 wieder auf.

3. Die Welle 2025/2026

Kurze Timeline zur Einordnung. Die Vorfälle 2026 sind keine Einzelfälle, sondern der Zwischenstand einer mehrjährigen Entwicklung:

Im Folgenden gehen wir durch, was an jedem Vorfall 2026 wirklich neu war. Technisch anspruchsvoll war keiner. Nicht Schwachstellen, sondern das Vertrauensmodell wurden ausgenutzt.

Shai-Hulud — der selbstreplizierende npm-Wurm

Im September 2025 veröffentlichte die Gruppe TeamPCP den ersten selbstreplizierenden npm-Wurm. StepSecurity taufte ihn Shai-Hulud. Wenn man den Mechanismus einmal gesehen hat, fragt man sich, warum das nicht früher jemand gebaut hat:

Jedes Paket, für welches das Opfer Schreibrechte hat, bekommt eine neue, bösartige Version. Nach der Erstinfektion braucht der Wurm keinen weiteren Angreiferkontakt, und das Aufräumen ist mühsam: Jede vergiftete Version muss gefunden und zurückgezogen werden, über alle Scopes und Maintainer hinweg.

Bislang drei benannte Wellen:

• Welle 1 (Sep 2025): 500+ Pakete kompromittiert. CISA veröffentlichte eine sektorweite Warnung.
• Welle 2, „Second Coming" (Nov 2025): GitHub-basierter C2-Dead-Drop, ~25 000 Repositories betroffen (Wiz-Analyse).
• Welle 3, „Third Coming" (Apr 2026): Erster in-the-wild Angriff auf AI-Coding-Assistenten. Lief über die Bitwarden-CLI-Kompromittierung (siehe weiter unten) herein.

Eine vierte Kampagne mit anderem Angriffsvektor, „Mini Shai-Hulud" getauft, schlug im Mai 2026 zu (TanStack / Mistral AI). Dazu kommen wir gleich separat.

Axios — Phishing im Startup-Hoodie

axios ist der meistgenutzte HTTP-Client auf npm: ~100 Millionen Downloads pro Woche, transitiv in rund 30 % aller Node-Anwendungen. axios ist so allgegenwärtig, dass viele Teams erst durch diesen Vorfall merkten, dass sie es verwenden.

Am 31. März 2026 wurde der Maintainer auf Slack von jemandem angeschrieben. Dem Anschein nach der technische Co-Founder eines Early-Stage-Payments-Startups. Gebrandeter Workspace, echte Domain, echte Landing-Page, wochenlanges Hin und Her in niedriger Frequenz. Nachdem genug Vertrauen aufgebaut war, wechselte der Kontakt in einen Teams-Call und bat um Hilfe beim Debugging einer Integration. „Könntest du kurz diese Binary laufen lassen?" Der Maintainer tat das. Laut dem offiziellen Post-Mortem handelte es sich um RAT-Malware, die Zugriff auf seinen PC erlangte und seine npm-Zugangsdaten stahl.

Die Attribution lautet UNC1069 / Sapphire Sleet, eine DPRK-nahe Gruppe mit einem Toolkit, das mindestens bis 2018 zurückreicht (Google GTIG). Sie betreiben genau dieses Fake-Recruiter-/Fake-Startup-Schauspiel seit 2023 auf LinkedIn und Slack. Interessant ist, dass der Angriff an keiner Stelle einen technischen Exploit gebraucht hat. Die ganze Kette war Beziehungsaufbau.

Auch die Payload ist sehenswert. Statt den schädlichen Code in axios selbst zu verstecken (wo ihn ein halbwegs aufmerksamer Reviewer gefunden hätte), legte der Angreifer ein neues „Schwesterpaket" plain-crypto-js an, einen Typo-Squat des legitimen crypto-js. Daran hing der postinstall-Hook:

  "dependencies": {
+   "plain-crypto-js": "4.2.1",
  },
  "scripts": {
+   "postinstall": "node ./node_modules/plain-crypto-js/.bin/init"
  }

Der Schadcode droppte WAVESHAPER.V2, einen Cross-Platform-RAT für macOS, Windows und Linux. Microsoft, Elastic, Snyk, Huntress und Datadog haben innerhalb von 48 Stunden parallel technische Analysen veröffentlicht.

Wer ist davongekommen? Jeder, der npm ci gegen ein committetes Lockfile laufen ließ, jeder mit ignore-scripts=true und jeder hinter einem internen Registry-Proxy, der frische transitive Pakete in Quarantäne gestellt hat. Wie in der Einleitung gesagt: die langweiligen Kontrollen haben die ganze Arbeit gemacht.

Bitwarden CLI — wenn die Lieferkette selbst der Angreifer ist

Vier Wochen nach axios, am 22. April 2026, schlug TeamPCP erneut zu. Diesmal gab es keinen Maintainer zum Phishen. Der gesamte Angriff fand innerhalb von CI statt und ist das sauberste Beispiel, das wir für einen Lieferketten-in-Lieferketten-Vorfall haben.

Das schädliche Release stand 90 Minuten auf npm (17:57 bis 19:30 ET) und kam auf 334 Downloads. Klingt wenig, aber @bitwarden/cli wird vor allem von CI-Bots in SecOps-Pipelines gezogen, also von den wertvollsten Installationen der Registry. Wichtig: Der Bitwarden-Tresor wurde nicht kompromittiert. Betroffen war nur der npm-Distributionspfad (Statement).

Die Payload selbst betrat in zwei Punkten Neuland. Erstens war sie wurm-tauglich: Sie sammelte Credentials für AWS, GCP, Azure, GitHub-PATs, npm-Tokens und kubeconfig ein, packte die Beute in RSA-verschlüsseltes AES-256-GCM und lud sie zu einem GitHub-Dead-Drop hoch. Zweitens, und damit hat die Branche immer noch zu kauen, suchte sie gezielt nach authentifizierten AI-Coding-Assistenten auf dem Host und stahl deren Credentials:

• Ziele: Claude Code, Cursor, Codex CLI, Aider, Kiro, Gemini CLI, OpenCode.
• Quelldateien: ~/.claude.json, ~/.claude/mcp.json, ~/.kiro/settings/mcp.json und ähnliche.
• Persistenz: ein 3,5 KB großes Heredoc wird an ~/.bashrc und ~/.zshrc angehängt, sodass ein frischer Stealer bei jedem Login startet.

Das ist der erste öffentlich dokumentierte Supply-Chain-Angriff gegen AI-Coding-Assistenten in freier Wildbahn, und wir halten ihn für eine eigene Kategorie. AI-Assistenten sind privilegierte Identitäten: Sie halten API-Tokens, führen Shell-Befehle aus und lesen repo-lokale Instruction-Files, die kaum ein menschlicher Reviewer wirklich prüft. Den AI Agent des Entwicklers zu übernehmen ist attraktiver als dessen Shell, denn der Agent hat zusätzlich zur Shell noch Token und Zugriffe.

TanStack, Mistral AI & UiPath — wenn OIDC dem Angreifer den Token ausstellt

Drei Wochen nach Bitwarden, in der Nacht vom 11. auf den 12. Mai 2026, fuhr TeamPCP die größte Kampagne des Jahres. In einem einzigen Sechs-Stunden-Fenster pushten sie 400+ schädliche Versionen über 170+ npm- und 2 PyPI-Pakete:

• @tanstack/* — 42 Pakete (Router, Query, Table, in zehntausenden React-Anwendungen im Einsatz), 84 schädliche Versionen.
• Mistral AI — das offizielle @mistralai/mistralai-SDK plus die Azure- und GCP-Integrationen, jeweils drei schädliche Versionen, plus das PyPI-Release mistralai 2.4.6.
• UiPath — 65 Automation-Pakete.
• OpenSearch (1,3 Mio. wöchentliche npm-Downloads).
• Guardrails AI (PyPI).

Die Presse taufte die Kampagne nach einer alten Kampagne „Mini Shai-Hulud", der Einstiegsvektor war aber neu und einen genauen Blick wert. Kein Maintainer-Phishing, kein gestohlenes .npmrc, kein postinstall-getriebener Wurm. Alles passierte innerhalb des legitimen TanStack-Release-Workflows in GitHub Actions:

Was diesen Vorfall richtig unangenehm macht: Die veröffentlichten Pakete trugen gültige npm-Provenance-Signaturen. Provenance beweist, dass ein Artefakt von einem bestimmten GitHub-Actions-Workflow in einem bestimmten Repository gebaut wurde. Hier stimmte beides. Das Artefakt wurde tatsächlich vom echten TanStack-Release-Workflow im echten Repository aus einem main-Commit mit gültiger Signatur gebaut. Der Angreifer hat den Workflow nur dazu gebracht, seinen Code mitzukompilieren.

OIDC Trusted Publishing ist das Sicherheitsmodell, auf das die Branche gerade setzt, um langlebige npm-Publish-Tokens abzulösen. Es hat hier genau das getan, wofür es gebaut wurde: einen kurzlebigen, auf den Workflow gescopten Token im Namen einer attestierbaren Identität ausgestellt. Nur eben für einen Workflow, der vorher dazu gebracht wurde, Angreifercode auszuführen.

Die PyPI-Hälfte der Kampagne nutzte einen anderen, aber genauso einfachen Trick. mistralai 2.4.6 enthielt einen Einzeiler, der in mistralai/client/__init__.py injiziert wurde und bei jedem Import unter Linux eine Payload nach /tmp/transformers.pyz (so benannt, dass es Hugging Faces Transformers imitiert) herunterlud und ausführte. SafeDep, Snyk, Wiz, Aikido und Orca veröffentlichten innerhalb von 24 Stunden parallele technische Analysen.

Der StepSecurity-Researcher ashishkurmi hat 20 bis 26 Minuten nach dem ersten schädlichen Publish öffentlich Alarm geschlagen. Das ist schnell. Es war trotzdem lang genug, dass mehrere hundert CI-Runner weltweit vergiftete Tarballs gezogen haben.

Drei Lehren speziell aus diesem Vorfall:

1. OIDC ist notwendig, aber nicht hinreichend. Lässt sich der Release-Workflow dazu bringen, Angreifercode auszuführen, signiert OIDC diesen Code in die Produktion. Provenance belegt Integrität nach dem Build, nicht Korrektheit des Builds.
2. pull_request_target ist geladen. Es läuft mit den Rechten des Base-Repositories gegen Code aus einem Fork. PR-Head-Code in einem pull_request_target-Workflow nie ohne strikte Sandboxing auschecken.
3. Der GitHub-Actions-Cache ist eine geteilte Trust-Boundary. Fast niemand behandelt ihn heute als eine. Der TanStack-Vorfall ist der Beweis, dass man das tun muss.

4. Wie man die Angriffe verhindert

Legt man diese vier 2026er Vorfälle nebeneinander, tauchen in der Spalte „hätte es gestoppt" immer dieselben Kontrollen auf. Die meisten kosten nichts und brauchen keinen neuen Hersteller. Sie sind nur unattraktiv, deshalb sind sie standardmäßig nirgends aktiviert.

Entwickler-Hygiene

Ein paar dieser Punkte verdienen einen Satz:

• Frozen-Lockfile-Installs in CI. Jeder Package-Manager kennt inzwischen dieselbe Idee („installiere exakt dieses Lockfile, sonst scheitere"), nur unter unterschiedlichen Namen:

  npm ci                            # npm
  pnpm install --frozen-lockfile    # pnpm (in CI auch Default)
  yarn install --immutable          # Yarn Berry (v2+)
  bun install --frozen-lockfile     # Bun 1.0+
  

  Ein Theam, welches im Frozen-Lockfile-Modus gegen ein committetes Lockfile baut, war von Axios und Bitwarden nicht betroffen. Ein normales npm install / pnpm install / yarn add löst neue Versionen mit allen Schädlichen Änderungen still neu auf, die Frozen-Varianten nicht.

• ignore-scripts=true ist die einzeilige .npmrc-Änderung, die in drei der vier Vorfälle oben die eigentliche Payload-Ausführung verhindert hätte. Kaum ein Stack braucht postinstall-Skripte zur Installationszeit in CI. Wenn doch, dann lieber bewusst und später ausführen.

• Mindest-Release-Alter ist 2026 die wirksamste Einstellung, wenn man keinen Proxy-Registry-Server hat. Jeder große Package-Manager kann inzwischen Versionen ablehnen, die jünger sind als ein konfigurierter Schwellenwert. Alle schädlichen Releases oben wurden innerhalb von 48 Stunden zurückgezogen, ein 2-Tage-Gate hätte sie für jedes Team neutralisiert, das den Schalter umgelegt hatte:

  # npm 11+
  npm config set min-release-age 2
  
  # pnpm 10+ — Wert in Minuten (schreibt in .npmrc)
  pnpm config set minimumReleaseAge 2880
  
  # Yarn Berry v4.10+ — Wert in Minuten (schreibt in .yarnrc.yml)
  yarn config set npmMinimalAgeGate 2880
  

  Bun 1.3+ unterstützt dieselbe Einstellung über bunfig.toml (Wert in Sekunden):

  [install]
  minimumReleaseAge = 172800
  

  Die Einstellung greift bei Lockfile-Updates, nicht bei npm ci. Wer npm install <new-pkg> mit min-release-age 2 ausführt, kann keine brandneue schädliche Version ins Lockfile ziehen, also erreicht sie auch nie die CI. npm ci installiert das geprüfte Lockfile dann deterministisch wie bisher, ohne nochmal das Alter zu prüfen. Beides zusammen: min-release-age hält das Lockfile sauber, npm ci setzt es durch. Auf Entwicklermaschinen und in CI konfigurieren, sonst hebelt ein manuelles npm install auf dem Runner alles aus.

  Die Ausnahmeliste (minimumReleaseAgeExclude in pnpm, npmPreapprovedPackages in Yarn) ist für interne Pakete gedacht, die man selbst publisht und sofort konsumieren muss. Sparsam einsetzen.

• FIDO2 hilft nicht gegen den TanStack-Vektor, hätte aber die Axios-Social-Engineering-Kette deutlich erschwert. SMS und TOTP fallen Phishing zum Opfer, FIDO2 nicht.

CI/CD-Härtung

Der TanStack-Vorfall zwingt die Branche diesen Aspekt ihrere IT-Sicherheit ernst zu nehmen.

• Interner Proxy-Registry-Server (Verdaccio ist kostenlos, Artifactory und Nexus für Enterprise). Ein Engpunkt für jede Installation, mit Regeln. Wer auf jeder Entwicklermaschine und jedem CI-Runner ein Mindest-Release-Alter gesetzt hat, braucht den Proxy nicht mehr zwingend für die Quarantäne. Für rückwirkendes Zurückziehen kompromittierter Versionen organisationsweit bleibt er aber die bessere Antwort.
• 24- bis 48-Stunden-Quarantäne auf frische Upstream-Versionen, entweder im Proxy (besser durchsetzbar) oder über die Tool-eigenen min-release-age / minimumReleaseAge / npmMinimalAgeGate- Einstellungen oben. Die meisten schädlichen Releases existieren genau in diesem Zeitfenster.
• OIDC Trusted Publishing für jeden Publish-Workflow. Schafft langlebige npm-Tokens aus CI-Secrets ab, Punkt. Mit dem nächsten Punkt kombinieren.
• GitHub Actions absichern. Niemals PR-Head-Code in einem pull_request_target-Workflow auschecken. Actions per Commit-SHA pinnen, nicht per Floating Tag. Auditen, wer in den Actions-Cache schreiben darf und was die Cache-Einträge anfassen dürfen.
• Verhaltensanalyse-Scanner wie Socket, Endor Labs oder StepSecurity. Ihre Free Tiers erkennen postinstall-Muster und auffälliges Lifecycle-Verhalten, bevor überhaupt ein Advisory existiert. Das kann npm audit schlicht nicht.
• SBOM pro Build, täglich diffen. Ein neues transitives Paket oder eines, das still den Maintainer gewechselt hat, taucht im Diff auf, bevor es irgendwo läuft.

AI-Assistant-Schutz

Die Bitwarden-Welle-3-Payload hat diesen Bereich als eigene Kategorie etabliert. Die meisten Organisationen haben heute keine Policy dazu. Wir erwarten, dass sich dies im Laufe des Jahres ändert. Minimum:

• AI-Assistenten als privilegierte Identitäten behandeln. Ihre API-Tokens im gleichen Takt wie Service-Account-Credentials rotieren. Nicht langfristig in ~/.claude.json liegen lassen, wenn es vermeidbar ist.
• Assistant-Konfiguration unter Versionskontrolle (CLAUDE.md, .cursor/rules, copilot-instructions.md) und Änderungen daran in PRs reviewen, genau wie Code.
• Tool-Aufrufe sandboxen. Keine beliebige Shell ohne explizite menschliche Bestätigung.
• Tool-Calls des Assistenten auditen. Loggen, was der Assistent ausgeführt hat, nicht nur was der Mensch in den Prompt getippt hat.

Wer einen tieferen Walk-Through möchte: unser Team hilft gerne. Bei Bedarf melden Sie sich über die Kontaktseite, oder schauen Sie sich das vollständige Webinar oben in diesem Artikel an.

Weitere interessante Themen finden Sie auf unserem Blog.