I september 2025 inträffade något som säkerhetsexperter har varnat för i åratal: Attackerare lyckades kompromettera de mest fundamentala byggblocken i modern mjukvaruutveckling. På sex veckar drabbades världens största kodbibliotek npm och GitHub av tre massiva attacker. Värst av alla var Shai-Hulud – den första självreplikerande masken som någonsin spridit sig genom mjukvarukedjan.

Omfattningen är svindlande

När Daniel dos Santos Pereira, senior backend-utvecklare, den 15 september varnade sina kolleger på LinkedIn om att ”skadlig kod sprids live på npm just nu”, visste få hur rätt han hade. Inom loppet av bara sex veckor hade över 520 npm-paket komprometterats. De 18 mest populära paketen från Chalk/Debug-attacken hade ensamma 2,6 miljarder nedladdningar per vecka.

För att sätta det i perspektiv: Det är fler nedladdningar per vecka än det finns människor på jorden. Varje installation kunde potentiellt sprida skadlig kod vidare.

Men siffrorna berättar bara halva historien. Cirka 700 privata GitHub-repositories gjordes publika av masken, vilket exponerade företagshemligheter, API-nycklar och känslig kod för hela världen. Tusentals AWS-, Azure- och Google Cloud-credentials stals. Attackerna fick säkerhetsansvariga på Netflix, NASA, PayPal och otaliga banker att jobba natten över.

Vad är npm och varför driver det internet?

Här kommer förklaringen som många behöver men få får: npm (Node Package Manager) är världens största programvarubibliotek. Tänk på det som ett IKEA-lager för kod – istället för att bygga varje skruv och bräda själv, kan utvecklare hämta färdiga komponenter som andra redan byggt och testat.

Registret innehåller över 2 miljoner kodpaket som används av 17 miljoner utvecklare världen över. När du besöker Netflix, scrollar på LinkedIn, betalar via PayPal eller till och med kollar NASA:s webbplats, så bygger deras system på npm-paket djupt ned i koden.

GitHub, som köpte npm 2020, är där dessa paket skapas och underhålls. Tillsammans utgör de två plattformarna hjärtat i modern mjukvaruutveckling. När de attackeras, attackeras internet självt.

AI-kodning gör oss alla sårbara

Här blir det riktigt intressant – och skrämmande. Du behöver inte längre vara professionell utvecklare för att använda npm. Tack vare AI-assistenter som Claude, ChatGPT, Lovable och GitHub Copilot kan vem som helst ”vibe-koda” fram en webbplats eller app.

När du ber AI:n ”skapa en webbsida för min verksamhet”, genererar den kod som automatiskt kör kommandot npm install. Plötsligt har du laddat ner hundratals kodpaket från internet – utan att ha den blekaste aning om vad de innehåller. Om bara ett av dessa paket är komprometterat, är hela ditt projekt infekterat.

Sex veckor av kaos

Slutet av augusti – Nx-attacken Det började med Nx, ett populärt byggverktyg med 6 miljoner nedladdningar per vecka. Attackerna, troligen från gruppen ”s1ngularity”, stal autentiseringsuppgifter och satte tonen för vad som komma skulle.

8 september – Den massiva Chalk/Debug-attacken Detta var den stora. Josh Junon, maintainer för några av JavaScript-världens mest fundamentala paket, fick ett mail som såg ut att komma från npm-support. Domänen var npmjs.help istället för npmjs.com. Han klickade, matade in sina uppgifter inklusive 2FA-koden – och på två timmar publicerades skadlig kod i 18 paket med sammanlagt 2,6 miljarder nedladdningar per vecka.

Paketen som chalk, debug och strip-ansi är så grundläggande att de sitter djupt ned i beroendeträdet hos tusentals andra projekt. Ett enda npm install kunde dra med sig den skadliga koden utan att någon märkte det. Koden var riktad mot kryptoplånböcker och lyckades stjäla cirka 600 dollar innan den upptäcktes – inte mycket, men beviset på att attacken fungerade.

15 september – Shai-Hulud: Den självreplikerande masken En vecka senare upptäcktes något som aldrig tidigare skådats i npm-ekosystemet: en mask som kunde replikera sig själv.

