Npm-packages met 2 miljard wekelijkse downloads zijn met malware geïnfecteerd

Onbekende aanvallers hebben malware weten te injecteren in meerdere npm-packages die gezamenlijk meer dan twee miljard keer per week worden gedownload. Daarmee worden cryptovalutastelers op geïnfecteerde systemen geïnstalleerd. De aanvallers lijken maintainers te hebben aangevallen via phishing.

Onder andere Aikido Security analyseerde de aanval, die plaatsvond op meerdere npm-packages. Het gaat onder andere om meerdere packages om met ANSI-codes te werken, zoals ansi-regex, ansi-styles en strip-ansi. Aikido Security zegt dat zeker achttien packages werden geïnfecteerd, waarvan de vier populairste, namelijk strip-ansi, chalk, debug en ansi-styles, gezamenlijk meer dan een miljard keer per week werden gedownload. Alle achttien packages samen zouden wekelijks zelfs 2,6 miljard keer per week worden gedownload. Aikido noemt in ieder geval de volgende packages:

Package	Downloads per week
backslash	0,26 miljoen
chalk-template	3,9 miljoen
supports-hyperlinks	19,2 miljoen
has-ansi	12,1 miljoen
simple-swizzle	26,26 miljoen
color-string	27,48 miljoen
error-ex	47,17 miljoen
color-name	191,71 miljoen
is-arrayish	73,8 miljoen
slice-ansi	59,8 miljoen
color-convert	193,5 miljoen
wrap-ansi	197,99 miljoen
ansi-regex	243,64 miljoen
supports-color	287,1 miljoen
strip-ansi	261,17 miljoen
chalk	299,99 miljoen
debug	357,6 miljoen
ansi-styles	371,41 miljoen

De packages worden allemaal gemaakt door Qix, het alias van maintainer Josh Junon. Hij erkent te zijn gephisht. Volgens Junon kreeg hij een phishingmail waarin hij werd gevraagd zijn tweetrapsauthenticatiemethode voor npmjs.com aan te passen. Daarop wisten de aanvallers toegang te krijgen tot alle packages en daarin malware mee te sturen.

De malware die vervolgens via de aanval werd ingeladen, onderschept wallet-api's voor cryptovaluta zoals Solana en Ethereum en steelt daarmee credentials. Volgens Aikido Security kan de malware netwerkverkeer niet alleen onderscheppen, maar ook websites in browsers nabootsen, zodat gebruikers zelf weer gephisht worden. Zo kan het voorkomen dat cryptovalutabezitters transacties doen naar nepaccounts.

Het is op het moment van schrijven niet duidelijk of Josh Junon of Qix weer toegang hebben tot hun packages en inmiddels updates hebben gepusht. Aikido houdt dat bij in zijn blogpost.

Reacties (152)

[controvi]

Weer een rede voor mij om NPM uit mijn projected weg te faseren zoveel dat mogelijk is.
Als ik zie wat er de laatste jaren zoal gebeurd is, en hoe debiel die packages soms zijn, maak ik me toch echt zorgen over de stabiliteit van alles wat er mee werkt.
Als door 1 fout op 1 package direct miljoenen sites onveilig worden, met mogelijk verstrekkende gevolgen, dan liever niet.

Ik snap het nut, maar de risico's beginnen me inmiddels tegen te staan.
Laat staan de hoeveelheid zooi aan dependencies die je moet ophalen om 1 package werkend te krijgen. (granted dat doet hij allemaal zelf, maar het is veel te veel.)
Als je ziet dat er grote, en veel gebruikte, packaged zijn die afhankelijk zijn van packages met 2 regels code, dan twijfel ik alleen maar meer aan de integriteit van de heel NPM.

Ps. bij Composer heb ik dezelfde twijfels.
I know het is iets anders, maar al die 3rd party software die, ook al zijn ze opensource, maar gewoon vertrouwd moeten worden dat 1 van de onderliggende dependencies niet breekt..... Elke keer als ik weer een npm install doe, vrees ik voor een crash van onze websites.

[Cartman!]

Wat is het alternatief? Alles from scratch zelf maken? Dat is simpelweg niet te doen.

[controvi]

I know, maar op deze manier raakt NPM ook al zijn geloofwaardigheid kwijt.
Daarnaast zal ik zeker niet de enige zijn die het gebruikt omdat het niet anders kan.

Voor mijn werk moet ik met Vue3 werken. En helaas gebruiken die ook een heel legio aan npm packages.
Probeer voor de lol eens een project met een Node-modules folder te verplaatsen... Dat duurt een uur als je pech hebt. Dat alleen al is eigenlijk te belachelijk voor woorden.

Wanneer deze onzin dan gebeurd, dan weet je ook als dev niet meer of je straks niet al je gebruikers data op straat hebt liggen, omdat 1 flippo ergens op de planeet met een package van 1 regel code een fout maakt en plots jouw database gedumpt wordt.

Is it likely? No.
Could it happen? definitely.
Would you know it in time? Nope.

Als zoiets gebeurd heb je het totaal niet door tot het te laat is.
Waarom? Omdat niemand naar de packages en dependencies kijkt die ze gebruikt.
Want om jouw woorden te gebruiken, "Dat is simpelweg niet te doen".

[spasma]

Gebruik harde versienummers en commit je package-lock.json (of yarn.lock, pnpm-lock etc etc.). Scheelt al een hoop ellende

[R4gnax]

als je een lockfile mee commit hoef je niet eens harde versie nummers te gebruiken.
Je ontwikkelteam hoeft alleen maar te onthouden enkel met npm ci packages te restoren, en niet met npm i.

[Ghoelian]

Dat zou je, buiten security redenen om, sowieso moeten doen. Anders zit je mogelijk package versies te installeren waar je software nooit mee getest is.

Ik had bij een vorige werkgever wel een collega die ook echt een goede programmeur was, maar die wel sterk van mening was dat lockfiles niet gecommit hoorden te worden. Ik weet alleen niet meer wat de reden daarvoor was helaas.

[air2]

Apart het staat expliciet in de documentatie van npm/yarn dat je ze moet committen.

[edwinjm]

Lockfiles moet je juist committen, zodat iedereen (en serveromgevingen) precies dezelfde versies gebruiken.

[sebrassino]

Je ontwikkelteam hoeft alleen maar te onthouden...

Ook dat gaat vroeg of laat een keer mis.

