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

Stand: 20. Mai 2026 - zuletzt aktualisiert

Autor: Mika Schmidt (IT-Security Experte) – Six Eight Consulting, Fokus: Analyse, IAM, Security Engineering.

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. [News]

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. [Threat Intel]

Kurzbewertung

Wenn betroffene Pakete seit dem 19. Mai 2026 in CI/CD oder auf Entwicklergeräten installiert wurden, sollten die Umgebungen als potenziell kompromittiert gelten. Die Malware zielt auf Secrets, Persistenz und Weiterverbreitung.

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. [News] [Threat Intel]

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. [Threat Intel]

Bereich	Stand 20. Mai 2026	Warum relevant?
Neue npm-Welle	323 Pakete, 639 Versionen laut Socket	Vor allem @antv, aber nicht nur scoped Pakete
Kampagne gesamt	502 Pakete, 1.055 Versionen laut Socket	Mehrere Ökosysteme, npm dominiert
Weitere Ziele	GitHub Actions, VS-Code-Extension, PyPI	Entwickler- und Build-Umgebungen im Fokus
Vorherige Welle	TanStack: 42 Pakete, 84 Versionen	Zeigt Muster und Risiko für Release-Pipelines

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. [Threat Intel]

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. [Analyse]

Wichtig für Lockfile-Prüfungen

Suchen Sie nicht nur nach Paketnamen. Entscheidend sind die konkreten Versionen, der Installationszeitpunkt und die Umgebung. Ein Fund in einem alten Lockfile ist anders zu bewerten als eine Installation in CI/CD am 19. oder 20. Mai 2026.

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. [Threat Intel]

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. [Threat Intel] [Analyse]

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. [Analyse] [Threat Intel]

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. [Analyse]

StepSecurity berichtet ausserdem 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. [News] [Analyse]

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. [Analyse]

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 ausserdem, warum Trusted Publishing statt langfristiger Publish-Tokens auch im PyPI-Umfeld relevant ist. [Analyse]

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. [Postmortem] [Advisory]

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. [Best Practice]

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.

Isolieren: Betroffene Runner, Workstations und Build- Images aus der Rotation nehmen.
Beweise sichern: CI-Logs, npm-/PyPI-Logs, Proxy-/DNS-Telemetrie, Prozessdaten und relevante Home-Verzeichnisse sichern.
Persistenz prüfen: Nach cat.py, kitty-monitor, ungewöhnlichen LaunchAgents/systemd-User- Services, manipulierten VS-Code- oder Claude-Code-Konfigurationen suchen.
GitHub prüfen: Unerwartete Repositories, Repository-Beschreibungen mit Shai-Hulud-Markern, neue Tokens, ungeplante Workflow-Läufe und auffällige Pushes suchen.
Secrets rotieren: Erst nach Persistenzprüfung GitHub-, npm-, PyPI-, Cloud-, Kubernetes-, Vault-, SSH- und CI/CD-Secrets erneuern.

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. [Threat Intel] [Analyse] [Analyse]

Kategorie	Indikatoren
Netzwerk	`t.m-kosche[.]com`, `https://t.m-kosche[.]com:443/api/public/otel/v1/traces`, `m-kosche[.]com`, `185.95.159.32`, `check.git-service[.]com`
GitHub-Marker	`niagA oG eW ereH :duluH-iahS`, `Shai-Hulud: Here We Go Again`, `results/results-*.json`
Persistenz	`~/.local/share/kitty/cat.py`, `com.user.kitty-monitor.plist`, `~/.config/systemd/user/kitty-monitor.service`
Payload-Hinweise	`preinstall`-Hook mit `bun run index.js`, `@antv/setup`, obfuskierte `index.js`, unerwartete GitHub-API-Nutzung während Paketinstallation
TanStack-Kontext	`router_init.js`, `router_runtime.js`, `tanstack_runner.js`, `@tanstack/setup`, `filev2.getsession.org`, `seed*.getsession.org`

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.

Dependency-Kontrolle

