TL;DR: de npm-worm Mini Shai-Hulud
Mini Shai-Hulud laat zien hoe een npm-compromis zich verspreidt na de eerste kwaadaardige publicatie. De aanvaller hoeft niet elke downstream applicatie direct te compromitteren. Ze hebben één maintaineraccount, één CI-pad of één uitvoeringspad tijdens installatie nodig dat credentials blootlegt.
Op 2026-05-19 meldde Socket 639 gecompromitteerde pakketversies in 323 unieke pakketten in een Mini Shai-Hulud-golf die zich concentreerde rond het @antv-ecosysteem. De getroffen pakketset omvatte pakketten voor grafieken, visualisatie, kaarten en React-wrappers die door engineeringteams worden gebruikt zonder dat die dependencies ooit als security-kritisch worden beschouwd.
Het patroon is het echte probleem. npm is nuttig omdat het publicatie, scanning en takedown centraliseert. Diezelfde centralisatie wordt gevaarlijk wanneer lifecycle scripts, trusted publishing en maintainercredentials worden misbruikt om pakketten in een distributienetwerk te veranderen.
Weinig tijd? Bekijk cside's in-browser Magecart- en skimmerblokkering. Dit dekt alles hieronder in één deployment.
Wat er gebeurde in de AntV-golf
De AntV-golf gebruikte een bekend npm-ingangspunt: uitvoering tijdens installatie. Socket's analyse beschrijft een root-level index.js-payload die package.json aanpaste zodat de payload tijdens preinstall draaide.
Dat is belangrijk omdat npm install, pnpm install en yarn install geen passieve downloadstappen zijn. Lifecycle scripts van pakketten kunnen code uitvoeren voordat een ontwikkelaar de pakketinhoud bekijkt of de applicatie start.
De payload was zwaar geobfusceerd. Socket meldde dat die runtime string decoding gebruikte, versleutelde exfiltratie, gebruik van de GitHub API, gebruik van de npm registry API en een hardcoded HTTPS-exfiltratiepad. Het doel was credentials verzamelen waarmee de malware opnieuw kon publiceren, niet alleen eenmalig uitvoeren.
Hoe Mini Shai-Hulud het sneeuwbaleffect creëert
De payload richt zich op ontwikkel- en CI/CD-omgevingen omdat die omgevingen publicatierechten bevatten. Een browserapplicatie heeft misschien alleen een grafiekpakket nodig, maar de machine of workflow die het installeert kan ook toegang hebben tot npm, GitHub, AWS, Kubernetes, Vault, SSH, Docker of databasecredentials.
De credentialdoelen zijn onder meer:
- GitHub-tokens en GitHub Actions OIDC-materiaal
- npm-publicatietokens
- AWS-credentials en instance metadata
- Kubernetes service account-bestanden
- HashiCorp Vault-tokens
- Docker-authenticatiebestanden
- SSH-sleutels en private keys
- Database connection strings
Zodra de malware bruikbare npm-credentials vindt, kan die pakketten opsommen die het slachtoffer mag onderhouden, package tarballs aanpassen, een installatiehook toevoegen, versies ophogen en gecompromitteerde pakketten opnieuw publiceren onder een vertrouwde maintaineridentiteit.
Waarom Axios en TanStack ertoe doen
De AntV-golf stond niet op zichzelf. Het npm-ecosysteem heeft een reeks incidenten gezien waarbij aanvallers misbruik maken van vertrouwde maintainers, transitieve dependencies en CI/CD-automatisering.
Datadog's Axios-analyse beschrijft hoe een aanvaller op 2026-03-31 een Axios-maintaineraccount kaapte en kwaadaardige axios-releases publiceerde die de getrojaniseerde dependency plain-crypto-js toevoegden. Die dependency downloadde en startte tijdens installatie een cross-platform remote access trojan.
Endor Labs' TanStack-analyse laat een andere les zien. TanStack gebruikte npm OIDC trusted publishing, wat langlevende statische npm-tokens overbodig maakt. De aanvaller kreeg alsnog een geldig publicatiepad via repository- en workflowmechanica. Het resultaat was kwaadaardige versies verspreid over de TanStack-namespace met ogenschijnlijk geldige provenance.
Geen enkele kapotte tool op zichzelf verklaart het patroon. De rode draad is de hoeveelheid autoriteit die geconcentreerd zit in ontwikkelomgevingen en releaseworkflows.
npm is tegelijk verdedigingstool en aanvalspad
npm geeft verdedigers een centrale plek om pakketten te inspecteren, malware te markeren, releases te deprecaten en tokens in te trekken. Dat centrale model is beter dan ondoorzichtige losse downloads.
Maar npm geeft aanvallers ook een centrale distributielaag. Als een vertrouwd pakket een kwaadaardige versie uitlevert, kunnen downstream gebruikers die ophalen via gewone installaties, lockfile-updates, CI-rebuilds of transitieve dependency-resolutie.
| npm-functie | Defensieve waarde | Waarde voor de aanvaller |
|---|---|---|
| Centraal register | Maakt scanning, advisories en takedown mogelijk | Geeft kwaadaardige versies brede distributie |
| Lifecycle scripts | Ondersteunen package setup en native builds | Voeren aanvallercode uit tijdens installatie |
| Maintaineraccounts | Maken snel publiceren mogelijk | Veranderen één gecompromitteerde identiteit in veel vergiftigde pakketten |
| Trusted publishing | Vermindert blootstelling van langlevende tokens | Kan worden misbruikt als de workflow of vertrouwensgrens is gecompromitteerd |
De les is om het automatische vertrouwen op elke plek waar code wordt uitgevoerd te verminderen, niet om npm te verlaten.
Wat teams nu moeten doen
Begin bij de build- en ontwikkelomgeving. Elke machine of CI-runner die een getroffen pakket installeerde, moet als blootgesteld worden behandeld totdat credentials zijn beoordeeld.
- Controleer lockfiles en package manager-logs op getroffen versies die op of na 2026-05-19 zijn geïnstalleerd
- Roteer npm-, GitHub-, cloud-, Vault-, SSH-, Docker- en databasecredentials die toegankelijk waren voor die systemen
- Audit maintainerpakketten op onverwachte versies, installatiehooks of toegevoegde git-dependencies
- Gebruik strikte lockfile-installaties zoals
npm ci,pnpm install --frozen-lockfileofyarn install --frozen-lockfile - Schakel lifecycle scripts uit waar dat praktisch kan met
--ignore-scripts, vooral in CI-jobs die geen native builds nodig hebben - Voeg dependency cooldowns of review gates toe zodat nieuw gepubliceerde pakketversies niet automatisch productie binnenkomen
- Monitor uitgaand verkeer vanuit CI en ontwikkelwerkstations op verdachte exfiltratiepaden
Deze controles verkleinen de kans dat één kwaadaardig pakket uitgroeit tot een publicatie-incident in elk pakket dat een ontwikkelaar onderhoudt.
Waar cside past
cside is geen npm registry-scanner en vervangt CI/CD-hardening niet. Je hebt nog steeds dependency scanning, lockfiles, tokenhygiëne en strikte releasecontroles nodig.
cside dekt het browser-runtime deel van de supply chain. Veel productiesites laden third-party scripts, SDKs, tag manager-payloads, analytics-pakketten en dynamisch geleverde code die zich nooit gedraagt als een vaste npm-dependency. Een pakket of leverancier kan tijdens de build legitiem lijken en later toch risicovol gedrag aan de browser leveren.
cside monitort scriptgedrag terwijl het in de browser van de gebruiker draait. Dat omvat scriptwijzigingen, onverwachte datatoegang, verdachte exfiltratiepogingen en browser-side activiteit die dependency-scanners niet meer kunnen zien zodra de code al in productie staat.
De juiste verdediging is gelaagd: beveilig het registrypad, harden CI, roteer secrets snel en monitor runtime-gedrag waar gebruikers de code daadwerkelijk uitvoeren.
