Mini Shai-Hulud: Neuer npm-Angriff trifft über 320 Pakete

Mini Shai-Hulud ist zurück. Am 19. Mai 2026 wurde eine neue Welle der Supply-Chain-Kampagne sichtbar, diesmal mit Schwerpunkt auf dem @antv-Ökosystem und weiteren beliebten npm-Paketen. SecurityWeek berichtet am 20. Mai 2026 von mehr als 320 betroffenen npm-Paketen sowie Bezügen zu GitHub Actions, einer VS-Code-Extension und PyPI.

Socket zählt für diese Welle 639 kompromittierte Versionen in 323 Paketen. Über die gesamte Mini-Shai-Hulud-Kampagne hinweg nennt Socket 1.055 Versionen in 502 Paketen, davon der überwiegende Teil in npm. Das macht den Vorfall nicht nur zu einem Paketproblem, sondern zu einem Risiko für CI/CD, Entwicklergeräte und Cloud-Zugangsdaten.

Was ist passiert?

Der kompromittierte npm-Maintainer-Account atool hatte Zugriff auf Pakete im @antv-Namensraum und veröffentlichte unter anderem timeago.js. Nach der Kompromittierung wurden schadhafte Paketversionen in kurzer Folge veröffentlicht. Betroffen waren Datenvisualisierung, Graphing, Mapping, Charting und React-Komponenten, darunter echarts-for-react mit hoher Download-Reichweite.

Der Angriff ist deshalb besonders kritisch, weil er nicht bei einem einzelnen Paket stehen bleibt. Die Malware enthält Logik zum Missbrauch von npm-Tokens: Token validieren, Pakete eines Maintainers enumerieren, Tarballs herunterladen, Payload und preinstall-Hook einfügen, Versionen erhöhen und veränderte Pakete erneut veröffentlichen.

Welche Pakete sind betroffen?

Die auffälligste betroffene Gruppe sind Pakete aus dem @antv-Namensraum, etwa @antv/g2, @antv/g6, @antv/x6, @antv/l7, @antv/s2, @antv/f2, @antv/g, @antv/g2plot, @antv/graphin und @antv/data-set. Socket nennt zusätzlich nicht gescopte Pakete wie echarts-for-react, timeago.js, size-sensor und canvas-nest.js.