Lockfiles verpflichtend nutzen, Updates nachvollziehbar machen, bekannte Malware-Pakete blockieren und neue Versionen nicht automatisch in produktive Build-Pfade ziehen.

Runner-Hardening

CI/CD-Runner als Hochrisiko-Systeme behandeln: minimale Rechte, Egress-Kontrolle, kurzlebige Umgebungen und klares Logging für Installations- und Publish-Schritte.

Secret-Hygiene

Langfristige Tokens reduzieren, Rollen eng schneiden, Repository- und Org-Tokens überwachen und Rotation nicht als Ersatz für Persistenz- Prüfung missverstehen.

Incident Readiness

Playbooks für kompromittierte Dependencies vorbereiten: Lockfile- Suche, Runner-Isolation, GitHub-Audit, Cloud-Token-Rotation und Registry-Publish-Review.

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.

Bin ich vom neuen Mini-Shai-Hulud-npm-Angriff betroffen?

Sie sind potenziell betroffen, wenn seit dem 19. Mai 2026 eines der kompromittierten npm-Pakete installiert wurde, insbesondere Pakete aus dem @antv-Umfeld, echarts-for-react, timeago.js, size-sensor, canvas-nest.js, mcp-echarts, mcp-mermaid oder weitere von Socket, StepSecurity und Wiz gelistete Pakete. Prüfen Sie Lockfiles, CI-Logs, Build-Caches und Entwicklergeräte.

Warum ist diese Welle gefährlicher als ein normales kompromittiertes Paket?

Die Malware stiehlt nicht nur lokale Secrets. Sie kann GitHub- und npm-Tokens nutzen, Pakete des betroffenen Maintainers enumerieren, Tarballs verändern, preinstall-Hooks einfügen und neue schadhafte Versionen veröffentlichen. Damit hat der Angriff Worm-Charakter und kann sich über weitere Maintainer-Konten ausbreiten.

Welche Pakete sollte ich zuerst suchen?

Priorisieren Sie @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 und die von Ihren SCA-Tools gemeldeten betroffenen Versionen. Die Listen wachsen, deshalb ist eine aktuelle Advisory-Quelle wichtig.

Welche Indicators of Compromise sind wichtig?

Wichtige Indikatoren sind t.m-kosche.com, https://t.m-kosche.com:443/api/public/otel/v1/traces, m-kosche.com, GitHub-Repositories mit results/results-*.json, die Marker niagA oG eW ereH :duluH-iahS beziehungsweise Shai-Hulud: Here We Go Again, sowie Persistenzartefakte wie ~/.local/share/kitty/cat.py und kitty-monitor-Services.

Soll ich Secrets sofort rotieren?

Ja, wenn eine betroffene Version installiert wurde, aber in der richtigen Reihenfolge: System isolieren, Persistenz und laufende Malware suchen, Logs sichern, dann GitHub-, npm-, Cloud-, Kubernetes-, Vault-, SSH- und CI/CD-Secrets rotieren. Sonst können neue Tokens direkt wieder abgegriffen werden.

Sind nur npm-Projekte betroffen?

Nein. Die aktuelle Berichterstattung beschreibt vor allem npm, aber die Mini-Shai-Hulud-Kampagne wird auch mit PyPI- und Composer-Aktivitäten in Verbindung gebracht. StepSecurity analysiert unter anderem kompromittierte durabletask-Versionen auf PyPI. Python-Teams sollten deshalb ebenfalls Paketversionen, Import-Zeitpunkte und CI/CD-Umgebungen prüfen.

Was hat das mit dem TanStack-Vorfall vom 11. Mai 2026 zu tun?

TanStack war eine frühere Mini-Shai-Hulud-Welle, bei der 42 @tanstack/*-Pakete kompromittiert wurden. Die neue @antv-Welle unterscheidet sich in Payload und Infrastruktur, nutzt aber ähnliche Muster: Installationszeit-Ausführung, Secret-Harvesting, GitHub-Missbrauch und npm-Weiterverbreitung.