Veelgebruikte axios-library gebruikt voor supplychainaanval via npm-packages

De veelgebruikte axios-library voor JavaScript-code is gehackt en wordt gebruikt voor een supplychainaanval. Gebruikers van de library installeren hierdoor mogelijk zonder dit te weten malware, specifiek een Trojan voor toegang op afstand. De library wordt tientallen miljoenen keren per week gedownload.

Volgens beveiligingsonderzoekers werden er op 31 maart twee gecompromitteerde versies van de axios-library gepubliceerd, namelijk versie 1.14.1 en de 0.30.4-versie van de legacybranch. Deze versies werden via de npm-packages verspreid. Dit zijn bestanden met JavaScript-code die via de npm-packagemanager verspreid worden. Eind vorig jaar vonden er op een vergelijkbare manier twee grootschalige cyberaanvallen plaats. Tweakers schreef een achtergrondverhaal over hoe dat werkt.

Distributie via gehackt account

De supplychainaanval is mogelijk omdat het npm-account van jasonsaayman, de maintainer van het axios-project, overgenomen lijkt te zijn. Het e-mailadres van de beheerder van de code is onlangs gewijzigd in een onbekend Proton-adres.

De gedistribueerde code is volledig identiek aan de legitieme code van axios, maar bevat een aangepast package JSON-bestand met een nieuwe dependency, extra code die in dit geval zogenaamd nodig zou zijn om goed te functioneren. Dit externe bestand heeft een verhulde payload waarmee malware op het geïnfecteerde systeem wordt geïnstalleerd. Na installatie zou de malware zichzelf verwijderen en het oorspronkelijke JSON-bestand plaatsen.

Terugdraaien en secrets vernieuwen

De beveiligingsonderzoekers raden alle gebruikers van de axios-library aan om terug te gaan naar versie 1.14.0 of 0.30.0 en deze 'vast te zetten', zodat een nieuwe geïnfecteerde versie niet opnieuw wordt geïnstalleerd. Overigens is de huidige malwareversie niet meer beschikbaar via npm. Daarnaast moeten gebruikers de geïnfecteerde bestanden verwijderen en zorgen dat er geen nieuwe scripts worden gedraaid.

Daarnaast zijn er standaard handelingen die ontwikkelaars kunnen doen bij dergelijke npm-supplychainaanvallen. Zo is het gebruikelijk om alle secrets, tokens en keys te vernieuwen. Dit maakt al gestolen secrets nutteloos.

Axios is een populaire library voor JavaScript-code voor het verwerken van HTTP-requests door webbrowsers of node.js-omgevingen.

Reacties (61)

[svane]

Dit lijkt steeds vaker voor te komen, heel ernstig. Eén keer npm install runnen en je bent de controle over je systeem compleet kwijt.

De makers van `pnpm` hebben een artikel geschreven over het verdedigen van dit soort aanvallen.

Als je pnpm ipv npm gebruikt, worden dit soort 'postinstall' hooks niet automatisch uitgevoerd, je moet dit handmatig goedkeuren. (Volgens mij doet Bun het zelfde)

To mitigate this, pnpm v10 disables the automatic execution of postinstall scripts in dependencies.

Samen met de optie om packages pas te installeren als ze meer dan x dagen oud zijn (minimumReleaseAge setting), lijkt mij dit wel een goede en essentiële voorzorgsmaatregel.

Another way to reduce the risk of installing compromised packages is to delay updates to your dependencies. Since malware is usually detected quickly, delaying updates by 24 hours will most likely prevent you from installing a bad version.

Ik zou misschien ook gewoon je dev omgeving volledig in docker draaien. Op die manier kan malware die in de container uitgevoerd wordt ook minder schade aanrichten.

Iemand nog andere ideeën?

[Reactie gewijzigd door svane op 31 maart 2026 11:25]

[genosis]