Shai-Hulud: Masken från Dune

Namnet kommer från Frank Herberts science fiction-klassiker Dune, där ”Shai-Hulud” är de gigantiska sandmaskarna som härjar under ökensanden och kontrollerar universums mest värdefulla resurs. På arabiska betyder det ”evighetens varelse”.

Attackarna valde namnet medvetet – de skapade publika GitHub-repositories med namnet ”Shai-Hulud” där de lagrade all stulen data. Det var både deras signatyr och ett sätt att håna offren.

Så här fungerar masken

När en utvecklare installerar ett infekterat paket körs automatiskt ett skript som startar bundle.js – en över 3 MB stor fil packad med skadlig funktionalitet.



Masken jobbar metodiskt:

Den börjar med att kartlägga offrets system. Vilken plattform? Vilka miljövariabler finns? Sedan laddar den ner TruffleHog, ett legitimt verktyg för att hitta hemliga nycklar i kod, och använder det för att skanna hela systemet efter autentiseringsuppgifter.

Masken är kräsen. Den validerar varje stulen nyckel innan den skickas vidare. npm-tokens testas mot npm:s whoami-endpoint. GitHub-tokens testas mot GitHubs API. Bara fungerande credentials skickas vidare.

Nu kommer det riktigt listiga: Masken skapar en ny publik GitHub-repository under offrets konto, döper den till ”Shai-Hulud”, och laddar upp alla stulna credentials dit. Data kodas tre gånger med base64 för att se oskadlig ut vid första anblicken.

Men det slutar inte där. Med den stulna npm-token autentiserar sig masken som offret, letar upp andra paket som personen underhåller, laddar ner dem, injicerar sin egen kod, och publicerar nya komprometterade versioner. Processen upprepas exponentiellt varje gång någon ny installerar ett infekterat paket.

På GitHub-sidan injicerar masken en skadlig GitHub Actions-workflow i offrens repositories. Varje gång någon pushar kod stjäl workflow-filen nya secrets från CI/CD-pipelinen. Masken går även igenom och gör privata repositories publika, vilket exponerar företagshemligheter för hela världen.

Därför är detta historiskt

Tidigare supply chain-attacker krävde att attackerarna manuellt komprometterade varje paket. Shai-Hulud automatiserade hela processen. En komprometterad utvecklare blir automatiskt till fem komprometterade paket. Dessa installeras av tio nya utvecklare. Nu har vi 50 komprometterade paket. De installeras av 100 utvecklare. Plötsligt har vi 500 komprometterade paket.

Nicholas Weaver vid International Computer Science Institute kallade det ”en supply chain-attack som genomför en supply chain-attack”. ReversingLabs bekräftade att det är första gången en självreplikerande mask opererat inom open source-leveranskedjan i sådan skala.

GitHub är både offer och förövare samtidigt

Det bisarra med Shai-Hulud är hur den använde GitHub mot sig själv. npm ägs av GitHub sedan 2020, vilket skapade en perfekt storm.

Masken kunde:

Stjäla npm-tokens och publicera skadliga paket. Använda dessa för att komma åt GitHub-konton. Stjäla GitHub-tokens och skapa ”Shai-Hulud”-repositories. Injicera GitHub Actions-workflows för att stjäla ännu fler credentials. Göra privata repositories publika. Använda GitHub Secrets från CI/CD-pipelines för att sprida sig vidare.

OX Security hittade 34 komprometterade GitHub-konton, vart och ett med en publik ”Shai-Hulud”-repository fylld med stulen data. Cirka 700 privata repositories hade gjorts publika. Säkerhetsforskare kunde bokstavligen googla ”Shai-Hulud GitHub” och hitta offrens credentials upplagda öppet.

Video från Defcon video som visar hur journalister hackade Trump administrationen på 20 minuter genom att kolla koden på Github

I det här finns det heapdump som var publika och journalisten beskrev hur han hackade deras kommunikation genom att hämta hem programvaran på Github och upptäcka sårbarheterna i deras kommunikation.
https://micahflee.com

