Atomic Arch: Forsyningskjede-angrepet som kapret 1900 AUR-pakker

I juni 2026 rammet et systematisk forsyningskjedeangrep mot Arch User Repository (AUR) nesten 1900 fellesskapsvedlikeholdte pakker, noe som gjør det til en av de største hendelsene i depotets historie. Kampanjen, døpt Atomic Arch av forskere hos Sonatype og sporet som Sonatype-2026-003775 med en CVSS-score på 8.7, utnyttet en legitim tillitsmekanisme for stille å distribuere en infostealer og et rootkit på kjernenivå til utviklerarbeidsstasjoner .

Omfang og tidslinje

Det som begynte som en tilsynelatende begrenset hendelse, utviklet seg raskt til en omfattende kompromittering i løpet av en enkelt helg.

• 11. juni 2026 (Første bølge): Sonatype identifiserte den første bølgen og bekreftet omtrent 408 kompromitterte pakker .
• 12. juni 2026 (Andre bølge): En ny bølge utvidet angrepet. Samfunnets konsolideringsarbeid og forskere hos PrivacyGuides rapporterte at antallet hadde steget til over 1500 pakker .
• 14.-15. juni 2026 (Opptrapping): Videre analyse fra Corgea Research bekreftet minst 1619 unike ondsinnede pakkenavn, mens Risky.biz meldte at det endelige antallet passerte 1900 .

Kampanjesiden til SafeDep og fellesskapets konsoliderte lister oppregnet til slutt 1937 berørte AUR-pakkenavn, noe som understreker angrepets massive rekkevidde . Det er kritisk viktig å merke seg at de offisielle Arch Linux-depotene (core, extra, community) ikke var berørt – dette var utelukkende en AUR-hendelse .

Angrepsmetoden: Utnyttelse av en tillitsbasert arbeidsflyt

Atomic Arch var ikke et innbrudd i Arch-infrastrukturen. I stedet var det en kirurgisk utnyttelse av AURs arbeidsflyt for adopsjon av foreldreløse pakker, en prosess som lar ethvert fellesskapsmedlem overta eierskapet til forlatte pakker .

Angrepet utspilte seg i to adskilte bølger, der gjerningspersonene forfinet fremgangsmåten for å unngå oppdagelse.

Bølge 1: npm-kroken (11. juni)

Angriperne adopterte systematisk foreldreløse pakker. Da de hadde fått vedlikeholderrettigheter, endret de ikke selve kildekoden til programvaren – et grep som ville ha brutt sjekksummer og utløst alarmer. I stedet endret de PKGBUILD-byggeskriptene for å injisere ondsinnede npm-avhengigheter: atomic-lockfile (v1.4.2) og js-digest (v4.2.2) . Disse pakkene var konfigurert til å kjøre automatisk under makepkg-prosessen. For ytterligere å skjule den ondsinnede aktiviteten ble koden bygget inn i .install-skript og forkledd ved hjelp av shell-strengsplitting, blandet quoting og heksadesimale tegn .

Bølge 2: Bun-bytten (12. juni)

Bare én dag senere dukket en ny bølge opp. Denne gangen byttet angriperne ut npm-installasjonsstien med en Bun-basert installasjonsprosess, og brukte en annen ondsinnet pakke kalt lockfile-js (v1.4.2) . Skiftet kompliserte deteksjon, ettersom mange av de første indikatorene på kompromittering (IoCs) fokuserte på npm-registeret, og sikkerhetsverktøy måtte oppdateres for å overvåke den nye kjøretidsmotoren og avhengigheten .

Ved å forgifte kun byggeinstruksjonene i stedet for selve programvaren, omgikk angriperne tradisjonelle integritetssjekker. Den oppstrøms kildekoden så ren ut, og skadevaren ble kun hentet og kjørt på byggetidspunktet, noe som gjorde den usynlig for brukere som ikke manuelt inspiserte PKGBUILD-skript .

De ondsinnede lastene: Infostealer og rootkit

Maskiner som bygde de kompromitterte pakkene mottok en totrinns nyttelast designet for spionasje og vedvarende tilstedeværelse.

• Rust-basert infostealer: Et fokusert binærprogram som høstet utviklerhemmeligheter, inkludert nettleserøkter, SSH-nøkler, GitHub-tokens, npm-tokens, Slack/Teams-økter, Vault-tokens, Docker/Podman-påloggingsdetaljer og skytilgangsnøkler .
• eBPF-rootkit (kun root): Hvis pakken ble bygget med root-rettigheter, distribuerte skadevaren et eBPF-rootkit som var i stand til å skjule sine egne filer, prosesser og nettverksaktivitet for standard deteksjonsverktøy som ps og htop. Rootkitet brukte /sys/fs/bpf/ for å opprettholde tilstedeværelse, noe som gjorde det usedvanlig vanskelig å fjerne .