Er zijn al gevallen bekend van AI malware die je docker uitbreken dus dat is ook geen goede optie.
Ik dacht altijd dat Docker redelijk safe was maar dat is dus niet zo. Ik draai nu riskante dingen in een virtuele machine en ik heb sowieso eigenlijk nergens plain text productie-wachtwoorden meer op mijn laptop staan.

[svane]

Er zijn al gevallen bekend van AI malware die je docker uitbreken dus dat is ook geen goede geen perfecte optie.

Niks is helemaal perfect. Er zullen vast ook wel gevallen bekend zijn van malware die uit een VM breekt. Daarom gaat beveiliging ook in lagen. Een docker omgeving waar de malware zichzelf uit moet hacken is beter dan helemaal geen extra laag. Een VM laag misschien beter, maar zal ook z'n kwetsbaarheden hebben.

Geen plaintext wachtwoorden opslaan is uiteraard ook goed. Hoe meer obstakels voor malware schrijvers hoe beter.

Heb je trouwens een artikel over die AI malware? Ben wel benieuwd. Ik neem aan dat die gaten inmiddels wel gedicht zijn in Docker

[MSalters]

Docker is geen security. Je zit mis als je denkt dat het "niet perfect" is. Docker deelt de kernel gewoon, en root is root binnen die kernel. Wil je een aparte kernel dan heb je een VM nodig.

Uit een VM breken is ook wel eens gebeurd, maar omdat dat wél een security probleem is worden die exploits snel gerepareerd.

[svane]

Docker is geen security.

Is dat zo? Volgens mij ligt het complexer, maar ik hoor 't graag als ik er naast zit.

De documentatie heeft het volgende te melden.

Docker containers are very similar to LXC containers, and they have similar security features. When you start a container with docker run, behind the scenes Docker creates a set of namespaces and control groups for the container.

Namespaces provide the first and most straightforward form of isolation. Processes running within a container cannot see, and even less affect, processes running in another container, or in the host system.

Dat klinkt toch wel degelijk als een vorm van beveiliging.

Ik ben op de hoogte van exploits als deze, maar dat toont juist aan dat er een exploit nodig is om bij het host-systeem te komen.

Als ik npm-malware als normale user uitvoer, kan het zo mijn `~/.kube/config` met gevoelige data uitlezen. Volgens mij gaat dat niet zo simpel vanuit een Docker container.

Stel ik voer `docker run -it ubuntu` uit. Kan ik dan vanuit deze container bij files op m'n host-system (zoals `~/.kube/config`?). Naar mijn weten is dit niet zomaar mogelijk, en dit vind ik wel degelijk een vorm van security. Mocht dat wel zo zijn hoor ik dat graag, ben nieuwsgierig.

Ik heb 't dan over default settings, dus niet over containers met de `--privileged` flag die beveiliging grotendeels uit zet. (Als Docker default trouwens geen, security toevoegt, wat doet de `--privileged` flag dan überhaupt?)

[synoniem]

Je kunt docker rootless of podman gebruiken dan is de aanvalsvector een stuk kleiner.

[genosis]

Ik kan het artikel wat ik gelezen heb niet meer vinden, het ging over een GIT repo waar de readme.MD was geprepareerd, zodra je dat dan gebruikte in combinatie met een LLM/docker kon het uit uitbreken.

Zie dat het veel vaker voorkomt dat er malware uitbreekt, dus ook docker desktop goed up to date houden.

[CH4OS]

Dat komt (mede) omdat Docker standaard niet root-less draait. Wil je dat wel, kun je denk ik beter overstappen op Podman.

[maffiaric]

Docker is inderdaad alleen gemak en om "it works on my machine"-situaties te voorkomen. Veilig niet, want gedeelde kernel. (een heel kort door de bocht conclusie)

[gixslayer]

Natuurlijk is het delaying van package updates ook een risico. Je zou maar een kritiek lek niet patchen dat actief wordt misbruikt omdat je een delay inbouwt. Je kan een afweging maken wat een hoger risico geeft, maar uiteindelijk is er denk ik maar 1 echte oplossing: beperkt het aantal dependencies.