Vad drabbade företag måste göra nu

Om ditt företag installerade något av de komprometterade paketen finns det ingen lätt utväg. All access måste antas vara stulen. Det betyder:

Rotera omedelbart alla GitHub Personal Access Tokens. Rotera alla npm-tokens. Rotera alla AWS-, GCP- och Azure-credentials som fanns på drabbade maskiner. Kolla efter publika ”Shai-Hulud”-repositories under företagets GitHub-konton. Leta efter oväntade GitHub Actions-workflows. Kontrollera om några privata repositories plötsligt blivit publika. Granska alla package-lock.json och yarn.lock-filer för komprometterade versioner.

TruffleHog stödjer över 700 olika typer av credentials. Om masken körde på en utvecklares maskin, anta att allt TruffleHog kan hitta också attackarna har.

Samhällets respons: Snabbt men inte tillräckligt

Trots det kaotiska läget reagerade open source-communityn imponerande snabbt. Bara 15 minuter efter att de skadliga Chalk/Debug-paketen publicerats diskuterades de på GitHub. Efter en timme hade vissa maintainers tagit ner sina egna komprometterade paket. Efter två timmar hade npm börjat ta ner resten.

För Shai-Hulud tog det längre tid eftersom masken spred sig snabbare än folk hann reagera. Men efter cirka tre dagar hade spridningen i stort sett stoppats genom att npm och GitHub låste komprometterade konton och tog ner skadliga paket.

Melissa Bischoping, senior director of security på Tanium, påpekade efteråt: ”Om du får panik över npm-incidenten, snälla gör det inte. Det finns en nästan noll chans att du påverkats.” Det ledde till debatt om huruvida detta var ”största supply chain-attacken i historien” eller bara ett bevis på att systemet faktiskt fungerar.

Men det missar poängen. Att attacken stoppades snabbt är bra. Att den kunde hända överhuvudtaget är katastrofalt.

Vilka står bakom attackerna?

Trots omfattande efterforskningar är attackarna fortfarande anonyma. Men säkerhetsforskare har identifierat tydliga kopplingar mellan alla tre attackerna.

S1ngularity-gruppen: Ett mönster av sofistikerade attacker

Wiz och andra säkerhetsföretag bedömer att Shai-Hulud-attacken är ”direkt nedströms” från Nx/s1ngularity-attacken i augusti. Aikido Security konstaterade att ”attackerna använder samma playbook i stora delar som den ursprungliga attacken, men har uppgraderat sitt spel.”

Mönstret är slående. Alla tre attackerna:

  • Använder samma teknik för att stjäla credentials
  • Kodificerar stulen data med dubbel base64-encoding
  • Skapar publika GitHub-repositories för att lagra stulna secrets
  • Riktar sig mot både GitHub- och npm-tokens samtidigt
  • Har särskild fokus på AI-utvecklingsverktyg (Claude, Gemini, Q)

Från Nx-attacken har forskare spårat attackarnas digitala fotspår: De använde TOR-nätverket för att dölja sin identitet och ett single-threaded Python-script för att publicera repositories. Den sårbara GitHub Actions-workflow som utnyttjades i Nx-fallet lades till den 21 augusti, utnyttjades för att stjäla token den 24 augusti, och skadliga paket publicerades den 26 augusti. Det hela gick blixtsnabbt.

Krypto-kopplingen: Distraktionsmanöver eller sekundärt mål?

Chalk/Debug-attacken riktades specifikt mot kryptovalutaplånböcker med kod designad att omdirigera transaktioner till attackerare-kontrollerade adresser. Men det finansiella resultatet var förvånansvärt litet.

Socket och Sonatype rapporterade att attackarna bara lyckades stjäla cirka 600 dollar totalt – 429 dollar på Ethereum, 46,63 dollar på Solana, och resten i BTC, TRON, BCH och LTC. Med tanke på att paketen kollektivt hade 2,6 miljarder nedladdningar per vecka är detta nästan ingenting.

Wiz Security konstaterar att ”den effektiva påverkan av denna attack mätt i framgångsrik cryptocurrency-stöld har varit minimal, särskilt med tanke på den höga förekomsten av komprometterade paket.”

