Hoe wij binnen 72 uur onze klanten beschermden tegen de nieuwste npm-malwaregolf

Wat doet die malware eigenlijk?

Shai-Hulud 2.0 is een geavanceerde supply chain-aanval op het npm-ecosysteem. Het is een zelfreplicerende worm die npm-packages compromitteert om gevoelige informatie (zoals API-keys, tokens, credentials en .env-bestanden) te stelen en zich verder te verspreiden. 

Deze aanval bouwt voort op de oorspronkelijke Shai-Hulud-worm uit september 2025 en heeft al 796 unieke npm-packages geïnfecteerd. Onder deze packages bevinden zich een aantal zeer bekende, samen goed voor in totaal meer dan 20 miljoen wekelijkse downloads.

Het aantal geïnfecteerde packages zal blijven toenemen doordat de worm zich blijft verspreiden. We zullen er voorlopig dus nog niet vanaf zijn.

Wat we hebben gedaan

Zodra het nieuws bekend werd, hebben onze front-end developers direct een sweep gedaan door de codebases van al onze klanten.
Gelukkig stuitten we al snel op een open-source tool die precies deed wat we nodig hadden: automatisch scannen op de bekende kwaadaardige pakketten en versies. De tool is ontwikkeld door security analisten van onder andere Aikido Security.
Hier is de repository van de open-source tool te vinden: Shai-Hulud-2.0-Detector

Omdat de tool lokaal niet bleek te werken, doken we in de codebase. We schreven een fix die ervoor moest zorgen dat de lokale ondersteuning verbeterd werd. Er werd een pull request geopend en binnen enkele uren werd deze gemerged.
De fix bleek succesvol want vanaf dat moment kon de scanner zonder problemen lokaal worden gebruikt.

Dankzij de snelle actie van betrokken open-source developers kunnen codebases nu razendsnel gecontroleerd worden op geïnfecteerde packages. Inmiddels wordt de tool wereldwijd al duizenden keren gedownload en succesvol ingezet.

Wat zonder samenwerking immens veel tijd had gekost, werd nu in slechts 72 uur gedaan. Binnen drie dagen konden alle projecten van Infocaster worden gecontroleerd. Met positief resultaat, want er bleken bij ons geen geïnfecteerde packages aanwezig.

Wat we al doen

Uiteraard maken we standaard gebruik van maatregelen die niet achteraf maar proactief onze security waarborgen. Voorbeelden hiervan zijn:

• CI/CD pipelines die gebruik maken van een lockfile
• GitHub advanced security scans op gebruikte packages en onze eigen code
• Samen keuzes maken over welke (nieuwe) packages we gebruiken
• Pull requests met vier-ogen principe

Voorkomen is beter dan genezen. Met een proces en goede regels zorgen we ervoor dat we de meeste problemen voor zijn. Wanneer we in het nieuws lezen dat er een grote aanval is geweest heeft dit gelukkig dus zelden impact op ons. Hierdoor zijn onze klanten ook dit keer gelukkig gespaard gebleven.

Hoe nu verder?

Omdat het einde nog niet in zicht is zullen we proactief blijven monitoren. We blijven onze klanten beschermen door middel van de security maatregelen die we nu al treffen. Daarnaast zullen we de open-source tool gaan integreren in onze release pipelines.

Conclusie:

• Security is bij ons proactief en geïntegreerd in elk proces.
• Open-source tools en de bijdragen van developers maken snelle reacties mogelijk.
• We stimuleren en waarderen bijdragen aan open-source projecten actief: of het nu gaat om een klantproject of om de beveiliging van het hele ecosysteem.