Ik krijg echt altijd de kriebels hoeveel meuk sommige projecten/talen wel niet binnen halen door alle transitive dependencies (good luck dat telkens te reviewen ook). Het is natuurlijk leuk dat iedereen hun eigen spul op npm/pip/etc kan gooien, maar misschien moeten we toch gaan verwachten dat talen zelf een solide standard library hebben zodat veel van die basale packages overbodig worden (i.e. left-pad), en waar je echt een dependency nodig hebt om iets te doen dat deze ook proberen hun dependencies te verminderen.

Ja dan moet je misschien maar wat code opnieuw schrijven die iemand ooit in een package al beschikbaar heeft, maar het is nu wel duidelijk dat elke dependency (direct of indirect) gewoon een security risk is, en je bij sommige van die kleinere/individuele hobby devs ook kan afvragen hoe realistisch het echt is dat zij altijd bestand zijn tegen meer georganiseerde hackers.

Met wat grotere dependencies die ook wat professioneler in elkaar zitten kan je misschien wat hogere verwachtingen hebben, en wellicht meerdere ogen/approval voordat er überhaupt een release kan plaatsvinden zodat de compromise van een individuele dev geen ramp is.

Conclusie: enigste oplossing die ik echt zie is (sterk) verminderen van dependencies.

[eborn]

Good luck with that. We gaan nu juist een fase in waarbij AI alles er bij trekt om in zo'n kort mogelijke tijd een werkende oplossing te realiseren. Daardoor zal er juist steeds minder grip op dependencies komen, omdat men de AI vertrouwd.

[R4gnax]

En daar is afgelopen najaar al op in gespeeld met een aanval gebaseerd op een nieuwe vorm van typo-squatting.

Waar in het verleden vaak malware verspreid werd via packages die bewust van menselijke typefouten gebruik maken (fictief voorbeeld: "axois" ipv "axios") om per ongeluk geinstalleerd te worden, het officiële package als dependency mee te installeren om de typo te pogen te verbergen, en middels een postinstall script malware te plaatsen alsmede zichzelf op te ruimen,

gebeurt dat tegenwoordig door AI te verleiden packages te installeren die functionaliteit lijken te bevatten waar vibe-coding AIs vaak op zoek naar zijn. Deze techniek heeft de naam slop-squatting gekregen. (Inderdaad; een verwijzing naar de roepterm AI-slop.)

[Grauw]

maar misschien moeten we toch gaan verwachten dat talen zelf een solide standard library hebben zodat veel van die basale packages overbodig worden (i.e. left-pad)

Wat dat specifieke geval betreft, JavaScript heeft sinds 2017 String.padStart(), dus die basale package is inderdaad overbodig geworden.

Je wordt op je wenken bediend .

[Reactie gewijzigd door Grauw op 31 maart 2026 12:33]

[NoUser]

Iemand nog andere ideeën?

Updates (geautomatiseerd) pas na een x aantal dagen installeren

[SVMartin]

Idee: packages verplaatsen naar een eigen lokale repo, zodat je die dagelijks kunt scannen, en je altijd kunt terug vinden wat je uberhaupt binnen hebt gehaald.

[R4gnax]

Je hebt al gespecialiseerde diensten die als NPM registry proxy dienen en dit voor je regelen, incl. proactieve early detection op basis van 'vreemde' signalen zoals contactgegevens van ontwikkelaars die ineens veranderen; manueel gepubliceerde packages ipv via reguliere automated builds; etc.

(Dat is trouwens ook hoe deze malware binnen het axios package opgemerkt is.)

[OverSoft]

Ja, als je npm draait om een package.json te installeren vanuit een repo of een download, gebruik dan "npm ci" in plaats van "npm install". Dit installeert de versies die daadwerkelijk in package.json of package-lock.json staan en niet simpelweg de nieuwste.

[R4gnax]