[Tubby]

Het controleren van de gebruikte dependencies is onderdeel van je werk. Zorgen dat je met een beperkte set "approved" groep id's werkt is daarin wel best practice. Als je binnen de volwassen projecten blijft en regelmatig update zit je over het algemeen goed.

In frontend land kun je niet bijna niet zonder npm, of je moet echt bij alleen jQuery blijven oid.

[ultimasnake]

Maar is dat ook zo? Volwassen projecten op NPM hebben weer hun eigen dependencies en met het aantal miljoenen downloads op deze packages doet mij vermoeden dat dit niet 1 op 1 gebruikte libs zijn maar juist weer gebruikt worden door deze "volwassen" dependencies... Je vertrouwen op een project en zijn beheerder is onvoldoende als je (bij wijze van) een color converter package hebt gebruikt die zelf weer een van deze libs installeert.

Uiteindelijk is het enige "veilige" zelf alles schrijven, maar of dat veiliger is dan het gebruik van een getest en publiek ingezet package is nog maar de vraag ;-)

[Tubby]

Als ontwikkelaar die packages gebruikt draag je ten alle tijden de eindverantwoordelijkheid. Je risico inschatting zit dus o.a. op de makers / organisaties van die packages en hoe ze omgaan met security issues / release frequentie e.d.

In algemene zin staat de apache foundation en spring op mijn whitelist; maar dat is in Java land. in Npm land beoordeel ik ook de projecten en hoe hun depedencies weer beheren / daarmee omgaan.

Vervolgens is het per package nog een risico inschatting wat het doet en de gevolgen daarvan; korte samenvatting, als je enige security-layer je frontend is dan is dat een risico op zichzelf :)

[Hugo_ijslijk]

Dat is wel makkelijker dan gezegd. Je gebruikt een paar standaard packages zoals Vue, Vite en Vitest, en je haalt honderden transiente dependencies binnen waar je nog nooit van hebt gehoord. Ik ben redelijk strict met dependencies, maar ik heb bij mijn eigen project even gecheckt of ik "is-arrayish" gebruik (een compleet nutteloze dependency tegenwoordig. En ja hoor, het lijntje gaat als volgt: @graphql-eslint/eslint-plugin ➡️ graphql-config ➡️ cosmiconfig ➡️ parse-json ➡️ error-ex ➡️ is-arrayish.

En dan gebruik ik alleen maar packages van "grote" "vertrouwde" publishers. Het probleem is dat er een aantal handige libraries zijn (cosmiconfig bv) die idiote kleine libraries binnenhalen, met elk weer 10 idiote eigen dependencies

[Tubby]

Ho, ik zeg niet dat het makkelijk is. Ik zeg dat als je in jouw software projecten dependencies gebruikt dat het gebruik daarvan ook jouw verantwoordelijkheid is.

Dat maakt dat het beoordelen daarvan en het inschatten van de risico's ook onderdeel is van je werk. (en het regelmatig bijwerken; etc; etc)

Life comes in package deals

in dit scenario heeft de maker ook netjes een check-cmd gedeeld https://github.com/chalk/chalk/issues/656 dus je kunt je project ook checken. Daar bovenop is het ook best-practice om een package-lock.json mee te committen en in je pipeline npm-ci te gebruiken zodat je build ook zuiver die deps gebruikt.

[Reactie gewijzigd door Tubby op 10 september 2025 11:33]

[Cartman!]

Maar je zegt het te willen uitfaseren en komt toch tot de conclusie dat dit eigenlijk niet kan want dan moet je zonder dependencies gaan werken en dat kan in praktijk eigenlijk niet.

[controvi]

Daarom zeg ik ook in diezelfde zin "zover het kan".
Ik heb er een hekel aan dat het niet op een andere manier kan, dus ik ben verplicht het te gebruiken.
Vooral als je platformen als Vue gaat gebruiken, dan zit je er direct aan vast met de minimum basis.

I know all that, maar dan kan ik nog wel proberen zoveel mogelijk zelf te doen als dat realistisch mogelijk is.

[Cartman!]

En hoe dan precies?

[controvi]

wat is dat nou voor vraag.
Als ik een iets heb gemaakt en gebruikte er packages voor, en ik kom erachter dat ik het zelf ook prima kan maken, dan kan ik dat toch doen?

[Cartman!]

Dat kan, maar ga je dat in praktijk ook echt doen? Een Vue bouw je niet even na en wat die onder de radar allemaal in gaat laden heb je geen controle over. Mijn punt is, die ene library die jij misschien stopt met gebruiken, gebruikt een van je andere dependencies misschien alsnog en dan heb je niks gewonnen. Met zelf maken introduceer je ook nieuwe risico's.

[controvi]

Maar daarom zeg ik ook in mijn originele comment, "zover het kan."
Dat betekend niet dat ik alles maar zelf ga maken. Als het moet, dan moet het maar.
Maar als ik iets kan bouwen zonder weer een berg packages te moeten installeren, dan zou ik daar eerder voor kiezen.

Maar again, mits dit realistisch is.

Dat ik een probleem heb momenteel met NPM betekend niet dat ik maar alles zelf ga maken.
Zoals VUE zit je er sowieso aan vast, dus ja, wat zijn mijn opties? Niet heel veel als je het gooit op tijd vs geld.

Dus nee, ik bouw het niet zelf, en gebruik het maar als het moet.

[Cartman!]

Dus samenvattend gaat er niet zoveel veranderen, dat was m'n punt ;)

[controvi]

klopt, mijn punt is dat ik dat jammer vind ;)

[kabelmannetje]

Hoe ga je precies alle dependencies zelf herschrijven?

[Joepin]

alles forken, EZ

[controvi]

Zeg ik dat ergens dan?
het liefst zou ik al die package managers zien verdwijnen en basis functionaliteit in de frameworks zelf zien ingebouw worden.
Helaas is dat niet zo en ben je zelfs met een basis instalatie van VUE al verplicht een hele lading packages mee te nemen.

En daar heb ik dus een hekel aan.
Helaas moet ik het risico maar nemen dat mijn hele project onderuit gehaald kan worden door een sub package met 1 regel code die makkelijk zelf geschreven had kunnen worden.

