Sapphire Sleet kapret 145 Mastra-pakker: Slik fungerte npm-angrepet

Mastra er et åpent TypeScript-rammeverk for å bygge AI-applikasjoner og AI-agenter. De berørte pakkene hadde til sammen mer enn 1,1 millioner ukentlige nedlastinger, noe som gjorde hendelsen relevant langt utover selve prosjektet . Microsoft knyttet operasjonen med høy sikkerhet til Sapphire Sleet i en oppdatering 19. juni .

Slik ble angrepet gjennomført

Angrepet fulgte en kjent oppskrift for programvareforsyningskjeder: Først ble en konto med høy tillit kapret. Deretter ble ondsinnede pakkeversjoner distribuert gjennom den legitime kanalen.

1. Sosial manipulering og kontoovertakelse

Angriperne målrettet en legitim Mastra-vedlikeholder gjennom sosial manipulering og fikk tilgang til npm-påloggingsopplysningene. Kontoen, identifisert som ehindero, hadde publiseringstilgang til hele @mastra-omfanget .

2. Massepublisering på kort tid

Med den kaprede kontoen publiserte angriperne nye versjoner av pakkene i @mastra/*-navnerommet. Hele operasjonen skal ha pågått i et vindu på rundt 88 minutter, mens selve publiseringsbølgen ifølge enkelte analyser skjedde på så lite som 19 minutter . Hastigheten peker mot bruk av automatiserte skript, ikke manuelle opplastinger.

3. En falsk avhengighet med nesten riktig navn

De kompromitterte versjonene inneholdt avhengigheten easy-day-js. Navnet ligner på dayjs, et legitimt og mye brukt JavaScript-bibliotek for dato- og tidsfunksjoner . Denne typen navnelikhet kalles typosquatting: Angriperen håper at utviklere eller automatiserte prosesser ikke oppdager den lille forskjellen.

Kampanjen er derfor omtalt som «easy-day-js» .

4. Koden startet ved installasjon

Den skadelige koden ble utløst gjennom npm-skriptet postinstall. Det betyr at nyttelasten kunne kjøre allerede da en utvikler eller et byggesystem utførte npm install – uten at applikasjonen eller en AI-agent måtte startes først .

5. På jakt etter nøkler og hemmeligheter

Etter aktivering kunne nyttelasten lete etter kryptolommeboknøkler, skylegitimasjon og hemmeligheter brukt i CI/CD-systemer – verktøyene som automatisk bygger, tester og publiserer programvare . Microsoft beskriver også at koden slo av TLS-verifisering og lastet ned en ny stealer-komponent fra angripernes infrastruktur .

Microsoft peker på Sapphire Sleet

Microsoft vurderte 19. juni med høy sikkerhet at operasjonen var utført av Sapphire Sleet, en nordkoreansk statlig aktør som i hovedsak retter seg mot finans- og kryptosektoren. Vurderingen bygger blant annet på infrastrukturen og angrepsteknikkene som ble observert, og på likheter med tidligere operasjoner gruppen er knyttet til .

Amazon Threat Intelligence har i tillegg koblet Sapphire Sleet til tidligere angrep mot npm-pakker som axios, debug, chalk og typo-crypto .

Microsoft strammer inn publisering av NuGet-pakker

Mastra-hendelsen kom samtidig som Microsoft allerede arbeidet med å redusere risikoen ved langlivede publiseringsnøkler. Tiltakene retter seg mot selve svakheten som angrepet utnyttet: En stjålet nøkkel kan gi angriperen langvarig tilgang til å publisere pakker i en annens navn.

Nye NuGet-nøkler får maksimalt 30 dagers levetid

Fra 17. august 2026 kan nye API-nøkler på NuGet.org – Microsofts pakkeregister for .NET-utviklere – ha en maksimal levetid på 30 dager, ned fra 365 dager .

Alle nøkler som ble opprettet før denne datoen, skal utløpe 1. november 2026 . Vedlikeholdere må derfor enten opprette nye nøkler etter behov eller gå over til Trusted Publishing.

Microsofts begrunnelse er at langlivede API-nøkler er «løse strenger som er enkle å miste», og at de har blitt en viktig angrepsflate i programvareforsyningskjeden . En nøkkel som lekker, kan gi angriperen et stort tidsvindu til å publisere trojaniserte pakker.

Trusted Publishing blir anbefalt standard

Microsoft anbefaler i stedet Trusted Publishing, en publiseringsmodell som ble lansert på NuGet.org i september 2025. Modellen bruker OpenID Connect (OIDC) til å bekrefte identiteten til arbeidsflyten i CI/CD-systemet, i stedet for å lagre en langlivet API-nøkkel .

I praksis skjer dette slik:

• En arbeidsflyt, for eksempel i GitHub Actions, ber om et kryptografisk signert OIDC-token.
• NuGet.org kontrollerer tokenet mot en forhåndsdefinert policy for repository, arbeidsflyt og eventuelt miljø.
• Plattformen utsteder en midlertidig, engangsbasert API-nøkkel for publiseringen.
• Nøkkelen varer vanligvis i omtrent én time og utløper automatisk .

Fordelene er at:

• det ikke må lagres langlivede hemmeligheter i kodearkivet eller CI/CD-systemet
• tilgang gis med kortlivede legitimasjoner for hver publisering
• identiteten til repositoryet og arbeidsflyten kan kontrolleres
• manuell nøkkelrotasjon blir unødvendig
• skadeomfanget begrenses dersom en legitimasjon likevel blir avslørt

npm gjør også publisering mindre avhengig av langlivede tokens

Microsofts grep skjer som del av en bredere innstramming i pakkeøkosystemet.

• Klassiske npm-tokens er tilbakekalt: npm tilbakekalte alle klassiske, langlivede tokens permanent i desember 2025. npm login gir nå sesjonstokens som utløper etter to timer .
• Kortere levetid for granulære tokens: Nye skriveaktiverte granulære tilgangstokens har en standardlevetid på sju dager og en maksimal levetid på 90 dager .
• Staged publishing: npm har gjort funksjonen allment tilgjengelig. Den krever at en vedlikeholder godkjenner en utgivelse med tofaktorautentisering før pakken blir offentlig installerbar .
• Trusted Publishing for npm: npm støtter også OIDC-basert Trusted Publishing, slik at pakker kan publiseres direkte fra godkjente CI/CD-arbeidsflyter uten langlivede npm-tokens .

Til sammen skal tiltakene gjøre det vanskeligere å gjenta akkurat denne typen angrep: én kapret vedlikeholderkonto med publiseringstilgang til et helt pakkeomfang.

Dette bør utviklere og vedlikeholdere gjøre

• Bytt ut gamle NuGet-nøkler: Har du nøkler opprettet før 17. august 2026, må de erstattes før 1. november 2026 .
• Gå over til Trusted Publishing: OIDC-basert publisering fjerner behovet for langlivede hemmeligheter i CI/CD. Løsningen støttes av blant annet NuGet.org, npm og PyPI .
• Gå gjennom npm-arbeidsflytene: Kontroller at publiseringsjobber bruker en støttet autentiseringsmetode med begrenset levetid, tofaktorautentisering eller Trusted Publishing .
• Lås avhengighetsversjoner: Bruk kjente, verifiserte versjoner for kritiske systemer, og unngå automatiske oppgraderinger før nye versjoner er kontrollert .
• Vurder å slå av installasjonsskript: npm install --ignore-scripts, eller innstillingen ignore-scripts = true, kan hindre at ondsinnede postinstall-skript kjører automatisk .
• Roter berørte hemmeligheter: Dersom et system installerte eller bygget en kompromittert pakke, bør relevante sky-, CI/CD-, publiserings- og kryptolegitimasjoner vurderes rotert .

Mastra-angrepet viser at tillit i åpen kildekode ikke bare handler om selve kildekoden. Den handler også om hvem som kan publisere, hvor lenge tilgangen varer, og om en automatisert arbeidsflyt kan bevise hvem den er – før en ny pakke slippes løs på resten av økosystemet.