Klopt. Alleen heb je dan ook nog vol-achterlijke tooling zoals Microsoft Visual Studio, die je de keuze daarin niet geeft. Zij hebben al jarenlang een instelling om automatisch NPM packages te restoren als je een project opent, gekoppeld aan het npm install commando ipv het npm ci commando.

Als je die auto-restore instelling niet uitgeschakeld hebt staan, dan ben je bij dit soort supply-chain aanvallen standaard de sigaar.

(En zelfs als je dacht dat je die uit had staan, kun je alsnog de bok zijn - want de settings sync van Visual Studio is zo vreselijk slecht geimplementeerd dat deze soms hotel-de-botel gaat waarbij er een failsafe activeert en allerlei instellingen een reset naar default krijgen. Je bent dus ook gewezen dit met regelmaat te controleren. Of liefst gewoon VSCode te gebruiken. Dat werkt tenminste gewoon.)

[Reactie gewijzigd door R4gnax op 31 maart 2026 19:47]

[readefries]

Ontwikkelen vanuit een devcontainer zodat als je dan iets update alleen die stuk is?

[divvid]

Iemand nog andere ideeën?

klinkt wat flauw, maar misschien een ander platform kiezen? Voor een simpel npm dingetje worden zomaar 100+ dependencies ge-installeerd. Met allemaal mogelijk bovenstaand probleem. Maar zoals je zegt, alles in een container of nog beter, VM, donderen helpt al een beetje

[Reactie gewijzigd door divvid op 31 maart 2026 15:59]

[OB1]

Dit artikel biedt een goede achtergrond over de werking van de malware, tijdlijn van de aanval, de detectie en oplossing: https://www.stepsecurity.io/blog/axios-compromised-on-npm-malicious-versions-drop-remote-access-trojan

De besmette package is uiteindelijk van 00:21 UTC tot ~3:15 UTC online geweest; dus heeft drie uur online gestaan. Als een systeem tussen die tijd bijv. een build heeft gedraaid (specifiek natuurlijk npm install) dan is het systeem dus hierdoor beïnvloed. Op basis van de type exploit lijkt het erop dat een Docker build/container hier ook door besmet kan raken.

[Reactie gewijzigd door OB1 op 31 maart 2026 11:33]

[telenut]

Niet direct uren waarop er bij ons veel updates gebeuren :-) En snel opgelost dus ook.
een MD5 van de malware zou handig zijn om te zoeken of dit ergens gezien is natuurlijk...

[ManIkWeet]

Toch zijn er veel bedrijven die "nightly" iets draaien/bouwen. Natuurlijk heb je te maken met timezones maar het is een goede range aan uren dat (vooral Europeese) bedrijven besmet kunnen raken.

[The Third Man]

Maar welk bedrijf gaat zijn dependencies onbewust updaten tijdens een release cycle? Je build automatiseren bevat niet dit risico omdat het domweg de locked versies de package.json en lockfile toepast. Pas als een dev de dependencies update en die commit in git, gaat de release cycle die nieuwere versie toepassen.

[Reactie gewijzigd door The Third Man op 31 maart 2026 13:22]

[The Third Man]

Zeg maar gerust Sha1 of Sha256 tegenwoordig.

[telenut]

Juist, maar elke scanner ondersteund ze alle 3 wel zeker :-)

[k0enf0rNL]

En daarom voeg je een npm audit stap toe als eerste stap in je pipeline en daarnaast kan je een cooldown gebruiken op npm package updates van een week voordat je ze in je package.json update.

[RobertMe]

Hoe helpt npm audit in deze? Het package/de versie is maar korte tijd gepubliceerd geweest en vervolgens ("meteen") van npm gehaald. Een npm audit zal in deze dus niet geholpen hebben omdat dat ook maar een publieke database is met bekende security issues. En tegen de tijd dat de malware infectie bekend was zal deze ook zeer snel van npm zijn gehaald. Waarbij het mij niet lijkt dat het toevoegen aan een publieke database met security issues substantieel sneller zal zijn dat dat een npm beheerder de versie offline haalt.