NPM en andere package managers zijn zo overspoeld met basic packages die 1 ding doen die je zelf net zo makkelijk had kunnen schrijven als bouwer van zon npm package.
Waarom zo lui zijn en dan een andere 1regel package includen voor die functionaliteit.
Het haalt in mijn optiek het hele idee achter die libraries onderuit en maakt het meer gevaarlijk om te gebruiken dan wat anders.
Je bent niet alleen afhankelijk van package X die je installeerd, maar ook van de 100 die andere die Package X gebruikt.

[kabelmannetje]

Dan schrijf je toch gewoon zelf die dependancy?

[controvi]

Waarom zou ik dat gaan doen?
Ik kan vervangen wat ik zelf kan en houden wat niet zelf kan.
Snap niet waarom dat zo moeilijk is. Ik zeg nergens dat ik het niet gebruik, je bent redelijk verplicht het te gebruiken.
Dus het moet maar.

[kabelmannetje]

Je geeft een hele lijst hoe slecht npm wel niet is. Dus, blijkbaar is het helemaal niet slecht als je het gewoon blijft gebruiken.

[controvi]

Dat is een heel slecht argument.
Wanneer er door een opdrachtgever, of in mijn geval, mijn werkgever gekozen wordt om bepaalde dingen op een website te plaatsen, en de enige realistische manier is om daarvoor met npm te moeten kloten, dan heb ik weinig andere keuze.

Kosten technisch kan ik niet een jaar gaan ontwikkelen op iets wat in NPM met 2 dagen in elkaar kan zitten.
Dat betekend niet dat het niet slecht is, of gewenst. Soms zijn er dingen waar je maar mee moet dealen, of je het nou leuk vind of niet.

Je kunt een ruk auto hebben die amper heel blijft bij een drempel en amper van A naar B komt maar hij komt er wel.
Dus schijnbaar is de auto helemaal niet slecht want je rijd er mee door.

[kabelmannetje]

Dus, gewoon de NPM gebruiken. Allemaal zaken bedenken die totaal onrealistisch zijn, daar heeft niemand wat aan.

[controvi]

Nou prima, dan laat het je dus compleet koud of je website, zonder dat je het door hebt, is geïnfiltreerd door kwaadwillende die de data van je gebruikers willen bemachtigen.

Klinkt alsof je een geweldige admin van je projecten bent met absolute vertrouwen in elke dev op de planeet.

Het hele artikel gaat over precies dat waar ik het over heb en je slaat het weg als onrealistisch.
Als het zo onrealistisch was, bestond dit artikel niet.

[kabelmannetje]

Prima, dan gebruik je toch gewoon geen externe repositories?

[Chevalric]

Dit is echt pertinente onzin. Als je een high level front-end package gebruikt (React, Angular, Vue, NestJS, etc.) dan zit daar een enorme boom aan low-level packages onder. Ook de packages die hier geinfecteerd waren, zijn packages die vooral als sub-dependencies gebruikt worden, daarom hebben ze zulke hoge download-aantallen. En het zijn ook altijd juist die low-level packages die het doelwit zijn van hackers, juist omdat ze zo'n groot attack surface hebben.

En om dan te roepen "skill issue" is echt enorme bullshit. Of zeg je dat ook als Java devs Spring Boot gebruiken? Het grootste probleem in front-end land is dat er geen standard library is die veel van dit soort low-level functies biedt. Dus moet je het of zelf bouwen (met alle issues vandien), of een battle-tested npm package binnenhalen. Drie keer raden wat de meeste mensen kiezen.

[kimborntobewild]

"Is it likely? No.":
Ik zou zeggen: yes.

[SilentLucidity]

even een sidenode, dat dat verplaatsen zo lang duurt komt ook door je OS. Windows maar in mindere mate ook Mac en Linux zijn nou eenmaal niet zo goed aan het verplaatsen van code. Los van dat 3, 4, 500mb aan 3th party javascript natuurlijk exorbitant is, zou dat op een gemiddelde SSD in een paar seconden verplaatst moeten zijn. Maar een consistente snelheid haalt Windows bijvoorbeeld niet bij tienduizenden bestandjes van een paar KB. Als je dit wel wilt doen: map zippen -> zip verplaatsen -> zip uitpakken. Dan kopieert Windows die MB's in een paar seconden, en ben je hoogstens 10 minuten bezig.

[controvi]

mee eens, maar doelde daarmee ook op de enorme hoeveelheid files met code die meekomt met zelfs maar een klein project.

[Ed Vertijsment]

Niet als nee, maar veel dingen waarvoor een library geïnstalleerd wordt kunnen gewoon zelf geïmplementeerd worden, en dan houd je de list net dependencies klein.

[Cartman!]

Dat klinkt logisch maar als jij 1 library installeert komen er misschien alsnog 1000 (sub) dependencies mee waar je geen invloed op hebt behalve die library niet installeren. Als je die echter nodig hebt is dat alleen geen optie.

[Ed Vertijsment]

Klopt, dit is dan ook altijd een goede check om uit toeren (dependencies van dependencies checken).

[Cartman!]

Dan ben ik toch benieuwd hoe je dat in praktijk zou doen. Library doet precies wat je wil maar omdat er 3 niveaus diep ergens een bepaalde (welke dan?) dependency is kies je ervoor het niet te gebruiken. Dan ga je naar een alternatief toe en daar is hetzelfde aan de hand. Ga je dan toch alles from scratch schrijven, ook al gaat je dat maanden kosten?

[Ed Vertijsment]

Dat is een kosten baten beslissing, maar je kunt wel kijken naar alternatieven. Mocht je helemaal je attack vector kleiner willen maken zou je dependency kunnen installeren en de subdependency overriden naar iets wat je wel zelf in beheer hebt en waarvan je de interface spiegelt. Maar zo ver ga ik eerlijk niet.

[Cartman!]

Maar zo ver ga ik eerlijk niet.

Dat was het punt dat ik wilde maken Er zijn heel veel opties om het veiliger te maken maar dat is veel te veel werk en dus doet niemand het. Je weet immers nooit welke package de volgende is en dan is de enige optie om alles zelf te maken of maar te vertrouwen dat het wel los al lopen.

[Reactie gewijzigd door Cartman! op 9 september 2025 11:41]

[Ed Vertijsment]

Het punt wat ik wou maken is dat er een balans in en dat je niet zomaar voor alles een dependency hoeft te gaan installeren en het niet veel werk is om de impact van een dependency qua andere dependencies te checken. Simpele designkeuze die je attack vector een stuk kleiner maakt.