StepSecurity listet ebenfalls zahlreiche Pakete, darunter mcp-echarts, mcp-mermaid, jest-canvas-mock, jest-date-mock sowie mehrere @openclaw-cn/*-Pakete. Weil die Kampagne aktiv untersucht wird, sollten Teams nicht mit einer statischen Liste arbeiten, sondern aktuelle Advisory-Daten aus SCA-, npm- und Threat-Intel-Quellen einbeziehen.

Wie die Malware arbeitet

Die kompromittierten npm-Pakete enthalten einen Installationszeit-Payload. Socket beschreibt eine obfuskierte index.js, die package.json so verändert, dass der Schadcode über einen preinstall-Hook ausgeführt wird. Das ist für CI/CD besonders unangenehm: Schon npm install, pnpm install oder ähnliche Dependency-Schritte reichen als Ausführungspunkt.

Der Payload sucht nach GitHub-Tokens, npm-Tokens, AWS-, GCP- und Azure-Zugangsdaten, Kubernetes-Service-Account-Material, HashiCorp-Vault-Tokens, SSH-Keys, Docker-Authentifizierung und weiteren Entwickler-Secrets. StepSecurity beobachtete zudem Versuche, Speicher des GitHub-Actions-Runners zu lesen, um maskierte CI/CD-Secrets im Klartext zu gewinnen.

Exfiltriert wird über zwei Wege: einerseits über eine C2-Infrastruktur, andererseits über GitHub-Repositories, die mit gestohlenen Tokens im Konto des Opfers erzeugt werden. Wiz und Socket nennen als wiederkehrenden Marker die Rückwärts-Zeichenkette niagA oG eW ereH :duluH-iahS, die vorwärts gelesen Shai-Hulud: Here We Go Again ergibt.

Die zentrale Lehre: Diese Malware sucht nicht nur nach Quellcode. Sie sucht nach allem, womit ein Build-System, ein Maintainer-Konto oder eine Cloud-Umgebung weiter bewegt werden kann.

Persistenz, C2 und Entwickler-Tools

Wiz beschreibt eine Python-basierte Backdoor unter ~/.local/share/kitty/cat.py. Auf macOS und Linux wurden Persistenzmechanismen wie com.user.kitty-monitor.plist und kitty-monitor.service genannt. Die Backdoor pollt GitHub nach signierten Kommandos mit dem Marker firedalazer und kann bei gültigen Anweisungen weitere Python-Payloads abrufen.

StepSecurity berichtet außerdem von Backdoors in Claude-Code- und VS-Code-Konfigurationen. SecurityWeek und Wiz verweisen auf eine kompromittierte VS-Code-Extension nrwl.angular-console in Version 18.95.0 sowie auf kompromittierte GitHub Actions aus dem actions-cool-Umfeld. Das erweitert den Blick von Paketmanagern auf die gesamte Entwickler-Toolchain.

PyPI: durabletask als Warnsignal

Die aktuelle Kampagne ist nicht sauber auf npm begrenzt. StepSecurity analysiert kompromittierte Versionen von Microsofts durabletask-Python-SDK auf PyPI: 1.4.1, 1.4.2 und 1.4.3. Laut Analyse wurden diese Versionen innerhalb eines kurzen Zeitfensters direkt auf PyPI hochgeladen, ohne passende Tags, Releases oder CI/CD-Läufe im GitHub-Repository.

Für Python-Teams ist der operative Punkt simpel: Wenn durabletask in den genannten Versionen installiert oder importiert wurde, sollte die Umgebung als kompromittiert behandelt werden. StepSecurity empfiehlt, auf 1.4.0 zu pinnen und Incident Response zu starten. Der Fall zeigt außerdem, warum Trusted Publishing statt langfristiger Publish-Tokens auch im PyPI-Umfeld relevant ist.

Warum der TanStack-Kontext wichtig bleibt

Der bestehende TanStack-Vorfall vom 11. Mai 2026 war eine frühere Mini-Shai-Hulud-Welle. TanStack bestätigte damals 84 kompromittierte Versionen von 42 @tanstack/*-Paketen. Die Ursache lag nicht in einem klassischen npm-Token-Diebstahl, sondern in einer missbrauchten GitHub-Actions-Release-Pipeline mit pull_request_target, Cache-Poisoning und OIDC-Kontext.

Genau deshalb gehören beide Wellen in dieselbe Risikoanalyse. Die Payloads und Infrastrukturen unterscheiden sich, aber das Zielbild bleibt gleich: Entwickler- und CI/CD-Umgebungen sind wertvolle Orte für Angreifer, weil dort Secrets, Publish-Rechte, Cloud-Zugriffe und Build-Artefakte zusammenlaufen.

Sofort-Check für Projekte und CI/CD

Starten Sie mit den Systemen, die am 19. oder 20. Mai 2026 Dependencies installiert haben: CI/CD-Runner, Build-Images, Entwicklergeräte, Preview-Deployments und Container-Builds. Der folgende Check ist bewusst breit, damit er erste Treffer in Lockfiles und Build-Artefakten findet.

rg -n "(@antv/|echarts-for-react|timeago\.js|timeago-react|size-sensor|canvas-nest\.js|jest-canvas-mock|jest-date-mock|mcp-echarts|mcp-mermaid|@openclaw-cn/|@starmind/collector-cli|durabletask)" package-lock.json pnpm-lock.yaml yarn.lock bun.lockb requirements.txt poetry.lock uv.lock pyproject.toml

rg -n "t\.m-kosche\.com|m-kosche\.com|niagA oG eW ereH :duluH-iahS|Shai-Hulud: Here We Go Again|results/results-|firedalazer|kitty-monitor|\.local/share/kitty/cat\.py|@antv/setup|preinstall.*bun run index\.js" .

Wenn Sie Treffer finden oder ein Installationszeitpunkt in das Risiko-Fenster fällt, behandeln Sie die Umgebung nicht als reines Dependency-Update. Mini Shai-Hulud ist ein Credential-Stealer mit Persistenz- und Propagationslogik.

GitHub Actions und Build-Workflows auditieren

Die neue Welle nutzt vor allem Paketinstallation und gestohlene Tokens. Der TanStack-Fall zeigt aber, dass auch die Release-Pipeline selbst zum Angriffsweg werden kann. Prüfen Sie deshalb, welche Workflows untrusted Code ausführen, welche Jobs Publish-Rechte haben und ob Caches zwischen Vertrauenszonen wiederverwendet werden.

rg -n "pull_request_target|id-token:\s*write|actions/cache|npm publish|pnpm publish|yarn npm publish|pypi|twine|trusted.?publish|GITHUB_TOKEN|NODE_AUTH_TOKEN|PYPI_API_TOKEN" .github/workflows

Gute Zielbilder für Build- und Release-Umgebungen:

• pull_request_target nur für Metadaten-Aufgaben einsetzen, nicht für Checkout und Ausführung von Fork-Code.
• Caches strikt trennen: untrusted PR-Jobs dürfen keine Artefakte erzeugen, die später von Release-Jobs blind wiederhergestellt werden.
• Publish-Rechte und id-token: write nur in minimalen, expliziten Release-Jobs erlauben.
• Third-Party-Actions auf Commit-SHAs pinnen und unerwartete Tag-Änderungen überwachen.
• Outbound Traffic aus CI/CD beschränken, damit Paketinstallationen nicht beliebig zu C2-Endpunkten kommunizieren können.

Indicators of Compromise

Die folgenden IOCs sind ein Startpunkt für Hunting und Triage. Sie sollten mit aktuellen Feeds abgeglichen werden, weil sich Infrastruktur und Paketlisten bei aktiven Supply-Chain-Kampagnen schnell ändern können.

Was Unternehmen daraus lernen sollten

Für Unternehmen ist Mini Shai-Hulud ein Lehrstück für Software Supply Chain Security. Der Angriff verbindet drei Risikofelder, die oft getrennt behandelt werden: Abhängigkeiten aus Open Source, CI/CD-Runtime-Sicherheit und Secret-Management. Wer nur auf Dependabot-Updates oder Vulnerability-Scans schaut, übersieht den wichtigsten Punkt: Ein kompromittiertes Paket kann in Sekunden den gesamten Build-Kontext lesen.

Fazit: Supply-Chain-Schutz endet nicht am Paketnamen

Die neue Mini-Shai-Hulud-Welle zeigt, wie schnell ein kompromittierter Maintainer-Account zum Risiko für hunderte Pakete und tausende Downstream-Projekte werden kann. Entscheidend ist nicht nur, ob ein Paketname in Ihrer Dependency-Liste steht. Entscheidend ist, ob der Code in einer Umgebung lief, die Zugang zu GitHub, npm, PyPI, Cloud, Kubernetes oder SSH-Schlüsseln hatte.

Gute Supply-Chain-Sicherheit kombiniert aktuelle Advisory-Daten, reproduzierbare Dependency-Updates, gehärtete CI/CD-Runner, minimale Publish-Rechte und Incident-Response-Prozesse, die speziell auf Entwickler- und Build-Umgebungen zugeschnitten sind. Mini Shai-Hulud ist damit weniger ein einzelner npm-Vorfall als ein Stresstest für moderne Softwarelieferketten.

Häufige Fragen

Diese FAQ ist für die schnelle Betroffenheitsprüfung gedacht. Für eine echte Incident Response sollten Lockfiles, Telemetrie, Paketlisten und GitHub-/Registry-Aktivitäten gemeinsam bewertet werden.