Deze security databases zijn voornamelijk gericht op onbedoelde security issues (uit programmeerfouten). Maar dat is hier natuurlijk niet aan de orde omdat er bewust malware is ingebakken. Waarbij dus gewoon de hele versie offline is gehaald.

[kaas-schaaf]

Supply chain attacks vallen ook onder CVEs, meestal worden die echter pas later gemaakt en gepubliceerd.

e.g. Trivy: https://nvd.nist.gov/vuln/detail/CVE-2026-33634

[RobertMe]

Wat dus ook half mijn punt bewijst. Zeker een echte CVE zal tijd overheen gaan terwijl in dit geval de versie vrij snel van npm was verwijderd en daarmee het issue voor "99%" was opgelost (of in ieder geval het acute probleem v.w.b. nieuwe installaties).

Waarbij ik overigens niet weet waar npm audit zijn info vandaan haalt. Van composer weet ik dat die ook gebruik maakt van GitHub security advisories. Dat lijkt mij sneller is dan officiële CVEs.

Maar dan nog zijn deze zaken zo ernstig dat ze vaak ook teruggetrokken worden uit het package registry. En dat zal in principe niet substantieel trager zijn dan de boel opnemen in een vulnerability database. Ook omdat die "vulnerability check" vaak zit ingebouwd in de package manager waarbij er potentieel dus een koppeling is tussen een versie die wordt opgenomen in een vulnerability database en een beheerder die een trigger krijgt om (wellicht) een versie terug te trekken.

[StefanJanssen]

Inderdaad en ik hoop dat mensen tegenwoordig niet blind `npm install` uitvoeren in de pipeline maar `npm ci` gebruiken?

[asdfke]

Dit gaat veel vaker voorkomen in de toekomst...
Het loont bijna om juist een kleine onbekende repo te gebruiken in je dependencies. Minder risico op supply chain hacks.

[Groax]

Nou ja, het kan ook gebeuren dat iemand zijn repo verwijderd en dus het halve internet breekt.
Misschien herinner je het npm left-pad incident nog wel?

[Robtimus]

De repo verwijderen zal het npm landschap niet breken omdat de package nog steeds in de npm registry staat. Pas als een package daaruit verwijderd wordt gaat het fout (dat gebeurde bij left-pad), maar dat is door het left-pad incident een stuk moeilijker gemaakt.

[Groax]

snip..

Ik las verkeerd

[Reactie gewijzigd door Groax op 31 maart 2026 14:18]

[The-Source]

En ook veel minder controle of het gehackt is. Dus tenzij je zelf gaat code reviewen is beide een risico.

[Itrme]

Ik denk dat je dan hele andere problemen krijgt. Zoals kwetsbaarheden die niet op tijd worden opgemerkt of gefixt worden etc. En als je applicatie leunt op die ene repo en niet zonder werkt..

[mavytan]

Is jouw idee niet gewoon een variant van security through obscurity?

[CH4OS]

Voordeel met een grote package dat wel veel gebruikt wordt, is dat veel ontwikkelaars dan naar de code kijken en issues melden wanneer er issues gevonden zijn. Een klein package is dan minder interessant voor dit soort malware, maar dat betekend ook dat het package (waarschijnlijk) vooral voor een niche is bestemd.

In beide gevallen moet je de package (en de ontwikkelaars ervan) maar vertrouwen. Dat kan alleen als je weet wat je binnenhaalt, ook als je een dependency update of upgrade doet.

[Reactie gewijzigd door CH4OS op 31 maart 2026 11:52]

[Ed Vertijsment]

Het loont bijna om juist een kleine onbekende repo te gebruiken in je dependencies. Minder risico op supply chain hacks.

Ik vraag mij of of dat meer veiligheid geeft, hoe weet je of de beheerder daarvan wel goed met zn beveiliging omgaat.

Wat mij betreft is de beste manier om onveilige dependencies te vermijden om geen (of zo min mogelijk) dependencies te hebben, en diegene die je hebt te version pinnen. Ook kan het vermijden van dependencies die minder dan 7 dagen oud zijn al heel veel doen.