Kombinasjonen av en infostealer og et rootkit på kjernenivå gjorde dette til en alvorlig trussel, spesielt for utviklere hvis arbeidsstasjoner ofte innehar privilegerte tilgangsnøkler og sensitive data.

Fellesskapets og utviklernes respons

Arch Linux-miljøet og sikkerhetsbransjen reagerte raskt, men responsen ble komplisert av angrepets omfang.

• Arch-teamets handlinger: Arch-bidragsytere opprettet en konsolidert AUR-rapporteringstråd 11. juni og begynte prosessen med å tilbakestille ondsinnede innsendinger, utestenge angriperkontoer og rydde opp i puljen av foreldreløse pakker. Arch Linux suspenderte også nye kontoregistreringer på AUR den påfølgende mandagen for å forhindre ytterligere misbruk . Arch-pakkevedlikeholder Jonathan Grotelüschen bekreftet at teamet jobbet med å «gjenopprette eller slette alle ondsinnede innsendinger og utestenge de ansvarlige kontoene» .
• Konflikt i fellesskapet: Angrepet utløste intens debatt. Heftige diskusjoner på plattformer som PrivacyGuides-forumet førte til at enkelte fellesskapsmedlemmer ba om at AUR ble fullstendig stengt, med argumentet at den tillitsbaserte modellen var fundamentalt ødelagt ved et kompromiss av dette omfanget .
• Tredjepartsrespons: Sikkerhetsfirmaer som Sonatype, Corgea, Cloud Security Alliance (CSA) og TrueSec publiserte detaljerte analyser, indikatorer på kompromittering (IoCs) og fellesskapsdeteksjonsskript (som aur-malware-check) for å hjelpe brukere med å revidere systemene sine .

En viktig kilde til friksjon var at det offisielle Arch-teamet ikke umiddelbart publiserte en enkelt, autoritativ liste over alle berørte pakker, noe som førte til at brukere baserte seg på tredjepartsmanifester fra kilder som SafeDep og Corgea .

Lærdom for Linux-økosystemet

Atomic Arch-angrepet avdekker strukturelle svakheter i tillitsbaserte fellesskapsdepoter som er avhengige av frivillig vedlikehold.

• «Den foreldreløse fellen» er en systemrisiko: Muligheten for enhver bruker til umiddelbart å overta og endre en forlatt pakke, uten identitetsbekreftelse eller obligatorisk kodegjennomgang, forvandlet en praktisk funksjon til en angrepsvektor med stor effekt .
• Injeksjon på byggetidspunkt omgår integritetssjekker: Tradisjonelle forsvarsmekanismer er avhengige av å verifisere integriteten til kildekodearkiver. Siden Atomic Arch forgiftet byggeskriptene i stedet for kilden, ga standard sjekksummer ingen beskyttelse .
• Kryss-økosystem forsyningskjeder er den nye frontlinjen: Angrepet brukte npm- og Bun-registrene som våpen for å distribuere skadevare inn i Linux-økosystemet, noe som beviser at en enkelt kompromittert pakke i ett register kan ha kaskadeeffekter på tvers av plattformer .

Hva berørte brukere må gjøre nå

Sikkerhetsforskere og Arch-fellesskapets veiledning er enstemmige: Dette er ikke et tilfelle der fjerning av en enkelt pakke er tilstrekkelig.

1. Anta full kompromittering: Behandle enhver vertsmaskin som bygde eller oppdaterte en AUR-pakke mellom 9. og 12. juni 2026 som fullstendig kompromittert .
2. Installer på nytt fra rent medium: En enkel skadevareskanning er upålitelig fordi eBPF-rootkitet er designet for å skjule seg for deteksjonsverktøy. Den eneste garanterte utbedringen er å gjenoppbygge det berørte systemet fra pålitelig installasjonsmedium .
3. Roter alle påloggingsdetaljer umiddelbart: Anta at infostealeren har eksfiltrert alle hemmeligheter som var tilgjengelige på maskinen: SSH-nøkler, GitHub- og npm-tokens, Vault-tokens, skytilgangsnøkler, nettleserøkter og Docker/Podman-påloggingsdetaljer .
4. Revider AUR-historikk: Kjør

   pacman -Qm

   for å liste alle eksterne pakker installert på systemet og kryssreferer dem mot fellesskapets publiserte lister over ondsinnede pakker .
5. Sjekk for indikatorer på kompromittering: Søk etter spor av atomic-lockfile, lockfile-js, eller js-digest i byggecacher, samt mistenkelige oppføringer under /sys/fs/bpf/ .
6. Behandle dette som en hendelseshåndteringssituasjon: Organisasjoner bør ikke behandle dette som en enkel skanningsøvelse. Enhver Arch-utviklerarbeidsstasjon eller CI/build-server som hentet fra AUR i angrepsvinduet, bør behandles som en sikkerhetshendelse som krever en fullstendig respons .