In de week van 14–19 september 2025 is het npm-ecosysteem geraakt door een uitzonderlijk grootschalige supply-chain-aanval. Onderzoekers verwijzen naar de campagne als Shai-Hulud, naar de woestijnworm uit Dune.
Wat begon als een melding over meer dan veertig aangetaste pakketten, groeide binnen enkele dagen naar honderden gecompromitteerde packages, waaronder het veelgebruikte @ctrl/tinycolor. Diverse securityteams en media beschreven het incident als een van de grootste supply-chain-incidenten in de geschiedenis van npm.
Supply-chain-aanval op npm uitgelegd: van ontwikkelmachine naar package-ecosysteem
De aanvallers publiceerden nieuwe malafide versies van bestaande npm-pakketten. Zodra een ontwikkelaar of CI-pipeline zo’n versie installeerde, draaide op de achtergrond JavaScript-code die geheime sleutels en tokens buitmaakte, waaronder GitHub-, npm- en cloud-credentials voor bijvoorbeeld AWS, Google Cloud en Microsoft Azure.
Met die gegevens wijzigde de malware vervolgens andere packages van dezelfde maintainer en publiceerde daar eveneens besmette versies van. Het resultaat was wormachtig gedrag: iedere besmetting vergrootte de kans op nieuwe besmettingen. In meerdere gevallen zijn ook verborgen GitHub Actions-workflows aangetroffen die tijdens builds extra data exfiltreren en persistente toegang mogelijk maken.
Technische kern van de aanval: automatische injectie en exfiltratie
Onderzoek beschrijft een geautomatiseerd proces dat bestaande package-archieven ophaalt, het manifest (package.json) muteert en een kwaadaardige bundel toevoegt. De payload draait bij installatie, scant op secrets en exfiltreert gevonden gegevens naar de aanvallers.
Omdat het proces leunt op reguliere ontwikkeltooling en bekende hostingplatformen, bleef de campagne aanvankelijk onder de radar. De analyses van StepSecurity en ReversingLabs geven reproduceerbare indicatoren en voorbeelden van payloads, inclusief aandachtspunten voor detection-regelaars.
Tijdlijn en schaal: van ruim 40 naar honderden aangetaste packages in enkele dagen
| Datum (2025) | Ontwikkeling | Details |
|---|---|---|
| 14–15 september | Eerste malafide publicaties gesignaleerd | Abnormale releases bij onder meer minder bekende libraries; kort daarop valt @ctrl/tinycolor op. |
| 16 september | Meer dan 40 aangetaste packages bevestigd | Brede waarschuwingen door securityteams; open source-gemeenschap start met lijstvorming en IOC-deling. |
| 16–19 september | Opschaling naar 100–180+ | Nieuwe detecties en forensische updates volgen elkaar snel op; meerdere maintainers draaien releases terug. |
| 18–20 september | Media rapporteren “honderden” | Incident wordt aangemerkt als een van de grootste supply-chain-compromissen in npm-geschiedenis. |
Impact op organisaties: waarom deze supply-chain-worm anders en gevaarlijker is
In tegenstelling tot eerdere npm-incidenten die vooral op cryptodiefstal mikten, jaagt Shai-Hulud primair op ontwikkelaars- en cloud-toegang. Dat vergroot de kans op laterale beweging, misbruik van CI/CD en sabotagerisico’s in releaseprocessen. Doordat de worm zich kan doorzetten naar alle packages van een maintainer, lopen niet alleen directe afhankelijken gevaar, maar ook transitieve afhankelijkheden en interne hulpmiddelen in je pipeline.
Voor organisaties met veel JavaScript- en TypeScript-codebases betekent dit dat traditionele endpoint-defense alleen niet volstaat; je hebt maatregelen nodig in broncodebeheer, build-systemen en artifact-distributie.
Hoe je besmetting herkent: signalen in code, builds en artefacten
Kenmerkende signalen zijn onverwachte post-install-scripts, obfusceerde bundels die direct bij installatie draaien, en plotselinge minor- of patch-releases zonder changelog of met vage omschrijvingen. In CI/CD-logs kunnen onbekende GitHub Actions of webhooks opvallen die geheime waarden lekken.
Directe beheersmaatregelen voor security- en platformteams
Begin met het roteren van sleutels en tokens voor npm, GitHub en cloud-accounts die op build-agents of ontwikkelmachines aanwezig zijn. Forceer waar mogelijk device-gebonden tokens en kortlevende credentials. Scheid ontwikkel-, test- en productieomgevingen om impact van een gecompromitteerde developer-endpoint te beperken.
Beperk publicatierechten tot dedicated release-accounts met hardware-MFA en controleer recent gepubliceerde versies van alle eigen packages op ongeautoriseerde wijzigingen. Schakel protected branches, verplichte reviews en ondertekende releases in.
Strategische lessen: weerbaarheid van de softwareketen structureel verhogen
Deze aanval laat zien hoe kwetsbaar opensource-ketens worden wanneer aanvallers zich richten op maintainers en publicatieprocessen in plaats van alleen op eindgebruikers. Organisaties die zwaar leunen op npm doen er goed aan beleid in te voeren voor dependency-pinning, allow- en deny-lists, herhaalbare builds en het spiegelen en valideren van third-party artefacten via private registries met integriteitscontroles.
Leveranciersmanagement hoort daarbij: leg leveranciers en interne teams duidelijke uitgifteprocedures en incident-playbooks op die rekening houden met package-takeovers en credential-diefstal.
Voor meer informastie rond ketenbeveiliging kun je ook de volgende blogartikelen lezen: beschermen tegen beveiligingsproblemen in de supply chain en een praktijkcase 3CX-aanval op de supply chain onderzocht.