[RobertMe]

Als je minder packages gaat gebruiken uit veiligheid ben je natuurlijk weer terug bij het punt waar je je eigen post mee begint. Als je de "kleinere" packages niet vertrouwd, waarom zou je je eigen code dan wel vertrouwen? Sure, je eigen code zul je niet bewust security issues in inbakken. Maar dat betekent niet dat de implementatie ook daadwerkelijk veilig is, en niet vol zit met bad practices waardoor de security in het geding komt (bv SQL injection mogelijk maken, of XSS, ...).

[watercoolertje]

Sure, je eigen code zul je niet bewust security issues in inbakken.

Maar je schrijft niet per ongeluk malware om je eigen device mee te infecteren, terwijl je die dus wel per ongeluk kan injecteren dmv leunen op packages van 3de...

Dus veel issues kan je inderdaad niet ondervangen, maar het specifieke issue uit het artikel is door eigen code te gebruiken juist voor 100% te ondervangen!

[RobertMe]

Dat klopt, en ontkende ik ook niet.

Maar hoe meer ogen er naar kijken hoe veiliger code in principe is. Dus code die ik zelf schrijf ga ik niet van uit dat die 100% veilig is. Gebruik ik code van iemand anders zou ik die nog steeds reviewen. Dus fouten die ik niet zou maken zullen dan ook niet in zo'n package zitten (want dan gebruik ik het niet, of draag ik er aan bij). En mogelijke fouten waarvan ik niet op de hoogte ben of zelf per ongeluk zou kunnen maken kunnen mogelijk door de 3th party ontwikkelaar voorkomen zijn. (En hoe meer er de code reviewen hoe groter de kans dat zaken gevonden en opgelost worden).

En issues door hostile takeovers / account hacks zoals in dit geval zou je als het goed is nog steeds ook zelf kunnen zien door niet klakkeloos te upgraden maar te reviewen. Of bij zeer grote packages dus dat het al gevonden is voordat je zelf update.

TL;DR: ik heb meer vertrouwen in 3th party packages waarbij ik zelf ook een review doe bij updates (en daarin potentieel dingen mis) dan dat ik vertrouwen heb in dat eigen geschreven code 100% veilig zou zijn.

[BCC]

Ja ik ben op dit moment heel blij dat ik voornamelijk in Elixir & Ruby develop.

[joppybt]

Dat is snel; op 31 maart (vandaag) gepubliceerd, door onderzoekers gevonden en Tweakers.net bericht er nu al over.
Dus het probleem is binnen enkele uren ontdekt en opgelost.

[Groax]

Ja, gelukkig dat er mensen zijn die opletten naar de gemaakte changes.

[YannickSpinner]

Alle credits naar meerdere tweakers (ik dacht minstens acht) die deze kwetsbaarheid vanochtend via de submits aan ons door hebben gegeven!

[CH4OS]

Dus het probleem is binnen enkele uren ontdekt en opgelost.

Komt mede omdat Axios best een grote package is in gebruik en daarmee ook veel ontwikkelaars die de wijzigingen bekijken en issues melden. Het laat de kracht van open source goed zien!

[Reactie gewijzigd door CH4OS op 31 maart 2026 11:48]

[R4gnax]

Axios is niet een 'best grote' package - maar één van de allergrootste packages. Het is haast één van de fundamenten van het complete NPM ecosysteem. 174k directe dependents alleen al.

En dat deze malware direct gevonden is heeft niets te maken met open source en veel ontwikkelaars die zogenaamd mee zitten te kijken. De malware heeft namelijk helemaal niet in de broncode op Github gestaan.

Enkel de NPM account van de ontwikkelaar is gecompromiteerd en overgenomen, en is gebruikt om direct manueel een versie van axios 14.1.0 te herpubliceren als 14.1.1 met een extra dependency (de malware payload) aan de package.json metadata toegevoegd.