Så vad var det verkliga målet?

Säkerhetsforskare tror att krypto-stölden var antingen:

  1. En distraktionsmanöver för att dölja den riktiga missionen: att stjäla företagscredentials
  2. Ett sekundärt mål medan huvudfokus låg på AWS-, Azure-, GCP-nycklar och GitHub-tokens

Värdet av stulna molnplatform-credentials och GitHub-tokens överstiger vida 600 dollar i krypto. En enda komprometterad AWS-nyckel kan ge tillgång till hela företagsinfrastrukturer värda miljoner. GitGuardian hittade att hälften av de 2,349 stulna secrets från Nx-attacken fortfarande var giltiga när de analyserades – vilket betyder att attackarna fortfarande kan använda dem för framtida intrång.

AI-aspekten: Första gången AI vapeniserades

Nx/s1ngularity-attacken var historisk av en annan anledning: Det var första gången en supply chain-attack aktivt sökte efter och missbrukade AI-utvecklingsverktyg.

Malwaren kollade specifikt om Claude Code CLI, Gemini CLI eller Amazon Q var installerade på offrets maskin. Om den hittade dem, körde den kommandon med farliga flaggor som --yolo och --trust-all-tools som förbikopplar säkerhetsbegränsningar. Orca Security kallade det ”den första kända supply chain-attacken som aktivt söker efter installerade LLM-verktyg på utvecklarmaskiner för att extrahera fler secrets från offret.”

Detta visar hur attackerna utvecklas. När utvecklare allt mer förlitar sig på AI-assistenter, blir dessa verktyg själva en attackvektor.

Hur många drabbades egentligen?

Det är svårt att ge ett exakt antal, men vi kan göra uppskattningar baserat på tillgänglig data.

Nx/s1ngularity-attacken

  • Phase 1: Över 1,700 användare fick sina credentials läckta till publika GitHub-repositories
  • Phase 2: Minst 480 komprometterade konton (två tredjedelar var organisationer) hade över 6,700 privata repositories gjorda publika
  • Phase 3: Ett enskilt företag fick över 500 repositories exponerade
  • Totalt: GitGuardian identifierade 1,346 repositories med namnet ”s1ngularity-repository”, med 2,349 distinkta secrets läckta

Chalk/Debug-attacken

  • De skadliga versionerna var live i bara 2 timmar
  • Vercel identifierade 70 teams med builds som innehöll komprometterade paketversioner över 76 unika projekt
  • Med 2,6 miljarder nedladdningar per vecka betyder det cirka 10 miljoner nedladdningar per timme
  • Under 2-timmarsfönstret: potentiellt 20 miljoner nedladdningar

Men som Melissa Bischoping från Tanium påpekade: ”Chansen att de laddades ner OCH skeppades in i din mjukvara under det tidsfönstret är väldigt, väldigt liten – nästan noll.” De flesta installationer cachas, och många projekt kör inte nya builds på måndagsmorgnar amerikansk tid.

Shai-Hulud-attacken

  • 500+ paket komprometterade
  • 278 secrets identifierade i läckta GitHub-data
  • ~700 repositories gjorda publika
  • Trend Micro rapporterar att organisationer i Nordamerika och Europa var mest drabbade

Den verkliga siffran

Wiz Security estimerar att ”tusentals företagssecrets” läcktes totalt över alla tre attackerna. Men många organisationer vet fortfarande inte om de påverkades, eftersom:

  • Många installationer sker via cachade versioner
  • CI/CD-pipelines kanske inte kördes under kritiska tidsfönster
  • Företag kanske inte övervakar sina dependencies tillräckligt noga
  • Många mindre organisationer saknar resurser för grundlig forensisk analys

Det som är säkert: Varje organisation som använder npm är potentiellt sårbar. Med över 17 miljoner utvecklare som använder npm globalt, och med paket som chalk och debug djupt inbäddade i tusentals projekt, är attackytan enorm.

Hur företag kan skydda sig

