Shai-Hulud: der npm-Wurm und wie Sie prüfen, ob Ihre Builds betroffen sind

Shai-Hulud ist ein sich selbst verbreitender Wurm, der npm-Pakete infiziert, ein Software-Lieferkettenangriff, der jedes Opfer dazu bringt, ihn weiterzuverbreiten. Er läuft, wenn ein Paket installiert wird, stiehlt npm-Tokens, GitHub-Tokens und Cloud-Schlüssel vom Rechner und nutzt das npm-Token, um infizierte Versionen der anderen Pakete des Opfers zu veröffentlichen. Seit der ersten Welle im September 2025 ist er immer wieder zurückgekehrt, und im Mai 2026 veröffentlichten seine Urheber den Quellcode, sodass hinter jeder Welle seitdem eine andere Gruppe stecken kann. Hat einer Ihrer Builds eine infizierte Version installiert, behandeln Sie diesen Job als kompromittiert und rotieren Sie jedes Secret, das er lesen konnte.

Der größte Schaden entsteht im CI. Bei der Welle im November 2025 stellte Wiz fest, dass nur 23 % der Infektionen auf Entwicklerrechnern lagen, der Rest überwiegend in CI/CD-Pipelines, am häufigsten in GitHub Actions. Ein Build installiert Hunderte von Paketen, hält die Secrets zum Veröffentlichen und Deployen bereit und führt jedes Install-Skript aus, ohne dass jemand zusieht. Wird eine neue Welle bekannt, stellt deshalb jedes Team dieselbe Frage: Hat einer unserer Builds eine infizierte Version installiert?

Was passiert ist

Wann	Welle	Was anders war
September 2025	Shai-Hulud	Ein postinstall-Skript führte ein 3,6 MB großes bundle.js aus, nutzte TruffleHog, um Secrets zu finden, und veröffentlichte bis zu 20 Pakete des Maintainers neu. Mehr als 500 Pakete waren betroffen, darunter @ctrl/tinycolor und 18 @crowdstrike-Pakete. CISA veröffentlichte am 23. September eine Warnung.
November 2025	Sha1-Hulud: The Second Coming	Wechselte zu preinstall, installierte die Bun-Runtime, um eine 10 MB große Schadsoftware auszuführen, versah bis zu 100 Pakete pro Maintainer mit einer Hintertür und registrierte infizierte Rechner als selbst gehostete GitHub-Runner. Pakete von Zapier, ENS, PostHog und Postman wurden getroffen; Wiz zählte mehr als 25.000 Repositories mit abgeflossenen Secrets.
Dezember 2025	„3.0“-Test	Eine veränderte Version in einem einzigen Paket, ohne nennenswerte Verbreitung.
Mai 2026	TanStack	84 bösartige Versionen von 42 @tanstack-Paketen. Der Angreifer stahl nie ein npm-Token: Ein pull_request_target-Workflow, ein vergifteter Actions-Cache und ein aus dem Runner-Speicher gelesenes OIDC-Token ermöglichten die Veröffentlichung über TanStacks eigenes Trusted Publishing. Erfasst als CVE-2026-45321, am 27. Mai in den KEV-Katalog der CISA aufgenommen.
Mai 2026	AntV	639 Versionen von 323 Paketen. Auf Linux-Runnern von GitHub Actions las die Schadsoftware Secrets aus dem Speicher des Runner-Prozesses und umging so das Log-Masking. GitHub machte 61.274 npm-Schreib-Tokens ungültig.
Juni 2026	Miasma	32 @redhat-cloud-services-Pakete, veröffentlicht über injizierte Workflows mit gültiger Provenienz. Jede Infektion trug eine individuell verschlüsselte Schadsoftware, sodass hash-basierte Erkennung versagte.
August 2026	CHAINDROP	Beliebte Caching-Pakete wie keyv, cacheable und cache-manager, insgesamt waren Hunderte von Paketen betroffen. Der Wurm setzte sich über Konfigurationsdateien für Editoren und KI-Assistenten im Repository fest.
September 2026	Wiederauftauchen	Am 7. September kehrte die Schadsoftware in vier Paketen zurück, die den neuen Malware-Scan von npm beim Veröffentlichen überwanden.
Oktober 2026	tensorlake	Am 8. Oktober wurde [email protected] mit dem Wurm veröffentlicht. OX Security sah neue Schlüssel der Angreifer und vermutet „einen unabhängigen Bedrohungsakteur oder eine neue Gruppe, die den Namen Shai-Hulud verwendet“.