[Cartman!]

Als je het hebt over "is-odd" of "is-arrayish" ben ik het helemaal met je eens ja, dat slaat echt nergens op .

Probleem is dus alleen dat ik bijv een dev dependency heb die daar wel gebruik van maakt en dan heb ik er weer geen invloed op.

[Reactie gewijzigd door Cartman! op 9 september 2025 17:11]

[WargamingPlayer]

Volgens mij moet je gewoon een code review doen. Open Source moet je altijd reviewen lijkt mij. Bij ons is het verplichte kost wanneer er externe code wordt gebruikt.

[Cartman!]

In een ideale wereld doe je dat maar in praktijk geloof ik niet dat dit tot meerdere lagen diep gebeurt. Als ik een pdf moet genereren pak ik daarvoor een library met voldoende sterren, veel downloads die actief wordt onderhouden. Als daar (tien)duizenden regels code in zitten moet ik er toch wel op vertrouwen dat dit klopt.

Ik heb net een (relatief klein) project laten reviewen door een gerespecteerde partij en die waren er 2 weken mee bezig en vele duizenden euros verder. Je kunt mij niet wijsmaken dat je elke dependency (en de dependencies daarvan) nauwkeurig kunt reviewen op hoog niveau waar je kunt uitsluiten dat er in kwetsbaarheden in zitten.

[Reactie gewijzigd door Cartman! op 8 september 2025 22:47]

[WargamingPlayer]

Maar deze case geeft dus aan dat je Open Source libraries dus gewoon niet kan vertrouwen. Je zou dus een code check op een library moeten hebben voordat deze beschikbaar komt. Wanneer er 1 schakel in de ketting niet te vertrouwen is, kan je de hele ketting niet vertrouwen.

Ondanks dat ik met vakantie ben heb ik al naar aanleiding van dit nieuws aangegeven bij een aantal teams dat dit aandacht nodig heeft. Heb best wel wat paniek reacties gekregen, maar zie over een week wel hoe ze het opgelost hebben. (iets met procedures niet gevolgd enzo)

[Cartman!]

Closed source kun je het zo min vertrouwen. Zelf alles maken is praktisch niet haalbaar en waarschijnlijk maak je dan zelf de fouten die in andere libraries allang opgelost zijn.

Code check klinkt leuk maar dat is alleen haalbaar als je een dedicated security researcher tot je beschikking hebt misschien. Die zal al snel overlopen van het werkt met de snelheid waarmee development beweegt.

[WargamingPlayer]

En wat als dan je data op straat ligt?

[Cartman!]

Hoe wil jij het voorkomen? In de praktijk dan, niet de theorie.

[latka]

Geen JavaScript frontend technologie gebruiken is een optie.... Niet populair maar wel effectief. Een taal gebruiken met een fatsoenlijke set aan standaard bibliotheken zodat je veel minder 3rd party dependencies hebt lost ook een hoop op.

[Cartman!]

Het JS ecosysteem heeft de meeste wildgroei, wat dat betreft helemaal eens. Echter zijn supply chain attacks in andere talen ook niet vreemd en is het denk ik inherent aan software development. Stel je ontwikkelt wel alles veilig, dan kan er een bug in de cpu zitten waardoor er alsnog data kan lekken

[Reactie gewijzigd door Cartman! op 9 september 2025 07:11]

[latka]

Ze zijn mogelijk in andere talen, in npm land is het een gegeven. Dit is niet de eerste keer (of de 2e).

[Zoop]

Dit is net zo'n argument dat MacOs veiliger is tegen virussen omdat het een kleinere doelgroep heeft dan Windows. Javascript komt het vaker voor puur door de populariteit en scope, maar het is echt niet dat dit inherent is aan Javascript of dat het meer risico loopt dan welke andere taal dan ook.

Het is een interessante attack vector voor hackers, daarom gebeurd het, niet meer en niet minder.

Tegenwoordig komt het zelfs meer voor door het gebruik van AI die nog wel eens gehallucineerde packages will gebruiken, en nu zijn er een aantal bijdehante knakkers die de veel-gehallucineerde-package-namen daadwerkelijk gaan aanbieden (met allerlei gore troep erin, uiteraard). Is volledig te wijten aan het feit dat je alle output van een AI bot dient te controleren, maar dit is ook weer een ding, en komt in elke taal voor.

[latka]

Het is inherent aan het roekeloos programmeren en dat komt zeker in php en JavaScript land vaker voor.

[latka]

Nee, het argument is dat JavaScript zo'n arme standaard omgeving heeft dat je voor van alles en nog wat een dependency nodig hebt (met isOdd() als grootste uitschieter). Omdat je vanaf regel al met 3rd party dependencies moet werken ben je het controleren snel zat. Tegen de tijd dat je live gaat zit er meer 3rd party code dan eigen code in het product. Het is daarmee ondoenlijk om in een redelijke tijd te zien wat je allemaal gebruikt. Gecombineerd met veel ontwikkelaars die automatisch de laatste versie van alles gebruiken (dankjewel NPM) ipv. een specifieke geteste bekende versie is het een makkelijk doelwit met makkelijke slachtoffers. Het heeft niets met doelgroep te maken maar met zwakke technische keuzes.

[Herko_ter_Horst]

En wat is het alternatief (voor front-end web development)?

[Reactie gewijzigd door Herko_ter_Horst op 9 september 2025 13:51]

[Zoop]

Die zelfde cultuur zie je anders gemakkelijk terug in elke andere programmeertaal.

Het volk dat voor een isOdd een dependency gaat zitten installeren ontkom je niet aan.

Ok, sure, ik snap je punt dat het naar is in JS dat je überhaupt daar een functie voor nodig hebt (alhoewel num % 2 super kort te schrijven is). Maar dat men voor dat soort kleine dingen al een dep installeert ligt toch echt aan die mensen en niet aan de taal. En dat soort lui heb je in elke omgeving.

Dus nee, niet mee eens. Heeft alles met de grootte van de doelgroep te maken. Die zwakke technische keuzes worden overal gemaakt.

[Loller1]

Sorry, wat? Dit gebeurd met npm net zo vaak als met eender welke andere package repository van zijn caliber. Je ziet het alleen vaker in het nieuws omdat npm simpelweg zo'n groot bereik heeft. Als iedereen verplaatst naar een andere taal gaat dat daar net zo'n groot probleem worden.