Het feit dat versie 14.1.1 met de hand gepubliceerd is ipv via een geautomatiseerde build vanaf een Github build agent, dat dit zonder de gebruikelijke provenance informatie die bij voorgaande versies wel zat gebeurd is, dat er op Github niet een versie tag voor een 14.1.1 release bestond, alsmede het feit dat het geregistreerde contact email-adres van de ontwikkelaar ineens gewijzigd was, hebben bij security firma's gespecialiseerd in proactief detecteren van malware binnen NPM vrijwel meteen alarmbellen doen rinkelen.

[Solopher]

Ik gebruik Dependabot, waarbij hij staat ingesteld op "daily" maar dan met een cooldown period van 7 dagen, aangezien Supply chain attacks vaak al binnen 7 dagen worden gevonden.

https://docs.github.com/en/code-security/reference/supply-chain-security/dependabot-options-reference#cooldown-

Defines a cooldown period for dependency updates, allowing updates to be delayed for a configurable number of days. The cooldown option is only available for version updates, not security updates.

Dit kun je voor Docker, composer, NPM, Github-Actions etc. instellen.

[Oon]

Maar dat kan met pnpm dus met de minimumReleaseAge instelling zonder dat je nóg een derde partij in je CI hoeft te verwerken alleen voor het scannen van evt. updates.
Wij gebruiken gewoon ncu om te kijken of er updates zijn

[Thidox]

En dit is dus exact waarom PNPM (Alternatief voor NPM), sinds vorig jaar ergens, postinstall scripts by default blokkeert.

https://pnpm.io/supply-chain-security

edit:
Ik zie dat @svane me net voor was, dus alle hulde en credits daar naartoe!

[Reactie gewijzigd door Thidox op 31 maart 2026 11:47]

[jeroen3]

Fascinerend wel dat het installeren van zo'n tool geschied met, "hier mik dit obfuscated commando in je administrator powershell".

En dan vervolgens nog de suggestie geeft dat het sneller is als je het programma exclude van Windows Defender.

[Oon]

Ik heb dat hele `curl | bash` bij software nooit gesnapt. Ja in principe is het hetzelfde als een installer draaien, maar het voelt toch veel verkeerder om een bash script ongelezen uit te voeren..

[Alfa1970]

Ik denk dat het advies om terug te gaan naar versie x, terwijl je zegt in hetzelfde artikel dat het account van de maintainer gecompromitteerd is, een heel slecht advies.

Met het gecompromitteerde account kunnen namelijk alle versies worden aangepast, niet alleen de laatste.
Naar een oudere versie gaan geeft geen enkele garantie dat die versie niet ook bewerkt is met de malware.

Het betere advies is om zo snel mogelijk van die afhankelijkheid af te komen.
En dat zal voor veel projecten betekenen, uithuilen en opnieuw beginnen.
Dat is helaas echter in de meeste gevallen geen realistische oplossing.
Maar je zal moeten afwegen of een bibliotheek waarvan het beheerders account gestolen is, de tijd waard is die je erin moet steken om er zeker van te zijn dat die bibliotheek, en vooral de installatie procedure, geen malware meeneemt, het waard is om nog langer van die bibliotheek gebruik te maken.
Versus in hoeverre je geïnvesteerd hebt in de afhankelijkheid van die bibliotheek en je niet meer zonder kunt in afzienbare tijd.

[Reactie gewijzigd door Alfa1970 op 31 maart 2026 12:25]

[RobertMe]

npm packages zijn gesigned / gehasht / ... en als je een lock fle gebruikt staat die er in. Dus ik zou niet expliciet een downgrade via npm doen. Maar je kunt prima de oude versie terugzetten in de lock file (op basis van je VCS historie). Daarmee krijg je dan weer de identieke versie die je ervoor had. Ook als die versie("naam") overschreven zou zijn met andere code. Óf npm ci geeft een error dat het gedownloade package niet overeen komt met wat is vastgelegd in de lock file.

