TL;DR
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. Een maintaineraccount, een CI-pad of een installatiestap die credentials blootlegt kan genoeg zijn.
Op 2026-05-19 meldde Socket 639 gecompromitteerde pakketversies in 323 unieke pakketten in een Mini Shai-Hulud-golf rond het @antv-ecosysteem. De getroffen set bevatte pakketten voor grafieken, visualisatie, kaarten en React-wrappers die engineeringteams gebruiken zonder die dependencies altijd als security-kritisch te zien.
Het patroon is het echte probleem. npm is nuttig omdat publicatie, scanning en takedown centraal plaatsvinden. Diezelfde centralisatie wordt gevaarlijk wanneer lifecycle scripts, trusted publishing en maintainercredentials worden misbruikt om pakketten in een distributienetwerk te veranderen.
Wat er gebeurde in de AntV-golf
De AntV-golf gebruikte een bekend npm-ingangspunt: uitvoering tijdens installatie. Socket 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 rapporteerde runtime string decoding, versleutelde exfiltratie, gebruik van de GitHub API, gebruik van de npm registry API en een hardcoded HTTPS-exfiltratiepad. Het doel was niet alleen eenmalige malware-uitvoering. Het doel was credentials verzamelen waarmee de malware opnieuw kon publiceren.
Hoe Mini Shai-Hulud het sneeuwbaleffect creëert
De payload richt zich op ontwikkel- en CI/CD-omgevingen omdat die omgevingen publicatierechten bevatten. Een webapplicatie 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 staat niet op zichzelf. Het npm-ecosysteem heeft meerdere incidenten gezien waarbij aanvallers misbruik maken van vertrouwde maintainers, transitieve dependencies en CI/CD-automatisering.
De Axios-analyse van Datadog 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.
De TanStack-analyse van Endor Labs geeft een andere les. TanStack gebruikte npm OIDC trusted publishing, dat langlevende statische npm-tokens verwijdert. De aanvaller kreeg alsnog een geldig publicatiepad via repository- en workflowmechanica. Het resultaat was kwaadaardige versies binnen de TanStack namespace met ogenschijnlijk geldige provenance.
De rode draad is niet één kapotte tool. Het 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 publiceert, 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 workflow of vertrouwensgrens is gecompromitteerd |
De les is niet om npm te verlaten. De les is om automatisch vertrouwen te verminderen op elke plek waar code wordt uitgevoerd.
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 een publicatie-incident wordt in elk pakket dat een ontwikkelaar onderhoudt.
Waar cside past
cside is geen npm registry-scanner en vervangt CI/CD-hardening niet. Dependency scanning, lockfiles, tokenhygiëne en strikte releasecontroles blijven 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 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 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.