Efter dessa attacker måste företag fundamentalt ompröva sin approach till supply chain-säkerhet. Här är konkreta åtgärder baserade på vad säkerhetsexperter rekommenderar.

1. Kontrollera och lås dina bibliotek

Software Bill of Materials (SBOM): Varje organisation måste veta exakt vilka dependencies de använder. Skapa och underhåll en SBOM som listar:

  • Alla direkta dependencies
  • Alla transitiva dependencies (beroenden av beroenden)
  • Exakta versionsnummer
  • Källan för varje paket

Verktyg som Wiz, OX Security, Cortex Cloud och JFrog Curation kan automatiskt generera och övervaka SBOMs.

Pinning och låsning:

json

// Dålig praxis - accepterar alla uppdateringar
"dependencies": {
  "chalk": "^5.0.0"  // ^ betyder "5.x.x"
}

// Bra praxis - låser exakt version
"dependencies": {
  "chalk": "5.0.1"  // Exakt version
}

Använd package-lock.json eller yarn.lock och commita dem till version control. I CI/CD, kör alltid npm ci (som respekterar lockfiles) istället för npm install (som kan uppdatera paket).

2. Bygg i isolerade miljöer

Separation av concerns:

  • Utvecklingsmiljö: Lokala maskiner med begränsad åtkomst till produktionssecrets
  • Staging-miljö: Testar med anonymiserad data
  • Produktionsmiljö: Strikt kontrollerad med minimala dependencies

Använd olika credentials för varje miljö:

  • Utvecklare ska ALDRIG ha produktions-AWS-nycklar på sina laptops
  • Använd kortlivade credentials i CI/CD (max 1 timme livslängd)
  • Implementera OIDC/Trusted Publishing för npm istället för long-lived tokens

3. Implementera försvarsmekanismer

Före installation:

  • Paket-vetting: Använd tjänster som Socket SafeChain eller Aikido SafeChain som skannar paket för malware INNAN de installeras
  • Cooldown-perioder: Vänta 24-48 timmar efter att ny version publicerats innan automatisk uppdatering (ger tid för communityn att upptäcka problem)
  • Provenance-krav: Kräv att paket är signerade med npm provenance (visar att de kom från legitim CI/CD)

Under byggtid:

  • Postinstall-skript blockering: Verktyg som pnpm kan förhindra att postinstall-skripts körs automatiskt
  • Network-isolation: Bygg i miljöer utan internet-åtkomst (airgapped) när möjligt
  • Scan för secrets: Kör TruffleHog eller liknande på byggmiljön för att säkerställa inga secrets läcker

Efter deployment:

  • Runtime-monitoring: Detektera suspekt beteende (oväntade nätverksanslutningar, fil-modifikationer)
  • Behavioral threat protection: Verktyg som Wiz Defend kan identifiera maskliknande beteenden
  • SRI (Subresource Integrity): För web assets, använd checksums för att säkerställa integritet

4. Härda GitHub och npm-konton

För npm:

  • Obligatorisk 2FA: TOTP-baserad (Google Authenticator, Authy) – INTE SMS
  • Trusted Publishing: Använd OIDC istället för long-lived tokens
  • Granulära tokens: Skapa separata tokens för varje paket med minsta möjliga behörigheter
  • Regelbunden rotation: Rotera tokens var 90:e dag (npm kommer kräva detta från november 2025)

För GitHub:

  • Branch protection: Kräv pull request reviews även för maintainers
  • Workflow-begränsningar: Var extremt försiktig med pull_request_target som gav Nx sin sårbarhet
  • Secrets management: Använd GitHub Secrets, men anta att de kan komprometteras – implementera ytterligare lager av kryptering
  • Audit logs: Övervaka regelbundet för events som:
    • repo.create med suspekta namn (”s1ngularity”, ”Shai-Hulud”)
    • Oväntat publika repositories (tidigare privata)
    • org_credential_authorization.deauthorize (GitHub staff-revokation)

5. Utbilda utvecklare

