Red Hat-pakker ble kapret med ekte signaturer

Microsoft Threat Intelligence beskriver et nytt supply-chain-angrep som bør få norske sikkerhetsmiljøer til å stramme inn blikket på npm, CI/CD og skyhemmeligheter. Angrepet traff 32 modifiserte pakker fordelt på mer enn 90 versjoner under Red Hats @redhat-cloud-services-scope på npm.

Det mest alvorlige er ikke bare at pakker ble infisert. Det alvorlige er at angriperne ifølge Microsoft brukte den legitime GitHub Actions OIDC-publiseringsflyten fra prosjektets CI/CD-kjede. Resultatet var at de forgiftede pakkene kunne fremstå med ekte provenance-signaturer. En kontroll som mange virksomheter nå bygger mer tillit til, ble dermed en del av angrepsflaten.

Kampanjen har fått markøren Miasma: The Spreading Blight. Den bygger på et mønster som har blitt stadig mer relevant etter bølgen av angrep mot utviklerøkosystemer: skadelig kode kjøres automatisk ved installasjon, stjeler hemmeligheter og forsøker å spre seg videre via utviklernes egne tilganger.

Signert betyr ikke nødvendigvis trygt

De infiserte pakkene kjørte en npm preinstall-hook. Det betyr at koden kunne starte før utvikleren faktisk tok pakken i bruk. Microsoft beskriver en kraftig obfuskert dropper på 4,29 MB som pakket ut flere lag med kode, lastet ned Bun-runtime og startet en nyttelast som gikk etter legitimasjon og skytilganger.

Listen over mål er bred: GitHub, npm, AWS, Azure, Google Cloud Platform, HashiCorp Vault, Kubernetes, SSH-nøkler, Git-legitimasjon og lokale utviklerhemmeligheter. I CI/CD-miljøer forsøkte skadevaren også å hente hemmeligheter fra GitHub Actions runner-minne. Microsoft skriver at Linux-runnere så ut til å være et hovedmål, men at skadevaren hadde støtte for Linux, macOS og Windows.

For virksomheter som automatiserer mer av utviklingsløpet med AI-kodeverktøy og agenter, er dette en viktig påminnelse. Tempoet i dependency-endringer går opp. Flere installasjoner, testløp og bygg skjer uten samme manuelle friksjon som før. Da må kontrollene tåle at angriperen ikke bare skjuler seg i ukjent kode, men også bruker legitime publiseringsmekanismer og signaturer.

Hva dette betyr for CIO og CISO

Mange norske virksomheter har de siste årene flyttet mye risiko fra egen kode til leverandørkjeder, åpne pakker og automatiserte pipelines. Det gir fart, men også en annen type ansvar. Et angrep som Miasma treffer ikke bare utviklernes maskiner. Det kan treffe byggemiljø, skyplattformer, Kubernetes, Vault og GitHub-organisasjonen i samme løp.

Det gjør hendelsen relevant langt utenfor teams som bruker Red Hat-pakkene direkte. Spørsmålet er om organisasjonen har oversikt over hvilke pakker som kan kjøre installasjonsskript, hvilke tokens som finnes i CI/CD, hvor bredt GitHub Actions-runnere får lese hemmeligheter, og hvor raskt sky- og npm-nøkler kan roteres ved mistanke.

Den klassiske responsen på sårbare pakker er å oppdatere. Her er ikke det nok. Når pakken har kjørt, må virksomheten vurdere om hemmeligheter allerede er lest ut. Da blir riktig første tiltak å identifisere berørte versjoner, se etter installasjoner i utviklermaskiner og byggelogg, rotere relevante tokens og kontrollere om angriperen kan ha publisert videre fra kompromitterte maintainer- eller CI/CD-kontoer.

Tiltak som bør inn i beredskapen

Det praktiske bildet er ganske nøkternt. Dependency-kontroll må flyttes fra periodiske skann til løpende overvåking av pakkeoppførsel, publiseringshistorikk og installasjonsskript. Preinstall, postinstall og andre lifecycle-hooks bør behandles som aktiv kodekjøring, ikke som metadata.

Virksomheter bør også gå gjennom trusted publishing og OIDC-oppsett. Provenance er fortsatt nyttig, men bare hvis man samtidig kan verifisere at riktig pipeline, riktig repo og riktig rolle faktisk publiserte pakken. Signaturen forteller at noe kom fra en godkjent flyt. Den beviser ikke alene at flyten ikke var misbrukt.

For AI-assistert utvikling er lærdommen ekstra enkel: agenter og kodeassistenter må ikke få ubegrenset spillerom til å installere og kjøre pakker i miljøer med produksjonsnære hemmeligheter. Sandbox, egress-kontroll, kortlevde tokens og separate testmiljøer er ikke byråkrati. Det er grunnmuren når kode blir generert, installert og testet i høyere tempo.

Microsoft skriver at funnene ble delt med npm-teamet, og at berørte repositorier ble fjernet. Det løser ikke risikoen for virksomheter som allerede har installert pakkene. For dem er dette en hendelse for incident response, ikke bare for dependency management.

Kilder og medier

Primærkilde: Microsoft Security Blog / Microsoft Threat Intelligence, "Preinstall to persistence: Inside the Red Hat npm Miasma credential-stealing campaign", publisert 3. juni 2026. Source: https://www.microsoft.com/en-us/security/blog/2026/06/02/preinstall-persistence-inside-red-hat-npm-miasma-credential-stealing-campaign/

Supplerende kilde: Socket, "Mini Shai-Hulud Campaign Hits Red Hat Cloud Services npm Packages", publisert 1. juni 2026. Source: https://socket.dev/blog/mini-shai-hulud-campaign-hits-red-hat-cloud-services-npm-packages

Thumbnail: OpenAI Image 2 / hogby.ai