Uiteraard kun je wel twijfels hebben bij elke nieuwe versie. Aangezien de aanvaller mogelijk ook de volledige git historie herschreven kan hebben en er een wijziging in een hele oude commit gedaan zou kunnen zijn. Maar dat zou je ook mogelijk ook kunnen controleren. Ik weet niet of de package lock ook de Git commit (hash) vast legt, composer (voor PHP) doet dat wel. Dan kun je controleren of de Git repo zonder verdachte wijzigingen weer gewoon verder borduurt op die commit zoals je zou verwachten. Want bij "historie rewriting" veranderen alle commit hashes. (Hash collissions kunnen wel en zijn volgens mij theoretisch ook al uitgevoerd, maar in de praktijk nog niet zonder dat het opvalt).

[Alfa1970]

Natuurlijk verandert de hash als er iets wordt aangepast, helemaal mee eens.
Maar tenzij je een oude kopie van alle oude hashes hebt, dan helpt je dat niets.

Het grote probleem is dat het account van de eigenaar is gehacked, en die kan alles vervangen inclusief alle hashes. In dit scenario helpen hashes of packages gesigned met een certificaat niet.
Het enige wat je mag hopen is dat de datum ergens in staat en dat het opvalt dat die niet overeenkomt met wat je zou verwachten.

-- edit --
Zoals @vandijkstef hieronder aangeeft kunnen oudere versies van nmp packages niet vervangen worden.

Dus in dat opzicht is het relatief veilig als je een versie installeert die eerder is uitgebracht dan wanneer de hack heeft plaatsgevonden.

Dat op zich zorgt mogelijk wel weer voor andere problemen, maar daar is vast omheen te werken.

De vraag is dan alleen wanneer is het duidelijk wordt de originele eigenaar weer exclusief de controle heeft over het account. En hoe lang dat herstel duurt.

[Reactie gewijzigd door Alfa1970 op 31 maart 2026 19:47]

[RobertMe]

Natuurlijk verandert de hash als er iets wordt aangepast, helemaal mee eens.
Maar tenzij je een oude kopie van alle oude hashes hebt, dan helpt je dat niets.

Ik mag toch hopen dat dat wél werkt. In de package-lock.json staat per package een integrity veld met een sha256. Je mag toch hopen dat na het downloaden van het package even gecontroleerd wordt of de download ook diezelfde hash heeft en hem weggooit als de hash niet matcht.
En aangezien je natuurlijk je code in versiebeheer (Git / ...) hebt weet je prima wat de integrity (/hash) van die oude vertrouwde versie is. (De Git commit hash staat dan weer niet in de package-lock. Dus de "integriteit" van de Git repo kun je niet controleren).

[vandijkstef]

NPM specifiek staat niet toe dat versies die reeds gepubliceerd zijn overschreven worden. Na 72 uur kunnen ze ook niet meer door de beheerders verwijderd worden. En ook bij verwijderen blijft het eerdere gebruik van een versienummer bewaard en kan deze niet meer gebruikt worden. Het advies is dus niet zo slecht als het lijkt, maar is wel specifiek voor deze situatie. In veel andere gevallen heb je absoluut gelijk.

[Alfa1970]

Bedankt voor deze informatie, ik was niet op de hoogte van deze specifieke beveiliging. Ik veronderstelde dat je oudere versies kon verwijderen en dan een nieuwe package kon publiceren onder het oude versie nummer. Dat is op zich wel goed bedacht van NPM.

[Don Key]

waarom is deze frequentie van malware verspreiding een stuk minder in het land der andere talen repos?
Waarom haal je tig deps binnen als chain van een pakket dat je wil installeren, ipv een minimaal aantal in andere taal repos? waarom is de kwaliteit van npm packages doorgaans vrij matig, in vergelijking met andere taal packages?

mss moeten we stoppen met npm? gewoon helemaal stoppen.. De JS wereld maakt zich toch wel wat belachelijk met deze ketting (chain, pun intended) van aanvallen die succesvol zijn ook nog.