[Cartman!]

Ik ken weinig websites gebouwd met cobol....

[WargamingPlayer]

Controles inbouwen. Je hebt hele mooie tools en frameworks hiervoor. Sowiso dat er bij een publish altijd het vier-ogen principe plaats moet vinden, met verschillende accounts. Dan ligt de verantwoordelijkheid ook bij de maintainer, maar kunnen dit soort zaken nooit plaats vinden omdat er een tweede persoon goedkeuring moet geven.

[Cartman!]

Dat had in dit geval alleen niks opgelost want de maintainer heeft het niet zelf gepubliceerd omdat zijn account was overgenomen.

[kozue]

Nee, deze case geeft dus aan dat je juist open source moet gebruiken. Hier is de code aangepast door een aanvaller die toegang had tot de bron. Als dat closed source was, kreeg je gewoon een nieuwe blob als update en kon je nooit controleren wat er in zit. Met open source kun je in ieder geval altijd zelf kijken wat er veranderd is sinds de laatste versie.

[WargamingPlayer]

Want het wordt na iedere release gecontroleerd?

[kozue]

Waarschijnlijk bij de meesten niet, maar je hebt in ieder geval de mogelijkheid, in tegenstelling tot closed source. Closed source heeft echt 0 voordelen tov open.

[Reactie gewijzigd door kozue op 9 september 2025 22:13]

[WargamingPlayer]

Ik snap je standpunt. Maar is open sources dan niet gevaarlijker omdat iedereen er van uit gaat dat iemand er wel eens naar gekeken heeft maar uiteindelijk niemand dat doet.

Zelfde is wanneer iemand in het water valt, dan kan je beter 1 persoon hebben die dat ziet dan 100 mensen omdat bij 100 mensen men denkt “iemand anders zal wel springen”.

Hoe veel open source is er veilig omdat er naar de source is gekeken?

Hoe veel closed source is er onveilig omdat er niemand van buiten naar heeft gekeken?

Ik ben van de open source, maar het “iemand anders zal het wel controleren” idee is een beangstigend fenomeen.

[kozue]

Oh, maar ik beweer ook nergens dat iemand anders het wel zal controleren, en ook niet dat je daar vanuit moet/kunt gaan. Ik beweer alleen dat je zélf die mogelijkheid hebt, als je daar behoefte aan hebt. Bij closed source is je code sowieso niet gecontroleerd, maar gewoon "wat de maker het wild in heeft geslingerd". Het grootste deel van de wereld controleert helemaal niks en maakt het niet uit of de code open of gesloten is, maar voor het deel dat dat wel iets uitmaakt is open niet alleen belangrijk maar wellicht zelfs cruciaal.

En als er iemand in het water valt, heb ik nog steeds liever 100 mensen er om heen dan 1. Mijn beperkte ervaring is dat er dan wel meerdere mensen het water in springen, maar natuurlijk niet alle 100, want ze reageren niet allemaal even snel, en degenen die te laat reageren hoeven het water niet meer in. Maar als er maar 1 staat en die kan net toevallig niet zwemmen, heb je pech. Maar dat is verder te veel off-topic.

[kimborntobewild]

"Maar deze case geeft dus aan dat je Open Source libraries dus gewoon niet kan vertrouwen.":
Je kan geen enkele library vertrouwen, of het nu closed of open source is.
Bij Open Source kan je tenminste zien wat er mis is (gegaan), bij Closed Source is dat niet te doen, nog afgezien van het feit dat reverse engineering verboden is.

Open Source is een _voorwaarde_ voor veilige software, geen garantie.
Zo is het hebben van een benzinetank een voorwaarde om te kunnen rijden met je benzineauto, maar geen garantie.

[Sleepkever]

Ga jij alle geminifiede code in nom reviewen dan? In dit geval zijn de aanpassingen zelfs buiten source control om gedaan dus dat is dan je enige optie.

[kimborntobewild]

Alles from scratch zelf maken? Dat is simpelweg niet te doen.

Dat maakt niet uit: als iets niet veilig kan, moet je het gewoon helemaal niet doen.

[Cartman!]

Dus je voorstel is om wereldwijd te stoppen met (software) development?

[kimborntobewild]

Dus je voorstel is om wereldwijd te stoppen met (software) development?

Nee, maar doe het veilig.

[Cartman!]

Dat gaat niemand je kunnen garanderen.

[Martinspire]

Zo heet wordt de soep niet gegeten. Ja er zijn aardig wat attack vectors, maar veel packages worden niet vaak bijgewerkt, ook om de invloed minder groot te maken. Ik zie hier veel packages voorbij komen, waarvan ik mij afvraag hoeveel nut ze werkelijk in de meeste projecten hebben.

Het feit dat ze erin zitten, zegt weinig over hoe gevaarlijk ze zijn. Daarnaast rekenen de meeste van dit soort malware op een post-install script. Dus als je die bewust uitschakelt, heb je daar al minder last van.

Wel is het verstandig om een npm mirror te gebruiken, dan heb je meer kans dat je websites live blijven, omdat ze niet per se een nieuwe package hoeven te pakken. NPM is net zo gevaarlijk als welke andere package library.

Wel zijn er de laatste tijd wat problemen mee geweest. NX had een week of wat geleden ook malware erin zitten. En iets verder terug was een hele belangrijke package onterecht als malware aangemerkt waardoor weer andere packages op hun gat gingen. Dit zijn zaken waar ze vast wel mee bezig zijn, maar wat ook weer heel complex is om op te lossen. Maar ik denk dat de javascript-wereld ook wel beseft dat dit niet zoveel langer kan. Zoveel code afhankelijk van zo weinig kritische packages/mensen. Ik heb al een paar packages hun eigen dependencies zien doorlopen en enorm snijden in de afhankelijkheden. Dat lijkt mij ook wel de weg vooruit, voor veel van dit soort projecten. Je hebt niet een extra package nodig om een string op te knippen. Dat kun je best zelf doen. En alle packages die al jaren niet gewijzigd zijn, hoef je ook niet elke keer op te zoeken voor installatie. Daar gaat de komende maanden/jaren veel in veranderen.

[controvi]

