Shai-Hulud bohrt weiter — 323 npm-Pakete im @antv-Cluster in einer Stunde, und was das für die Build-Pipeline-Disziplin bedeutet

TL;DR — die 90-Sekunden-Zusammenfassung

Was ist das Problem? — der Worm, der seinen eigenen Vorrat aufbaut

Wie der Worm in der Praxis aussieht

Der Standard-Payload — in der Mai-Variante leicht abgewandelt gegenüber der September-2025-Vorlage — läuft im npm-preinstall-Hook bzw. bei Composer im PluginInterface::activate()-Hook. Beide Hooks feuern vor dem ersten Application-Code, oft sogar bevor die Anwendung überhaupt geladen ist. Ablauf:

1. Environment-Inventur — Auslesen von HOME, USER, PWD; Suche nach .npmrc, .yarnrc, .pnpmfile.cjs, ~/.config/configstore/, GitHub-Tokens (GH_TOKEN, GITHUB_TOKEN), Standard-Pfaden für AWS-, Azure- und GCP-Credentials, ~/.docker/config.json, SSH-Keys.
2. Validierung gegen Provider-APIs — gefundene Tokens werden gegen die Provider-API auf Gültigkeit geprüft. Inaktive Tokens werden nicht weiter genutzt.
3. Exfiltration — aktive Credentials werden an einen C2-Endpoint geliefert (in der Mai-Welle: rotierende GitHub-Releases- bzw. Cloudflare-Worker-Endpoints).
4. Self-Propagation (nur npm-Variante mit gültigem npm-Token) — der Payload listet die Pakete des Token-Owners, lädt das aktuelle Tarball jedes Pakets, injiziert den eigenen preinstall-Hook in das package.json des Tarballs, packt es neu und publiziert mit angehobener Version. Effekt: aus einem kompromittierten Maintainer-Konto werden in Minuten Hunderte Pakete kompromittiert. Das ist der Worm-Charakter.

Die @antv-Welle vom 19. Mai ist das bisher dichteste Beispiel dieses Propagations-Schritts: das atool-Konto hatte direkten Push-Zugriff auf das gesamte @antv-Ökosystem, binnen einer Stunde gingen 323 Pakete in 639 Versionen kompromittiert raus.

Warum npm und Packagist

Die Composer-Ausweitung am 30. April ist strukturell aufschlussreich. Composer hat keinen direkten preinstall-Hook wie npm, aber Composer\Plugin\PluginInterface ist semantisch nahe genug: ein Composer-Plugin wird beim ersten composer install/composer update mit dem Plugin im Tree aktiviert, und activate() ist die Standard-Methode, die als Erstes läuft. Die Angreifer haben das intercom/intercom-php@5.0.2-Tarball so umgebaut, dass die Bibliothek formal wie zuvor aussah (gleiche Klassen, gleiche API), aber zusätzlich ein eingebettetes Composer-Plugin mitlieferte, das in activate() den Worm-Payload startet. Effekt: jeder composer install oder composer update einer Anwendung mit intercom/intercom-php im Tree triggerte den Payload — bei ~20,7 Mio. Lifetime-Installs ist die Angriffsfläche entsprechend.

Die Lehre aus den Schwester-Wellen: jeder Paketmanager mit einem Lifecycle-Hook ist ein Worm-Träger. PyPI ist seit Mai 2026 ebenfalls im Pfad (Mini-Shai-Hulud-Sub-Welle am 11.–12. Mai trifft PyPI mit), RubyGems und Maven sind bisher nicht angegriffen, aber das Pattern lässt sich grundsätzlich übertragen.

Wer ist betroffen?

Bei Moselwal: SBOM sauber, Auswirkung null

Unsere produktiven Builds fahren Lockfile-Pinning mit Integrity-Hash, die CI-Gates über npm audit signatures und composer audit, und SBOM-Generation (CycloneDX) als Build-Artefakt. Das @antv-Cluster ist in keiner unserer produktiven Anwendungen im Tree (wir nutzen Recharts und Chart.js, kein @antv). @tanstack/react-query ist im Tree; die SBOM-Auswertung gegen die zur Welle publizierten Versionslisten zeigte, dass die kompromittierten Versionen ausserhalb unseres Pinning-Bandes lagen. Composer-Seite: intercom/intercom-php ist nicht im Tree.

Auswirkungen

Build-Time-Credential-Exfiltration. Der grösste reale Schaden: jeder Build-Agent, der während der Welle eine npm install mit den kompromittierten Versionen im Tree gefahren hat, hat seine Build-Time-Secrets an den C2-Endpoint geliefert. Das umfasst:

• npm-Tokens — direkt verwertbar zur Self-Propagation (Worm in weitere Pakete des Token-Owners injizieren) und zur Manipulation der eigenen Releases.
• GitHub-PATs — Lesezugriff auf alle Repos, möglicherweise Schreibzugriff. Im schlimmsten Fall kann ein Angreifer Code in eigene Releases einbringen.
• Cloud-Credentials (AWS, Azure, GCP) — direkter Cloud-Workload-Zugriff. Praxis: Mining-Workloads in entdeckten Accounts, Daten-Exfiltration aus S3/Blob/GCS, Pivot in produktive Cluster.
• Docker-Registry-Credentials (~/.docker/config.json) — Push-Zugriff auf eigene Image-Registries. Worst case: kompromittierte Container-Images in der eigenen Tag-Linie.
• SSH-Keys — Pivot in andere Systeme, in denen der Build-Agent zur Auslieferung verwendet wird.

Second-Order-Impact: kompromittierte Pakete im eigenen Tree. Wer in den letzten Wochen ein npm- oder Composer-Update gefahren hat und ein kompromittiertes Paket in den dependencies oder devDependencies hat, transportiert den Worm im Code-Tree weiter — bei jedem npm install an einer beliebigen Stelle (CI, Entwickler-Workstation, lokaler Test) feuert der Payload erneut. Lockfile-Cleanup und Force-Reinstall mit gepinnten sauberen Versionen sind notwendig, sobald der Sicherheits-Provider die kompromittierten Versionen markiert hat (Socket, Snyk, Phylum, GitHub Advisory Database — alle pflegen aktuelle Listen).

Third-Order-Impact: kompromittierte Produktions-Artefakte. Wenn der Build-Agent mit Push-Token zur Container-Registry kompromittiert wurde, können neue Images mit injiziertem Code in der eigenen Tag-Linie sein. Image-Rebuild aus sauberer Quelle nach Token-Rotation ist Pflicht.

Nicht-Auswirkung: Runtime-Exploit. Der Worm ist ein Build-Time-Phänomen. Wer einen kompromittierten Tarball gezogen hat, aber nie npm install oder composer install mit Lifecycle-Hooks darauf gefahren hat (z. B. nur das Tarball lokal entpackt und manuell inspiziert), hat den Payload nicht aktiviert.

Mitigation / Sofortmaßnahmen

Pfad 1 — Inventur: lief unsere Build-Pipeline durch die Welle?