Phishing fungerade i alla tre attackerna. Utvecklare måste tränas att:

  • Verifiera avsändare: Gå alltid direkt till npmjs.com eller github.com, klicka ALDRIG på länkar i email
  • Ifrågasätt brådska: ”Du måste uppdatera din 2FA inom 48 timmar” är klassiskt phishing
  • Kolla domäner noga: npmjs.help vs npmjs.com – en bokstav kan avgöra allt
  • Rapportera suspekta mail: Skapa en kultur där det är OK att rapportera tveksamma meddelanden

6. Incident Response-plan

Varje organisation behöver en plan för när (inte om) de upptäcker komprometterade dependencies:

  1. Detektering: Hur upptäcker vi att vi använder skadliga paket?
  2. Karantän: Hur stoppar vi snabbt spridning internt?
  3. Forensik: Vilka system påverkades? Vilka credentials exponerades?
  4. Sanering: Rotera alla potentiellt exponerade credentials
  5. Recovery: Bygg om från kända säkra sources
  6. Lärdomar: Dokumentera vad som hände och uppdatera processer

Vad är säkrast och smartast?

Det finns ingen silverkula, men baserat på expertråd från Palo Alto Networks, Wiz, Socket och andra, är detta den smartaste kombinationen:

Guld-standard för stora företag:

  1. Privat npm-register (som Artifactory eller Verdaccio) som mirror
  2. Alla paket skannas för malware innan de tillåts in i registret
  3. SBOM-generering och continuous monitoring
  4. Zero Trust-arkitektur för utvecklarmiljöer
  5. Runtime threat detection i produktion

Praktisk minimumlösning för mindre företag:

  1. Använd package-lock.json och npm ci konsekvent
  2. Implementera Socket SafeChain eller Aikido SafeChain (open source)
  3. Obligatorisk 2FA för alla GitHub och npm-konton
  4. Rotera credentials var 90:e dag
  5. Ha en incident response-plan skriven och testad

Nicholas Weaver sammanfattar det bäst: ”NPM och alla liknande paketregister måste omedelbart kräva explicit mänsklig godkännande för varje publikation med en phishing-säker 2FA-metod. Allt mindre betyder att attacker som denna kommer fortsätta och bli mycket vanligare.”

Framtiden: Vad måste förändras

Nicholas Weaver var glasklar i sin bedömning: npm och alla liknande paketregister måste omedelbart kräva explicit mänsklig godkännande för varje publikation, med phishing-säker 2FA. ”Att tillåta rent automatiserade processer att uppdatera publicerade paket är nu ett bevisat recept för katastrof.”

Men det räcker inte. Sonatype rapporterar att över 845 000 instanser av open source-malware har katalogiserats, med en tillväxt på 188 procent år över år. Första kvartalet 2025 såg nästan 18 000 skadliga paket över olika ekosystem.

Problemet är fundamentalt: Den tillit som gjorde open source möjligt – automatiska uppdateringar, transparens, fri tillgång – har blivit vår största sårbarhet. Modern mjukvaruutveckling bygger på att utvecklare litar på kod de aldrig sett, skriven av personer de aldrig träffat, distribuerad via system de inte kontrollerar.

När AI-kodning gör det ännu enklare att använda npm utan att förstå riskerna, växer attackytan exponentiellt. Varje hobbyutvecklare som kör npm install efter att ha frågat ChatGPT om hjälp blir en potentiell ingångspunkt.

Industrin måste hitta en balans mellan hastighet och säkerhet, mellan tillit och verifiering, mellan automatisering och mänsklig övervakning. Annars är Shai-Hulud bara början.


Källor och vidare läsning

Den här artikeln är undersökt med ChatGPT och Claude. Det kan förekomma felaktigheter.

Share.

Daniel Larsson har jobbat med cybersecurity och datasäkerhet med fokus på Internet sedan 1998. Under åren har han marknadsfört scaleup cyberbolag inom områden som PKI, certifikat, digital signering, mobil säkerhet och kryptering. Han har tung erfarenhet av digital marknadsföring, webbutveckling och e-handel från några av världens största varumärken och jobbar till vardags på Expandtalk.

Leave A Reply Cancel Reply

Denna webbplats använder Akismet för att minska skräppost. Lär dig om hur din kommentarsdata bearbetas.

Exit mobile version