Shai-Hulud-worm besmet meer dan 1.280 npm-pakketten: zo verliep de aanval

Het begin: hoe de aanvallers binnenkwamen

Rond 09.00 uur UTC op 4 augustus 2026 kregen de aanvallers controle over het GitHub-account van Jared Wray, jaredwray . Vanuit dat account plaatsten ze kwaadaardige code rechtstreeks op de main-branch van de repository van keyv. Vervolgens brachten ze nieuwe versies uit van de volledige keyv- en cacheable-pakketfamilie .

De eerste besmettingsgolf omvatte 11 pakketten binnen beide namespaces. Daaronder vielen keyv, cacheable-request, cache-manager, @cacheable/utils, flat-cache en file-entry-cache . Onderzoekers van Aikido Security, StepSecurity — dat de worm onder de naam ChainDrop volgt — Socket en Chainguard bevestigden de aanval onafhankelijk van elkaar in de eerste uren .

De kwaadaardige code: setup.mjs en Math_Symbol.js

Elke besmette pakketversie kreeg hetzelfde herkenbare patroon:

• twee nieuwe bestanden: setup.mjs en Math_Symbol.js;
• een aangepaste package.json met de entry "preinstall": "node setup.mjs" .

Wanneer een ontwikkelaar of CI-systeem vervolgens npm install uitvoerde, startte setup.mjs automatisch vóórdat de installatie was afgerond. Dit bestand fungeerde als dropper: het downloadde een legitieme binaire versie van de JavaScript-runtime Bun vanaf GitHub Releases en startte daarna de zwaar versleutelde tweede fase, Math_Symbol.js, met een omvang van ongeveer 710 tot 728 KB .

Microsoft Threat Intelligence bevestigde dat het om een Mini Shai-Hulud-variant gaat . De payload verzamelde een brede reeks geheimen en inloggegevens uit besmette omgevingen :

• npm-authenticatietokens;
• GitHub personal access tokens (PAT's);
• AWS-sleutels;
• Kubernetes-secrets;
• HashiCorp Vault-tokens;
• Stripe-sleutels;
• Slack-tokens;
• SSH-sleutels;
• Terraform-statebestanden;
• Docker-inloggegevens;
• VPN-configuraties.

Zelfverspreiding: van één maintainer naar duizenden releases

De aanval werd vooral gevaarlijk doordat de worm zichzelf kon voortplanten. Nadat de malware npm-publicatietokens en GitHub-PAT's uit een besmette omgeving had buitgemaakt, gebruikte zij die toegangsrechten om nieuwe kwaadaardige versies van pakketten van andere, niet-gerelateerde maintainers te publiceren .

De omvang liep in korte tijd sterk op:

• Na ongeveer twee uur telde StepSecurity 435 besmette pakketten en 1.557 versies .
• In de vroege middag, CEST, rapporteerde Aikido Security 868 gecompromitteerde pakketten verdeeld over 1.381 versies .
• Aan het einde van de dag lag het totaal volgens BleepingComputer en andere bronnen boven 1.280 pakketten en 1.680 versies .

De worm bleef niet beperkt tot de oorspronkelijke keyv- en cacheable-namespaces. Via gestolen tokens sprong de malware over naar pakketten van onder meer Deliveroo, Ornikar, OneReach, Picsart, Qlik en ServiceTitan .

Waar gingen de gestolen gegevens naartoe?

De buitgemaakte gegevens werden geëxfiltreerd naar een GitHub-repository die door de aanvaller werd beheerd. De worm maakte daarvoor een nieuwe repository aan of gebruikte een speciaal ingerichte exfiltratierepository . In de payload waren bovendien meerdere, redundante exfiltratiekanalen ingebouwd . Daardoor kon de gegevensstroom doorgaan wanneer één kanaal werd uitgeschakeld.

Wat moeten organisaties doen?

Onderzoekers van verschillende beveiligingsbedrijven adviseerden om elk systeem waarop een getroffen pakketversie was geïnstalleerd als volledig gecompromitteerd te behandelen. De belangrijkste herstelmaatregelen zijn de volgende .

1. Zet pakketten direct vast of draai ze terug

Verwijder besmette versies en pin dependencies op bekende schone releases. Gebruik waar mogelijk overrides in npm, Yarn of pnpm — bijvoorbeeld de "overrides"-instelling in package.json — om te voorkomen dat een besmette versie opnieuw wordt geïnstalleerd .

Controleer daarnaast de lockfiles package-lock.json, yarn.lock en pnpm-lock.yaml. Kijk ook naar indirecte dependencies: een pakket kan via een andere dependency zijn binnengehaald .

2. Beschouw getroffen hosts als volledig gecompromitteerd

Alleen de kwaadaardige bestanden verwijderen is niet voldoende wanneer op een machine een besmette versie met npm install is uitgevoerd . Ga ervan uit dat alle geheimen die op dat systeem beschikbaar waren, zijn buitgemaakt. In veel gevallen is opnieuw opbouwen vanaf een schone image veiliger dan opschonen op de bestaande installatie.

3. Trek alle mogelijk blootgestelde tokens in en roteer ze

Intrek en genereer opnieuw alle gegevens die in de omgeving aanwezig kunnen zijn geweest , waaronder:

• npm-tokens, zowel klassieke als granular tokens;
• GitHub-PAT's en fijnmazige tokens;
• AWS IAM- en access keys;
• Kubernetes service-accounttokens;
• HashiCorp Vault-tokens;
• Stripe- en Slack-sleutels;
• SSH-sleutels;
• Docker-inloggegevens;
• VPN-tokens.

4. Schakel token-watchers eerst uit

Een belangrijk detail is de volgorde van handelen. De malware kon soms GitHub-workflow-watchers installeren die een nieuw token opnieuw buitmaakten zodra het werd aangemaakt . Onderzoekers adviseerden daarom om dergelijke monitoring of workflows eerst uit te schakelen of te verwijderen en pas daarna de tokens te roteren .

5. Wis caches en bouw alles opnieuw

Wis npm-, pnpm- en Yarn-caches en ook Docker-buildcaches op ontwikkelaarsmachines en CI/CD-runners . Bouw alle artefacten opnieuw op vanaf schone bronnen. Zo voorkom je dat besmette dependencies in buildcaches, Docker-lagen of bestaande artefacten blijven zitten .

6. Controleer GitHub en CI/CD op blijvende toegang

Controleer GitHub op nieuw aangemaakte repositories, onbekende commits en ongeautoriseerde workflows . Let ook op mogelijke persistentieartefacten, zoals .claude/settings.json en .vscode/tasks.json, die door de worm kunnen zijn aangemaakt . Bekijk daarnaast toegangslogs en de instellingen van self-hosted runners.

Waarom deze aanval zo belangrijk is

De Shai-Hulud-aanval van 4 augustus 2026 laat zien hoe snel één overgenomen maintainer-account kan uitgroeien tot een grootschalig supply-chain-incident. De aanvallers hoefden niet rechtstreeks toegang te krijgen tot alle besmette pakketten: gestolen publicatietokens maakten het mogelijk om de worm van maintainer naar maintainer te laten springen.

De combinatie van een legitieme Bun-runtime voor het uitvoeren van de payload, automatische uitvoering via een preinstall-script, zelfverspreiding en meerdere exfiltratiekanalen maakte deze campagne bijzonder effectief .

Voor ontwikkelteams zijn de lessen duidelijk: pin dependencies, controleer indirecte pakketten, schakel installatiehooks uit waar dat kan, monitor ongebruikelijke GitHub-activiteit en zorg dat er een incidentresponsplan klaarligt voor gecompromitteerde softwareleveringsketens.