# CI-Log-Analyse: wann lief der letzte Public-npm-/Composer-Install seit 19.05.?
grep -E "(npm install|yarn install|pnpm install|composer install)" .github/workflows/*.yaml

# Wer im Build-Tree die kompromittierten Pakete hatte:
npm ls --all | grep -E "@antv/|@tanstack/|@mistralai/|@uipath/|@opensearch-project/"
composer show | grep "intercom/intercom-php"

Treffer mit Versionen aus dem Welle-Fenster sind das Signal, dass die Pipeline durch die kompromittierten Versionen gelaufen ist.

Pfad 2 — Token-Rotation (auch bei „wahrscheinlich nicht betroffen“)

# npm-Tokens auflisten und alte Tokens rotieren
npm token list
npm token revoke <token-id>
npm token create --read-only   # neuer Token für CI-Pull-only-Setup

# GitHub-PAT: über GitHub UI rotieren (Settings → Developer settings → Personal access tokens)
# AWS/Azure/GCP-Credentials: rotieren via IAM / Subscription / IAM Console
# Docker-Registry-Token: rotieren via Registry-Web-UI

Pfad 3 — npm install --ignore-scripts als Standard für CI-Pulls

# Für Production-Build-Steps (wo der Anwendungs-Code keine Build-Scripts braucht)
npm ci --ignore-scripts

--ignore-scripts stoppt den Worm-Payload, weil preinstall nicht ausgeführt wird. Nachteil: Pakete, die zur Install-Zeit Native Modules kompilieren (node-gyp-Pfad), brauchen postinstall-Scripts. In der Praxis bedeutet das: --ignore-scripts geht für Production-Builds, für Dev-Builds muss man es selektiv fahren.

Pfad 4 — npm audit signatures als Pre-Install-Gate

# Vor dem Install: Signatur-Provenance prüfen
npm audit signatures

npm audit signatures verifiziert die Sigstore-Signaturen der Pakete im Lockfile gegen die npm-Public-Key-Infrastruktur. Nicht alle npm-Pakete sind signiert, aber für signierte Pakete (npm-CLI ab v9.5, Sigstore-Integration) ist es eine harte Provenance-Schicht.

Pfad 5 — Composer-Audit als Pre-Deploy-Gate

composer audit
composer audit --format=plain --abandoned=ignore

Composer-Audit zieht aus der Friends-Of-PHP-Datenbank sowie aus dem Packagist-Advisory-Stream. Im Pre-Deploy-Gate ist das die Mindest-Linie.

Pfad 6 — Interner Mirror mit Allow-Liste

Für Plattformen, die regelmäßig gegen npm/Packagist bauen: ein interner Mirror (Verdaccio, JFrog Artifactory, Sonatype Nexus) mit Allow-Liste ist die zweite Verteidigungslinie. Der Mirror pullt nur explizit erlaubte Versionen aus dem öffentlichen Registry; neue Versionen kommen erst nach manueller Freigabe in den Mirror. Effekt: zwischen dem Worm-Publish auf public npm und dem Pull in den eigenen Build-Pfad liegt ein menschlicher Freigabe-Schritt.

Detection / Prüfung

Build-Time-Network-Anomalien

Falco-Rule (Kurzform) für verdächtige Outbound-Verbindungen während npm install oder composer install:

- rule: Suspicious Network Activity During Package Install
  desc: npm or composer process opens outbound connection to non-registry domain
  condition: >
    evt.type=connect and
    proc.name in (node, php, composer, npm, yarn, pnpm) and
    not fd.sip in (npm_registry_ranges, packagist_registry_ranges, github_releases_ranges)
  output: "Suspicious outbound connection during package install (proc=%proc.name dest=%fd.sip)"
  priority: WARNING

Lockfile-Diff-Enforcement in CI

# Bei jedem CI-Run: Diff zwischen Lockfile pre- und post-Install muss leer sein
npm ci
git diff --exit-code package-lock.json || (echo "LOCKFILE DRIFT DETECTED"; exit 1)

Wenn der Lockfile sich beim npm ci ändert, ist eine Version-Resolution unsauber — ein Hinweis darauf, dass eine andere Version als die gepinnte gezogen wurde.

Token-Aktivitäts-Audit (npm / GitHub / Cloud)

• npm:npm token list zeigt aktive Tokens; im npm-Audit-Log (npmjs.com/settings/<USER>/tokens) Nutzungs-Spuren prüfen
• GitHub:github.com/settings/security-log — ungewöhnliche IP-Zugriffe, neue Token-Creations
• AWS: CloudTrail-Events iam:*, sts:GetSessionToken, ungewöhnliche AssumeRole-Spuren
• Azure: Activity Log nach Service-Principal-Aktivität ausserhalb regulärer Build-Zeiten

Betreiberempfehlung

Operational Decision Block

• Sofort patchen und Token rotieren, wenn … die Build-Pipeline seit dem 19. Mai eine npm install ohne strenges Lockfile-Hash-Pinning gegen public npm gefahren hat und @antv-Pakete im Tree sind.
• Sofort Composer-Audit und Token-Rotation, wenn …intercom/intercom-php im Composer-Tree war und seit dem 30. April ein composer install gegen public Packagist gefahren wurde.
• Defensive Pipeline-Hygiene, immer: Lockfile-Pinning mit Hash-Sum, npm audit signatures als Pre-Install-Gate, composer audit als Pre-Deploy-Gate.
• Strategischer Schritt: wer in den nächsten 12 Monaten plant, npm- und Composer-Builds in einen sauberen Mittelstand-Stack zu heben, baut den internen Mirror jetzt — die Welle ist nicht das einmalige Ereignis, sondern der laufende Zustand.

Mittelstand (PHP-, Symfony-, Sylius-, Shopware- und Node-Plattformen)

Einmalige Inventur, Token-Rotation, Pre-Install-Gates aktivieren. Wer kein internes Mirror-Setup hat, beginnt mit den Pre-Install-Gates — npm audit signatures und composer audit kosten nichts und fangen die ersten Wellen-Träger ab.

Enterprise (mehrere Mandanten, mehrere Build-Stacks)

Interner Mirror mit Allow-Liste, signaturgeprüfter Pull, SBOM als Build-Artefakt jedes Builds (CycloneDX oder SPDX), zentrale Rotations-Routine für Tokens alle 30 Tage, Build-Agent-Pool ohne dauerhafte Cloud-Credentials (OIDC-Federation, ephemere Tokens).

Kubernetes und containerisierte Setups

Image-Rebuild gegen saubere Versionen nach Token-Rotation. Build-Context im Dockerfile so führen, dass keine NPM_TOKEN- oder COMPOSER_AUTH-Werte als Build-Args durchgereicht werden — stattdessen Multi-Stage-Build mit BuildKit-Secret-Mount:

# syntax=docker/dockerfile:1.4
FROM node:20-bullseye AS builder
WORKDIR /app
COPY package*.json ./
RUN --mount=type=secret,id=npmrc,target=/root/.npmrc \
    npm ci --ignore-scripts

FROM gcr.io/distroless/nodejs20-debian12
COPY --from=builder /app /app
CMD ["/app/dist/server.js"]

Deklarative Stacks (NixOS, Talos, Flatcar mit Wolfi-Images)

Wolfi-Distroless-Images sind auf der Image-Pull-Seite signaturgeprüft (Cosign + Rekor). Das heisst nicht, dass die npm install- oder composer install-Schicht innerhalb des Wolfi-Builds nicht angreifbar wäre. Deklarative Stacks brauchen denselben Mirror- und Token-Hygiene-Pfad wie klassische Stacks.

Was wir konkret getan haben

Bei uns laufen npm audit signatures und composer audit als CI-Gates über alle produktiven Builds; Lockfile-Pinning mit Integrity-Hash ist Standard. Die Komponenten-Inventur sitzt in der SBOM (CycloneDX), die pro Build automatisch erzeugt wird. Manuelle composer show | grep-Stichproben oder Ad-hoc-composer audit | grep-Läufe pro Mandant gehören nicht zu unserem Vorgehen.

Beim @tanstack- und @mistralai-Cluster am 11. und 12. Mai 2026 hat das Lockfile-Pinning zusammen mit dem CI-Gate die kompromittierten Versionen ausserhalb unseres Pin-Bandes gehalten — keine Welle-Version landete im produktiven Tree. Während der @antv-Welle am 19. Mai war die Auswirkung null: das @antv-Cluster ist in keiner unserer produktiven Anwendungen im Tree. Auf der Composer-Seite war intercom/intercom-php am 30. April ebenfalls nicht im Tree, der CI-Gate war grün; Token-Rotation lief trotzdem als Vorsichtsmaßnahme über die zentrale Rotations-Routine.

Lessons Learned: die Mai-Welle zeigt, dass Shai-Hulud kein Einmal-Ereignis vom September 2025 war, sondern ein laufender Zustand ist. Wer die Hygiene-Schichten aufgebaut hat (Lockfile-Pinning mit Integrity-Hash, --ignore-scripts als Default, Pre-Install-Gates, Rotations-Routine für Tokens, SBOM als Build-Artefakt), hat ruhigere Tage. Wer 2025 die Welle als Ausnahme abgehakt hat, ist 2026 im Reaktionsmodus. Das ist der eigentliche Erkenntniswert dieser Welle, nicht ein einzelner CVE-Pfad.

Technischer Deep-Dive: die Übernahme des atool-Kontos am 19. Mai ging über einen Phishing-Angriff gegen den Maintainer (JFrog-Bericht hat die Details). Schutz auf Maintainer-Seite wäre 2FA oder WebAuthn auf dem npm-Konto gewesen, was atool nicht aktiv hatte. Auf der Konsumenten-Seite — also bei uns als Plattform-Betreiber — zählt nicht, was der Maintainer macht, sondern ob der eigene Pull-Pfad signaturgeprüft und Allow-list-basiert ist. Beide Schichten sind nötig; eine ohne die andere ist Theatersicherheit.

Fazit

Die @antv-Welle vom 19. Mai ist die bisher dichteste Einzel-Stunden-Welle in der Shai-Hulud-Reihe — 323 Pakete in 639 Versionen über ein einzelnes kompromittiertes Maintainer-Konto. Sie steht nicht für einen Einzelfehler, sondern für einen anhaltenden Zustand: Konto-Übernahme + Self-Propagation + Lifecycle-Hook = ein automatischer Verteiler-Apparat für Credential-Diebstahl auf der ganzen npm-Population. Composer/Packagist steht seit Ende April im selben Spielfeld. Wer eine produktive PHP-, Node- oder Mixed-Stack-Plattform betreibt und in den letzten 18 Monaten die Hygiene-Schichten aufgebaut hat — interner Mirror, Lockfile-Hash-Pinning, --ignore-scripts, npm audit signatures, composer audit, BuildKit-Secret-Mount, Rotations-Routine für Tokens —, hat in dieser Welle wenig bis nichts zu tun. Wer die Welle als Anlass nimmt, jetzt die Hygiene-Schichten aufzubauen, hat einen klaren Bauplan und einen Trigger. Die Frage lautet nicht „kommt die nächste Welle?“ — sie lautet, ob die eigene Pipeline sie reflexiv übersteht oder jedes Mal in den Reaktionsmodus geht.