Selvspredende orm i npm kompromitterte Keyv og andre mye brukte pakker

Et omfattende angrep mot forsyningskjeden i npm ble beskrevet 4. august 2026 av Aikido og av Microsoft. Angrepet spores som ChainDrop og knyttes til en variant av Mini Shai-Hulud. Det kompromitterte Keyv og andre mye brukte pakker med skadevare som kjørte under installasjonen, stjal legitimasjon fra utviklere, byggekjeder, GitHub, npm og skytjenester, og brukte den tilgangen til automatisk å publisere nye infiserte utgaver. Hendelsen viser hvordan én kompromittert vedlikeholder eller byggeidentitet kan spre skadevare raskt gjennom åpen kildekode som mange stoler på.

Hva som skjer teknisk

En pakke i npm kan kjøre kode som del av installasjonen, gjennom et skript som kalles automatisk når pakken hentes inn. Det er en praktisk mekanisme, og den er samtidig den korteste veien fra en pakke til en maskin. Både utviklerens egen maskin og byggetjeneren i byggekjeden kjører denne koden uten at noen leser den først.

Ormeegenskapen er det som gjør ChainDrop alvorlig. Ifølge beskrivelsene stjal skadevaren legitimasjon fra utviklere, byggekjeder, GitHub, npm og skytjenester, og brukte deretter npm-legitimasjonen til å publisere nye infiserte utgaver av andre pakker automatisk. Da er spredningen selvgående, fordi hver kompromittert vedlikeholder blir utgangspunkt for neste runde. Byggeidentiteter er særlig verdifulle her, siden de ofte har rett til å publisere uten at et menneske godkjenner, og siden de er laget for å kjøre uten tilsyn. Hemmeligheter som ligger som miljøvariabler i en byggejobb, er derfor ikke bare et lokalt problem.

Infisert pakkehentes inn i prosjektetInstallasjonsskriptkjøres automatiskLegitimasjon stjelesnpm, GitHub og skyNye infiserte utgaverpubliseres automatisk
Figur: Sløyfen er poenget. Legitimasjonen som stjeles i ett prosjekt, brukes til å publisere neste infiserte utgave, og runden begynner på nytt.

Hva det betyr for virksomheten

Dette rammer flere enn dem som utvikler programvare selv. Nesten enhver moderne nettløsning trekker inn hundrevis av pakker indirekte, og en virksomhet som har fått laget en portal av et byrå, har den samme eksponeringen uten å ha skrevet en linje kode. Spørsmålet om dere bruker Keyv, er derfor sjelden noe virksomheten kan svare på uten å spørre leverandøren.

Det som skiller de som håndterer dette godt fra resten, er om de har en liste over hva som faktisk inngår i egne løsninger. Med en programvarestykkliste tar oppslaget minutter. Uten den blir det en telefonrunde over flere dager, mens legitimasjon som allerede kan være stjålet, fortsatt virker. Nøkkelbyttet er den delen som oftest glemmes, for en oppdatert pakke fjerner ikke en polett angriperen allerede har hentet. For virksomheter under NIS2 er dette leverandørkjeden i artikkel 21, og i norske virksomheter er det ofte den delen av artikkelen som er dårligst dekket i praksis.

Berigo anbefaler

  • Be leverandøren om en oversikt over pakkene som inngår i løsningene deres, og få den oppdatert ved hver leveranse.
  • Slå av automatisk kjøring av installasjonsskript i byggekjeden der det lar seg gjøre, og lås pakkeversjonene.
  • Bytt legitimasjon for npm, GitHub, byggekjeder og skytjenester dersom noe tyder på berøring, uten å vente på endelig bekreftelse.
  • Krev at publisering til pakkeregistre går gjennom et menneske og et sterkt påloggingsmiddel.
  • Gå gjennom loggene for hva byggeidentitetene deres har gjort den siste tiden.

Sikkerhet som forstås, styres og virker.

La oss hjelpe dere å gjøre sikkerhet til et fortrinn, ikke en kostnad. Ta kontakt for en uforpliktende samtale om hvor virksomheten står, og hva som bør prioriteres først.

Ta kontakt