Was der Wurm in einem CI-Job tut

Die Details ändern sich von Welle zu Welle, aber das Muster bleibt:

1. Er läuft bei der Installation. Ein preinstall- oder postinstall-Skript wird ausgeführt, sobald npm install oder npm ci die infizierte Version erreicht. Nichts in Ihrem Code muss sie importieren.
2. Er sammelt Secrets. Umgebungsvariablen, .npmrc-Tokens, Cloud-Zugangsdaten aus dem Metadatendienst und aus Secret Managern sowie alles, was TruffleHog auf der Festplatte findet. Spätere Wellen lasen direkt den Speicher des GitHub-Actions-Runners aus und erbeuteten so Secrets, die dem Schritt nie zugänglich waren und die das Masking in Logs verborgen hätte.
3. Er schafft sie nach draußen. Frühe Wellen legten öffentliche GitHub-Repositories an, die nach dem Wurm benannt waren, und pushten einen Workflow, der jedes Repository-Secret an webhook.site sendete. Spätere Wellen nutzten Server der Angreifer und Messaging-Netzwerke.
4. Er verbreitet sich und bleibt. Mit einem gestohlenen npm-Token veröffentlicht er infizierte Versionen anderer Pakete. Mit einem GitHub-Token fügt er Workflows hinzu, registriert selbst gehostete Runner oder platziert Konfigurationsdateien, die ausgeführt werden, wenn jemand das nächste Mal das Repository öffnet.
5. Er verhält sich im CI anders. Die Schadsoftware vom November 2025 prüfte auf GITHUB_ACTIONS, BUILDKITE, CIRCLE_SHA1 und ähnliche Variablen und lief im CI synchron, sodass sie ihre Arbeit beendete, bevor der Build weiterging.

Wer betroffen ist

Jeder, dessen Rechner oder Builds eine infizierte Version installiert haben, solange sie in der Registry verfügbar war: Entwicklerlaptops, CI-Jobs, Docker-Builds, die npm install ausführen, und selbst gehostete Runner. Sie müssen nicht direkt von dem Paket abhängen; eine transitive Abhängigkeit oder ein mit npx ausgeführtes Tool genügt. Jede Welle hat ihre eigene Liste von Paketen und Versionen, und infizierte Versionen werden meist innerhalb von Stunden oder Tagen entfernt. Entscheidend ist also, ob irgendetwas sie in diesem Zeitfenster installiert hat.

Wie es funktioniert

Shai-Hulud ist kein Fehler in npm. Es ist bösartiger Code, der in ansonsten legitimen Paketen veröffentlicht wird und den die Malware-Advisories von GitHub für die infizierten Pakete als eingebetteten bösartigen Code (CWE-506) einstufen. Jede Welle kombiniert einige Techniken:

• Ausführung bei der Installation. npm führt die Lifecycle-Skripte eines Pakets, etwa preinstall, postinstall und prepare, während der Installation aus, mit den Berechtigungen des Benutzers oder des CI-Jobs. Eine infizierte Version muss nur im Abhängigkeitsbaum stehen; nichts muss sie importieren.
• Verbreitung mit gestohlenen Veröffentlichungsrechten. Mit einem npm- oder GitHub-Token, das einem Opfer abgenommen wurde, veröffentlicht der Wurm neue Versionen der anderen Pakete dieses Opfers mit der hinzugefügten Schadsoftware, sodass jeder infizierte Maintainer weitere Pakete infiziert.
• Veröffentlichung über die eigene Release-Pipeline des Opfers (TanStack, Mai 2026). Laut dem Advisory von GitHub verkettete der Angreifer einen pull_request_target-Workflow, einen über die Vertrauensgrenze zwischen Fork und Basis-Repository hinweg vergifteten GitHub-Actions-Cache und ein aus dem Speicher des Runners gelesenes OIDC-Token und veröffentlichte über TanStacks Trusted Publishing, ohne den Publish-Workflow zu ändern. Die infizierten Versionen deklarierten eine optionale Abhängigkeit auf einen Commit in einem Fork, dessen prepare-Skript die Schadsoftware ausführte und dann absichtlich fehlschlug, sodass npm sie verwarf und keine Spur in node_modules blieb.
• Gültige Provenienz (Miasma, Juni 2026). Injizierte Workflows veröffentlichten aus den eigenen Repositories der Opfer, sodass die infizierten Versionen gültige Provenienz trugen, und eine pro Infektion individuell verschlüsselte Schadsoftware hebelte hash-basierte Erkennung aus.

So prüfen Sie, ob Sie betroffen sind

1. Besorgen Sie sich die Liste der betroffenen Versionen für die jeweilige Welle. Sicherheitsanbieter veröffentlichen sie innerhalb weniger Stunden; Datadog zum Beispiel pflegt ein Repository mit Indicators of Compromise und Listen von Paketen und Versionen.
2. Durchsuchen Sie jedes Lockfile auf jedem Branch, auf dem im betreffenden Zeitfenster das CI lief, nicht nur auf dem Default-Branch.
3. Durchsuchen Sie die Builds selbst. Suchen Sie in CI-Logs nach setup_bun.js, bun_environment.js oder anderen in der Sicherheitsmeldung genannten Dateinamen sowie nach Installationsausgaben, die die betroffenen Versionen nennen. Wenn Sie SBOMs pro Build aufbewahren, durchsuchen Sie sie nach den Versionen.
4. Prüfen Sie Ihre GitHub-Organisation auf neue, nach dem Wurm benannte Repositories, Workflow-Dateien, die Sie nicht geschrieben haben (zum Beispiel shai-hulud-workflow.yml, discussion.yaml oder formatter_*.yml), und selbst gehostete Runner, die Sie nicht registriert haben.

Befehle, die Sie anpassen können. Um die Lockfiles jedes Remote-Branches zu durchsuchen, schreiben Sie die betroffenen Versionen der Welle in affected.txt, ein name@version pro Zeile:

git fetch --all --quiet
for ref in $(git for-each-ref --format='%(refname:short)' refs/remotes); do
  while read -r pkg; do
    name=${pkg%@*}; version=${pkg##*@}
    git grep -n -A3 -F "$name" "$ref" -- '*package-lock.json' '*yarn.lock' '*pnpm-lock.yaml' \
      | grep -F "$version" | sed "s|^|$pkg  |"
  done < affected.txt
done

Um die selbst gehosteten Runner Ihrer Organisation aufzulisten, neue Repositories, die den Wurm erwähnen, und die Workflow-Dateien, von denen bekannt ist, dass der Wurm sie anlegt (ersetzen Sie ORG):

gh api --paginate orgs/ORG/actions/runners --jq '.runners[] | [.name, .os, .status] | @tsv'
gh repo list ORG --limit 1000 --json name,description,createdAt \
  --jq '.[] | select((.description // "") | test("hulud"; "i")) | [.name, .createdAt] | @tsv'
for repo in $(gh repo list ORG --limit 1000 --json name --jq '.[].name'); do
  gh api "repos/ORG/$repo/contents/.github/workflows" --jq '.[].name' 2>/dev/null \
    | grep -E '^(shai-hulud-workflow\.yml|discussion\.yaml|formatter_.*\.yml)$' \
    | sed "s|^|$repo  |"
done

Repositories können auch eigene Runner haben (gh api repos/ORG/REPO/actions/runners), und frühe Wellen legten Repositories in den persönlichen Konten der Entwickler an, deren Tokens sie gestohlen hatten. Bitten Sie Ihre Entwickler daher, auch ihre eigenen Konten zu prüfen.

Warum das Lockfile die Frage nicht klärt

Der übliche Rat lautet, package-lock.json, yarn.lock oder pnpm-lock.yaml nach den betroffenen Versionen zu durchsuchen. Tun Sie das zuerst, aber ein sauberes Lockfile beweist keinen sauberen Build:

• Außerhalb des Lockfiles installierte Pakete. npx some-tool installiert ein Paket, das keine Projektabhängigkeit ist, in den npm-Cache. npm install -g in einem Setup-Schritt, ein in einem Build-Skript installiertes Tool und ein npm install in einem Dockerfile umgehen alle das Lockfile des Projekts.
• Das heutige Lockfile des Branches ist nicht das, das lief. Ein Build vor drei Wochen verwendete, was damals im Lockfile stand, auf dem Branch, der ihn ausgelöst hat. Pull Requests für Abhängigkeits-Updates lassen das CI gegen neue Versionen laufen, bevor jemand sie prüft.
• Caches stellen wieder her, was zuvor installiert war. Ein wiederhergestelltes node_modules oder ein npm-Cache kann eine Version enthalten, die das aktuelle Lockfile nicht mehr nennt.
• npm ci installiert, was im Lockfile steht. War die infizierte Version bereits festgeschrieben, übernimmt eine strikte Installation sie getreu.
• Auch eine korrekt veröffentlichte Version kann bösartig sein. TanStack und Miasma wurden über ihre eigenen Release-Workflows kompromittiert, und die infizierten Versionen von Miasma trugen gültige Provenienz. Die Prüfung, ob eine Version ordnungsgemäß veröffentlicht wurde, sagt nichts darüber aus, ob sie sauber ist.

Was Sie tatsächlich brauchen, ist eine Aufzeichnung, welche Paketversionen jeder Build geladen hat, über jedes Repository und jeden Branch hinweg, für den gesamten Zeitraum, in dem eine infizierte Version in der Registry verfügbar war. Siehe Sind wir betroffen? So bewerten Sie eine neue CVE über Ihre Builds hinweg.

So beheben Sie es, und was Sie tun, wenn Sie noch nicht patchen können

1. Hat ein Build eine betroffene Version installiert, behandeln Sie den Job als kompromittiert. Rotieren Sie jedes Secret, das er lesen konnte: npm-Tokens, GitHub-Tokens, Cloud-Zugangsdaten und Deploy Keys. Weil spätere Wellen gestohlene Secrets in den Konten anderer Opfer veröffentlichten, sollten Sie nicht davon ausgehen, sicher zu sein, nur weil in Ihren eigenen nichts aufgetaucht ist.
2. Leeren Sie die Caches. Löschen Sie GitHub-Actions-Caches und den npm-Cache auf Entwicklerrechnern und selbst gehosteten Runnern, damit der nächste Build saubere Versionen installiert:

gh cache delete --all --repo ORG/REPO   # GitHub Actions caches, per repository
npm cache clean --force
rm -rf node_modules "$(pnpm store path)"   # pnpm; for Yarn: yarn cache clean

3. Pinnen Sie auf eine saubere Version und entfernen Sie die Workflows, Repositories, Runner und Konfigurationsdateien, die der Wurm hinzugefügt hat.

Die Bereinigung verifizieren

1. Jedes Lockfile löst auf saubere Versionen auf. Auf jedem Branch zeigt npm ls <package> (oder pnpm why bzw. yarn why) die installierte Version; keine darf auf der Liste der Welle stehen.
2. Eine saubere Installation enthält keine Dateien der Schadsoftware. Installieren Sie nach dem Leeren der Caches oben erneut und suchen Sie nach den in den Advisories genannten Dateien der Schadsoftware:

find node_modules -name bundle.js -size +3M \
  -o -name setup_bun.js -o -name bun_environment.js -o -name router_init.js

3. Die alten Zugangsdaten funktionieren nicht mehr. Widerrufene npm-Tokens fehlen in npm token list, alte GitHub-Tokens und Deploy Keys sind gelöscht, und Cloud-Schlüssel sind deaktiviert, nicht nur ersetzt.
4. Die Caches sind weg. gh cache list zeigt in keinem betroffenen Repository einen Cache, der vor der Bereinigung angelegt wurde.
5. Nichts, was der Wurm hinzugefügt hat, ist übrig: keine Repositories, Workflow-Dateien, selbst gehosteten Runner oder Konfigurationsdateien für Editoren und KI-Assistenten, die Sie nicht angelegt haben.
6. Der nächste Build ist sauber. Prüfen Sie die Versionen, die er tatsächlich installiert hat, anhand seines Logs oder seiner SBOM pro Build, nicht nur anhand des Lockfiles.

So begrenzen Sie den Schaden beim nächsten Mal

• Deaktivieren Sie Install-Skripte, wo Sie können. npm v12, im Juli 2026 erschienen, deaktiviert Install-Skripte standardmäßig und lässt Sie sie pro Paket erlauben. pnpm und Yarn bieten ähnliche Kontrollen.
• Warten Sie, bevor Sie neue Versionen übernehmen. Die meisten infizierten Versionen werden innerhalb von Stunden oder Tagen gefunden und entfernt. Eine Wartezeit für Abhängigkeits-Updates, die sowohl Dependabot als auch Renovate unterstützen, hält sie aus Ihren Builds heraus. Die Package Firewall von GitHub, seit dem 20. Oktober 2026 als Public Preview für GitHub Enterprise Cloud verfügbar, prüft npm-Installationen auf bösartige Pakete und bietet ebenfalls Wartezeiten.
• Veröffentlichen Sie mit Trusted Publishing und kurzlebigen Tokens. npm hat im Dezember 2025 alle Classic Tokens widerrufen. Verwenden Sie OIDC-basiertes Trusted Publishing aus dem CI statt langlebiger Tokens, und trennen Sie Publish-Workflows von Build- und Test-Workflows.
• Härten Sie die Workflows, die der Wurm missbraucht. Vermeiden Sie pull_request_target, pinnen Sie Actions auf Commit-SHAs und geben Sie GITHUB_TOKEN nur die Berechtigungen, die jeder Job braucht. Siehe GitHub Actions Secrets: Wie sie abfließen und wie Sie sie absichern.
• Beschränken Sie, wohin sich Builds verbinden können. Ein Build braucht seine Paket-Registries und einige APIs. Kann er nur diese erreichen, schlagen die Aufrufe des Wurms an webhook.site oder seine eigenen Server fehl. Siehe wie eine Egress-Richtlinie die Exfiltration aus GitHub Actions stoppt. Das stoppt keine Exfiltration über einen Host, den der Build legitim nutzt, etwa GitHubs eigene API, auf die sich einige Wellen stützten.

Auf Kompromittierung prüfen

Shai-Hulud ist von Grund auf bösartig: Jeder Rechner und jeder Job, der eine infizierte Version installiert hat, hat sie ausgeführt. Die Indikatoren unterscheiden sich je nach Welle; nutzen Sie daher das Advisory für die Welle, die Sie prüfen. Aus Primärquellen:

Welle	Indikatoren	Quelle
September 2025	Schadsoftware bundle.js, SHA-256 46faab8ab153fae6e80e7cca38eab363075bb524edd79e42269217a083628f09; Workflow .github/workflows/shai-hulud-workflow.yml auf einem Branch shai-hulud; ein öffentliches Repository namens Shai-Hulud; Verbindungen zu webhook.site	StepSecurity, CISA
November 2025	setup_bun.js, SHA-1 d1829b4708126dcc7bea7437c04d1f10eacd4a16; bun_environment.js, SHA-1 d60ec97eea19fffb4809bc35b91033b52490ca11 oder 3d7570d14d34b0ba137d502f042b27b0f37a59fa; Repositories mit cloud.json, contents.json, environment.json, truffleSecrets.json und actionsSecrets.json; Workflows .github/workflows/discussion.yaml und formatter_*.yml; ein selbst gehosteter Runner namens SHA1HULUD	Wiz
Mai 2026, TanStack	"@tanstack/setup": "github:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885c" in optionalDependencies; Schadsoftware router_init.js (etwa 2,3 MB) im Paket-Stammverzeichnis; Hilfsskript tanstack_runner.js; Verbindungen zu filev2.getsession.org und seed1.getsession.org bis seed3.getsession.org sowie Downloads der zweiten Stufe von litter.catbox.moe	GHSA-g7cv-rxg3-hmpx

Spätere Wellen änderten die Schadsoftware pro Infektion, ein nicht übereinstimmender Datei-Hash beweist also nichts; gleichen Sie zuerst die Paketversionen ab.

Wann Sie von einer Kompromittierung ausgehen sollten. Behandeln Sie jeden Host und jeden CI-Job, der eine betroffene Version installiert hat, als kompromittiert, auch wenn die Installation fehlschlug oder nichts in node_modules hinterließ. Das TanStack-Advisory von GitHub sagt, dass jede Entwickler- oder CI-Umgebung, die eine betroffene Version installiert hat, „als kompromittiert betrachtet werden sollte“. Prüfen Sie ab der ersten Veröffentlichung der infizierten Version, nicht ab dem Tag, an dem die Welle bekannt wurde.

Rotieren Sie Zugangsdaten. Rotieren Sie alles, was die Installation erreichen konnte. Bei der TanStack-Welle waren das laut dem Postmortem Zugangsdaten für AWS, GCP, Kubernetes, Vault, GitHub, npm und SSH. Prüfen Sie die Audit-Logs Ihrer Cloud auf Aktivitäten der betroffenen Hosts während und nach dem Installationszeitfenster.

Leeren Sie Caches und Artefakte. Durchsuchen Sie Artefakt-Repositories und Dependency-Proxys nach zwischengespeicherten Kopien der betroffenen Versionen und löschen Sie sie, wie die CISA rät. Löschen Sie node_modules, den npm-Cache und CI-Caches; bei der TanStack-Welle war ein vergifteter pnpm-Store-Cache der Weg des Angreifers hinein, prüfen Sie also Actions-Caches ebenso wie Paket-Caches. Bauen Sie alles neu und veröffentlichen Sie alles erneut, was ein kompromittierter Job erzeugt hat.

Was Sie Ihren Kunden sagen

Wenn Sie Software ausliefern, die mit npm gebaut wird, werden Kunden fragen, ob Ihr Produkt den Wurm enthält oder ob Ihre Release-Pipeline kompromittiert wurde. Antworten Sie mit dem, was Sie geprüft und was Sie getan haben:

Wir haben jeden Build von [Produkt] zwischen [Datum] und [Datum] mit den veröffentlichten Listen der von Shai-Hulud infizierten npm-Paketversionen abgeglichen. [Kein Build hat eine betroffene Version installiert.] / [Builds von [Komponente] am [Datum] haben [Paket@Version] installiert; wir haben die Zugangsdaten rotiert, auf die diese Builds zugreifen konnten, [Produkt] aus sauberen Abhängigkeiten neu gebaut und [Version] veröffentlicht. Die Releases [x bis y] sind betroffen; bitte aktualisieren Sie auf [Version].] Wir aktualisieren diesen Hinweis, falls neue Wellen die Lage ändern.

Wenn Sie noch prüfen, sagen Sie das, und sagen Sie, wann Sie antworten werden. Eine erste Stellungnahme und Vorlagen für jedes Ergebnis finden Sie unter wie Sie Kunden nach einem Lieferkettenangriff antworten.

Wie CRACI hilft

CRACI führt Ihre GitHub-Actions-Jobs auf eigenen Runnern aus (runs-on: craci) und zeichnet jedes Paket auf, das jeder Job tatsächlich von npm und anderen Registries lädt, einschließlich aus Caches wiederhergestellter Pakete. Diese Aufzeichnung deckt die oben genannten blinden Flecken ab: npx-Tools, globale Installationen und Installationen in Build-Skripten erscheinen alle, weil die Aufzeichnung aus dem stammt, was der Job heruntergeladen hat, nicht aus dem, was ein Lockfile deklariert hat. Wird eine neue Welle bekannt, schlagen Sie die betroffenen Versionen in den von CRACI aufgezeichneten Builds nach, statt sie aus Lockfiles und Logs zu rekonstruieren, und der Netzwerk-Trace jedes Jobs zeigt, wohin er sich verbunden hat. Die Build-Historie bewahrt jeden vergangenen Build mit seiner SBOM auf, sodass Sie innerhalb Ihres Aufbewahrungszeitraums sehen, welche Builds eine infizierte Version enthielten und in welchem Zeitfenster Sie exponiert waren.

Die Egress-Richtlinie von CRACI begrenzt, wohin sich ein Job verbinden kann, wird vor dem Start des Jobs validiert, blockiert im Zweifel und alarmiert Sie, wenn ein Job versucht, ein Ziel zu erreichen, das die Richtlinie nicht erlaubt. Infizierte Releases mit veröffentlichter CVE, wie die der TanStack-Welle, werden wie jede andere Schwachstelle markiert, und Policy Gates können Builds blockieren, die sie enthalten. CRACI bewertet Pakete nicht auf bösartiges Verhalten und markiert eine neue infizierte Version nicht, bevor es ein Advisory gibt; kombinieren Sie es mit einem Tool zur Paketreputation, wenn Sie infizierte Versionen vor der Installation blockieren möchten.

Sehen Sie die Paketaufzeichnung eines Ihrer eigenen Builds

Weitere Vorfälle: alle Schwachstellen.

Quellen und Aktualisierungen

Primärquellen und Originalforschung:

• CISA: Warnung vom 23. September 2025, KEV-Katalog
• GitHub: GHSA-g7cv-rxg3-hmpx (CVE-2026-45321), unser Plan für eine sicherere npm-Lieferkette, Widerruf der npm Classic Tokens
• Postmortem von TanStack
• Wiz zur Welle vom November 2025 und zu ihren Folgen
• Microsoft zu AntV und die Erkennungshinweise von Microsoft
• Datadog und Elastic zu CHAINDROP
• StepSecurity zur Welle vom September 2025
• FIRST: EPSS-Wert für CVE-2026-45321

Aktualisierungen:

• 2026-11-11: EPSS, die CWE-Klasse und den Credit in der Infobox ergänzt, dazu Prüfungen zum Kopieren und Abschnitte dazu, wie der Wurm funktioniert, wie Sie die Bereinigung verifizieren und wie Sie auf Kompromittierung prüfen, mit Indikatoren pro Welle.

• 2026-11-11: Aus dem Blog in den Bereich Schwachstellen verschoben. Ergänzt wurden die tensorlake-Welle vom 8. Oktober 2026, das Datum des Wiederauftauchens im September 2026, CVE-2026-45321 und ihre Aufnahme in den KEV-Katalog für die TanStack-Welle sowie die Package Firewall von GitHub.

• 2026-09-25: Erstveröffentlichung im CRACI-Blog.