Daar kan ik me helemaal in vinden.
Ik weet dat het niet heel kritisch is, maar vind het wel interessant hoe online, en ook de bedrijven waar ik mee gewerkt heb, vaak aangeven "gebruik geen derde partij software als het niet nodig is." Daarmee doelen ze op npm, composer, etc, etc, ook frameworks die wellicht weer overkill zijn. Hoewel frameworks zich net zo hangen aan composer in de meeste gevallen.

Maar zoals je ook al zei, het is bijzar dat er packages dependencies hebben om een een string in lowercase the veranderen. Dat is 1 regel code. Waarom moet je daar van afhankelijk zijn?
Als je dan een 3rd party software gebruikt, is dat met bijv. vue, niet 1 thirdparty maar meteen 100.

Maar zoals je ook al aangaf, dit is natuurlijk ook een ding dat eerst vaker fout moet gaan voor de community die er mee bezig is, beseft dat het niet langer kan zo. Dan pas komt er verandering.

Ik hoop dat het in de nabije toekomst verbeterd, want momenteel maak ik het liever zelf, wanneer het kan, dan weer 100 packages te installeren.

Wat ik wel grappig vind met al die packages, en ironisch ook, is hoeveel devs op het web zeggen "don't copy but understand.", of iets van gelijke aard.
Maar wanneer we een project moeten maken met vue, react of what else, "download deze packages allemaal. maakt niet uit dat je niet wat wat er in zit" XD

[Boost9898]

Dit is zo'n non-argument, je kan nooit (als zelfstandige dev/klein team) zonder node packages werken aan grotere projecten.

[controvi]

Is het feit dat je dat moet zeggen niet al een soort red flag?
Wat installeer je allemaal? 90% van de devs zullen nooit de dependencie tree langs lopen en kijken of alle code wel klopt.

Het feit dat er een wildgroei is aan packages die basically direct in een vuilnisbak gegooid moeten worden, en die dan ook nog in grote packages worden include... dat is mij echt een raadsel hoe dat tot op de dag van vandaag nog steeds geaccepteerd wordt.

Waar zijn al die flippo's die andere devs op stackoverflow zaten uit te schelden als ze rare code scheven maar vervolgens aanraden om package X te instaleren omdat het veel beter is. Niet vertellede dat je dan code hebt waar je niets van weet PLUS met een beetje pech nog 100 packages extra die als dependencie erbij moeten.

[wimdebok]

Wat is het alternatief voor npm?

Nooit zo goed gerealiseerd maar dit incident zet aan het denken. Ben geen javascipt kenner maar vind het het leuk om wat te doen met svelte/node. Je krijgt een inderdaad een enorme mep aan packages mee.

Het is wat gek node npm en wat er aan hangt is het enige ik niet installeer via de normale os packages, Debian/apt. Vraag me nu af wie is de baas en verzorgt de integriteit en de betrouwbaarheid?

Hopelijk een niet al te donme vraag.

Edit: komt nu safe npm tegen, lees dat er bedrijven die eigen repos er op na houden die ze zelf. Vind het bar is niet een groep of iemand die hier verantwoordelijk voor is?

[Reactie gewijzigd door wimdebok op 9 september 2025 08:31]

[henkbiertank]

Voor Composer zou je `roave/security-advisories` kunnen installeren. Dit is een package die vrij snel wordt bijgewerkt als er versies van andere packages zijn die om wat voor (security) reden dan ook niet geïnstalleerd moeten worden. Daar wordt mooi gebruik gemaakt van de `conflicts` configuratie van Composer zelf. Voor NPM bestaat zo'n package helaas niet.

[Nedje]

Er zit een stevige dosis waarheid in je verhaal, maar je weet het wel met een mooie hoeveelheid drama te brengen. Je doet nu net alsof een npm install in het overgrote merendeel van de gevallen een enorm groot probleem is. Je hebt volkomen gelijk dat het een probleem kan zijn. Je bent bijvoorbeeld afhankelijk van het feit dat je dependency fatsoenlijk versioneert en geen breaking changes in patch versions doet (ik kijk naar jullie, keycloak...)

Specifiek voor deze situatie kun je iets als Safe Chain gebruiken (zie hier), je wordt dan geinformeerd wanneer een package bijvoorbeeld obfuscated code gebruikt. Ook dat is niet waterdicht maar je kunt helaas niet veel anders. Alles zelf bouwen is simpelweg niet te doen en te onderhouden.

[controvi]

Tuurlijk kun je stellen dat het probleem niet ZO groot is. En aan de oppervlakte is dat ook wel zo.
Maar als jij te horen krijgt dat je airbag mogelijk niet werkt, kun je ook nog steeds doorrijden.

Mijn punt is vooral dat je op dit moment geen idee hebt wanneer je een uitrol doet van updates, en plots je hele user database op straat zou kunnen liggen. Of keyloggers ergens diep in de dependencies, de logins van je users naar een database stuurt in verwegiestan.

Dit is natuurlijk geen lekker idee als ziet hoeveel gegevens van mensen op straat komen te liggen de laatste jaren.

Online was het sentiment altijd , tenminste toen stackoverflow not goed was, dat je de code moest begrijpen die je gebruikt. Je moet niet lukraak copy & pasten. Maar met de wildgroei aan NPM packages, die je bijna niet anders meer. Je begrijpt alleen nog door de docs hoe je de code aanspreekt, maar wat doet het precies? Hoe werkt het? Geen idee.

Uit eindelijk zal het vast beter worden, maar op het moment is het meer irritant hoe alles een beejte aan elkaar vast hangt met te weinig ductape. Dingen kunnen makkelijk breken als je even niet oppast, of iemand anders doet het voor je in het ergste geval.

Het is nu een soort, "het werkt, niet meer aanraken" idee voor mij

[Nedje]

Je hebt natuurlijk gelijk en het is absoluut een probleem. Ik herken het duct tape gevoel wat je omschrijft, toch zit ik zelf wel in het kamp van: met regelmaat je versies bij werken. Nu al een paar projecten gedaan waar dit niet zo was en er een CVE werd gevonden waardoor we ineens meerdere major versies omhoog moesten (met alle gevolgen van dien).


Kortom: We denken hetzelfde, ik ging enkel aan op de ietwat sensationele beschrijving :-).

[TheDutchSmoke]

Voor de geïnteresseerden tussen ons, hij lijkt updates te plaatsen op zijn Bluesky: https://bsky.app/profile/bad-at-computer.bsky.social

En voor de techneuten zijn Github issue:
https://github.com/debug-js/debug/issues/1005#issuecomment-3266868187

[WargamingPlayer]

41 minuten geleden een melding dat er meerdere ontwikkelaars geraakt zijn. Het is dus inderdaad groter.

[Nattekat]

Wauw, dat verhaal van hoe het ontdekt is is ook wel echt eentje van extreem geluk. Niet alleen hadden ze toevallig een environment die oud genoeg was om erop kapot te gaan, maar ook hadden ze een pipeline die bijna direct na het uitbrengen van de nieuwe versie gerund werd.

[OverSoft]

Deze packages worden onder andere gebruikt in Electron (een extreem veel gebruikt pakket om van een webapplicatie een Windows/Mac/Linux applicatie te maken, onder andere Steam is een Electron applicatie) en React (een veel gebruikte library om GUI's te bouwen in Javascript, onder andere gebruikt door Facebook).

Check dus even of je in de afgelopen dagen je npm packages geupdate hebt als je aan een project werkt wat gebouwd is op een van deze libraries, want ja: er draait echt gigantisch veel op.

[Don Key]

Steam is GEEN electron applicatie!

Het gebruikt CEF (Chromium Embedded Framework), in een in c++ geschreven applicatie.

[bleepie]

Betekent dat ook dat Steam (automatisch?) deze updates in de software heeft zitten en hebben gebruikers daar dan ook last van? Of hoe moet ik dat zien?

[OverSoft]

Steam moet actief een update hebben uitgerold waar een van de “aangetaste” versies in zitten.

Ik vermoed dat er bij Steam een flinke check pipeline in het bouwproces zit, die dit soort dingen opmerken.

Dus nee, het gaat niet automatisch, dit moet door Steam gepushed zijn.

[bleepie]

Laten we zeggen dat ze het wel gedaan hadden, wat zou dan de impact voor de gebruikers zijn?

[OverSoft]

Het is nog een beetje vroeg om te zeggen. Het lijkt er op dat het alleen impact heeft op de pagina’s die geserveerd worden binnen de applicatie. (Dus bijvoorbeeld de winkel binnen Steam) Of webpagina’s die gebouwd zijn met het pakketje.

Het lijkt er op dat de malware crypto adressen aanpast voordat ze naar een wallet gestuurd worden. Voor Steam lijkt dit weinig impact te hebben, maar ik weet niet of het hele plaatje van de malware al duidelijk is.

Het treedt in ieder geval niet buiten de applicatie waar het pakketje in zit.

[Bart321]

Ik ben een 'safe npm' wrapper gaan gebruiken die alle packages voor het installeren analyseert: https://socket.dev/blog/introducing-safe-npm Volgens mij ligt die site aardig plat, info hier: https://docs.socket.dev/docs/safe-npm-faq

Dit gebruikt static analysis, dus niet 100% veilig. Als je echt veilig wilt zijn dan moet je een zelf gehoste npm proxy gebruiken waar alle packages met de hand worden nagekeken. Dit is wat grote bedrijven gebruiken.


Verder als je npm packages publiceert, voeg 2FA toe aan je npm account, het liefste met een Yubikey. En configureer trusted publishing: https://docs.npmjs.com/trusted-publishers

[Reactie gewijzigd door Bart321 op 8 september 2025 22:56]

[Martinspire]

Die trusted publishers heeft toch weinig impact als ze een nieuwe update triggeren vanuit je github account nadat ze files aanpassen met je gespoofde token?

Op zich ziet safe-npm er aardig uit, maar het lijkt mij nog wel een package waar ze snel geld voor vragen. Nu is het vooral als integratie van hun huidige platform, maar hoe lang dat gratis blijft. Wel vind ik dat NPM meer moet doen om malafide packages al tegen te houden voor ze worden toegevoegd, maar een betaalde tool vind ik op zich ook niet zo heel erg, zolang ik het ook zelf kan uitvoeren zonder mijn organisatie en diens code eraan te moeten koppelen.

[Reactie gewijzigd door Martinspire op 9 september 2025 10:08]

[markg85]

@TijsZonderH https://github.com/debug-js/debug/issues/1005#issuecomment-3266868187 "live" updates van Qix

[gitaarwerk]

Dank! fijn te hebben!

[gitaarwerk]

Ik heb morgen een leuke klus te doen, denk ik.. Zou wel mooi zijn om een versie range te weten. Zal wel z.s.m. beschikbaar komen.

[Reactie gewijzigd door gitaarwerk op 8 september 2025 20:25]

[n9iels]

Inmiddels bekend (met dank aan @markg85 die elders in de reacties dit issue plaatste): https://github.com/debug-js/debug/issues/1005#issuecomment-3266868187

[gitaarwerk]

Dank!

[dbs1]

Toch wel bijzonder dat 1 "hack" ervoor zorgt dat dit zo'n wijdverspreid effect heeft. Lijkt me dat dat best een puntje van aandacht mag zijn.

[DdeM]

Dit is een van de redenen waarom, voor simpele dingen, het "not invented here" syndroom best nuttig kan zijn. Zo op basis van de namen staan hier ook packages tussen waarvan het zelf implementeren net zo makkelijk zou zijn, met een stuk minder risico. Nagenoeg niemand zal bij elke package update de gehele source van een package nakijken, maar wel updaten zodra en een update beschikbaar is.

[Blokker_1999]

En dan spendeer je uren aan iets te schrijven, testen, debuggen enzoverder voor iets redelijks eenvoudig dat een ander volledig heeft uitgewerkt voor je. Vergis je niet hoeveel tijd er kan gaan zitten in het schrijven van wat vaak als basisfuncties wordt voorgesteld.

[nzall]

Ik denk dat ook een groot deel van het probleem met "NIH" en "don't reinvent the wheel" is dat in het moderne auteursrechtensysteem software code OOK auteursrechten heeft en niet zomaar mag worden overgenomen uit andere bronnen. Veel van deze code bestaat al in "afgewerkte" vormen die gewoon feature complete zijn. Om maar een voorbeeld te geven: left-pad is letterlijk 11 regels code en valt eigenlijk niet echt veel aan te verbeteren. Als je die gewoon in je code zou mogen mieteren zonder dat er daar een extra dependency bij aan te pas komt zou heel dit probleem niet voorkomen.

[DdeM]

Gezien het mijn dagelijkse bezigheid is zal ik me er zeker niet in vergissen, maar na weet ik het hoe vaak toch tegen issues aan lopen met packages van andere, en dan heb ik het nog niet eens over dit soort malware injecties, ben ik een heel stuk kieskeuriger geworden in welke 3rd party dependencies ik aan ga.

[Quacko]

Ik kom toch van een stal waar versieupdates niet zomaar werden gedaan. Er werd eerst gekeken of er known bugs of andere zaken in zaten en dus ook niet meteen snel verhogen eens het uit is.

Als er zoiets pas vele maanden later boven komt zal het ook niet gevat zijn op deze manier, maar de problemen die boven komen in de eerste maanden wel. Meermaals gehad dat er niet verhoogd mocht worden wegens een probleem met volgende versie.

[SiErRa]

Die werkwijze wordt juist door gevonden vulnerabilities steeds laster te hanteren. Fixes voor vulnerabilties worden niet altijd gebackport naar oudere versies. En een beetje afhankelijk van je applicatie / package management systeem, zal je toch vrij regelmatig je dependencies moeten updaten om niet vulnerable te worden.

[Guru Evi]

Het is 1 user die een redelijk aantal pakketjes onderhoudt. De vraag is eigenlijk waarom JS devs zoveel vertrouwen stellen in de code van 1 user.

Zelfs als die heer het opzettelijk had gedaan, of gewoon gezegd dat iedereen morgen moet betalen voor zijn werk, of als hij het beu is, dat is evengoed mogelijk geweest en vroeger al gebeurd.

Een degelijke build proces echter zou die dingen moeten inspecteren en dan kun je labels zetten en enkel gebruiken met 'vertrouwen' als een derde partij of meerdere partijen een build geinspecteerd hebben.

Sommige van die libraries (zoals color-convert) heb je eigenlijk maar 1x in je leven nodig (en een paar upgrades) maar anders is het gewoon statische code, waarom moet bij elke build die JS opnieuw gedownload worden? Dat hoeft echt niet in een externe library te zitten die van een (letterlijk) "random" URL gedownload wordt. Identiek voor de ANSI libraries, de ANSI standaarden zijn heus niet veranderd in de laatste 50+ jaar, zolang het werkt...

[wiseger]

Open source. Een enkele ontwikkelaar beheert veel gebruikte standaard libraries. Zijn approval is genoeg om commits door te voeren in de libraries. 4-ogen checks zijn niet nodig.

Eén enkele phishing email naar die ontwikkelaar is dan genoeg om al die libraries te infecteren en de verspreiding van die malware gaat vervolgens vanzelf.

[n9iels]

Ik weet niet precies of/wat je hiermee wilt zeggen, maar bij het alternatief (closed source) was dit wellicht veel later ontdekt. En dan is het maar de vraag of de ontwikkelaar ook door het stof gaat om het bekend te maken t.o.v. in stilte fixen en zwijgen.

Het probleem bij veel projecten is dat er vaak überhaupt maar 1 dev is die zo gek is om zijn vrije tijd op te offeren. Deze packages hebben gecombineerd 2 miljard downloads, ik ben verbaasd als de ontwikkelaar genoeg binnen krijgt aan donaties om er ook maar een halve dag betaald aan te kunnen werken.

[Reactie gewijzigd door n9iels op 8 september 2025 20:38]

[hcQd]

Obligate xkcd-link: https://xkcd.com/2347/

[NIMIC]

Ik ben er blijkbaar al even uit, want ik wist niet wat een npm package was.

Maar blijkbaar is Npm de standaard pakketbeheerder voor de JavaScript-runtime-omgeving Node.js

En dus zijn dit pakketjes om te gebruiken in je javascript code.

Wikipedia: npm (software)

[Ed Vertijsment]

En ook gewoon voor websites en webapplicaties

[rob12424]

Thanks als niet programmeur had ik geen idee wat het betekende! Ik zat echt: npm welke Linux distro gebruikt npm?

Zuur dat dit gebeurt is.

[CH4OS]

NPM staat voor Node Package Manager, wordt gebruikt om JavaScript libraries / dependencies te beheren in Node (web) applicaties.

[WargamingPlayer]

Ik heb een vermoeden dat dit erger is dan iedereen denkt. Iedereen welke code gebruikt met deze packages is het bokkie. Dus heeft iemand deze packages gebruikt in een interne bedrijfs applicatie, dan kan je gewoon stellen dat iedere user welke deze applicatie gebruikt heeft het bokkie is.

[J_van_Ekris]

Ik heb een vermoeden dat dit erger is dan iedereen denkt. Iedereen welke code gebruikt met deze packages is het bokkie. Dus heeft iemand deze packages gebruikt in een interne bedrijfs applicatie, dan kan je gewoon stellen dat iedere user welke deze applicatie gebruikt heeft het bokkie is.

Het probleem met NPM packages is dat het vaak een hele cascade van packages is, en je niet eens bewust bent van issues omdat een toplevel package weer een npm package nodig heeft etc.. Als package maintainer include je iets als een webserver of een bluetooth manager, maar uitzoeken wat je daarbij meeneemt is echt een ding.

Ben zelf package maintainer van een Javascript app, en we leunen behoorlijk op bepaalde packages en het is best wel een klus om alle onderliggende NPM packages bij te houden. GitHub waarschuwt wel als je package-lock.json security issues heeft (kun je aanzetten, wel erg handig), maar het oplossen daarvan is wel een klus. Als er halverwege die supply-chain iemand zit te slapen (of het repo gewoon abandoned heeft, wat ons onlangs overkomen is), dan heb je een hele slechte week.

[CH4OS]

Dan is het in potentie toch ook groter dan dat je met jouw eerste zin het doet lijken? Je haalt in elk geval met jouw tweede zin, de eerste flink onderuit.

[WargamingPlayer]

Ik snap jouw opmerking niet. Ik haal toch niks onderuit? Ik zeg gewoon dat het veel erger is dan dat het nu lijkt. Gevolgd door een voorbeeld.

[CH4OS]

Ah, ik las jouw reactie verkeerd en ik zie nu mijn fout, hahaha! Ik dacht dus dat er ergens niet in de eerste zin stond, sorry!

[mocean]

Enkel als je ze hebt binnengehaald in de compromised periode.

[WargamingPlayer]

Gezien het aantal downloads....