Atomic Arch: Så kapades 1 900 AUR-paket i en av Arch Linux största attacker

I juni 2026 drabbades Arch User Repository (AUR) av en systematisk leveranskedjeattack som komprometterade nästan 1 900 community-underhållna paket – en av de största incidenterna i arkivets historia. Attacken har döpts till Atomic Arch av forskare på Sonatype och spåras som Sonatype-2026-003775 med ett CVSS-värde på 8,7. Kampanjen utnyttjade en legitim tillitsmekanism för att tyst distribuera skadlig kod som stjäl inloggningsuppgifter och ett rootkit på kärnnivå till utvecklares arbetsstationer .

Attackens omfattning och tidslinje

Det som först verkade vara en isolerad händelse svällde snabbt till en omfattande kompromettering under en enda helg.

• 11 juni 2026 (första vågen): Sonatype identifierade den inledande attackvågen och bekräftade cirka 408 komprometterade paket .
• 12 juni 2026 (andra vågen): En andra våg utökade attacken. Sammanställningar från communityn och forskare vid PrivacyGuides rapporterade att antalet stigit till över 1 500 paket .
• 14–15 juni 2026 (eskalering): Ytterligare analys av Corgea Research bekräftade minst 1 619 unika skadliga paketnamn, medan Risky.biz rapporterade att slutsumman klättrat förbi 1 900 .

SafeDep:s kampanjsida och community-sammanställda listor räknar slutligen upp 1 937 drabbade AUR-paketnamn, vilket understryker attackens enorma räckvidd . Viktigt att notera är att de officiella Arch Linux-förråden (core, extra, community) inte påverkades – detta var uteslutande en AUR-incident .

Attackmetoden: Utnyttjande av ett tillitsbaserat arbetsflöde

Atomic Arch var inte ett intrång i Archs infrastruktur. Istället var det ett kirurgiskt utnyttjande av AUR:s arbetsflöde för adoption av övergivna paket – en process som tillåter alla community-medlemmar att ta över ägandeskapet av övergivna paket .

Attacken utvecklades i två distinkta vågor där förövarna förfinade sin metod för att undvika upptäckt.

Våg 1: npm-kroken (11 juni)

Angriparna adopterade systematiskt övergivna paket. När de väl fick underhållsbehörighet ändrade de inte programvarans källkod – ett drag som skulle ha brutit kontrollsummor och utlöst alarm. Istället modifierade de byggskripten PKGBUILD för att injicera skadliga npm-beroenden: atomic-lockfile (v1.4.2) och js-digest (v4.2.2) . Dessa paket konfigurerades för att köras automatiskt under makepkg-processen. För att ytterligare dölja den skadliga aktiviteten bäddades koden in i .install-skript och förkläddes med hjälp av shell-strängdelning, blandad citering och hexadecimala escape-sekvenser .

Våg 2: Bun-bytet (12 juni)

Bara en dag senare dök en andra våg upp. Denna gång bytte angriparna ut npm-installationsvägen mot en Bun-baserad installationsprocess och använde ett annat skadligt paket vid namn lockfile-js (v1.4.2) . Bytet försvårade upptäckt eftersom många av de tidiga indikatorerna på kompromettering (IoC) fokuserade på npm-registret, och säkerhetsverktyg var tvungna att uppdateras för att övervaka den nya körtidsmiljön och beroendet .

Genom att endast förgifta bygginstruktionerna snarare än själva programvaran kringgick angriparna traditionella integritetskontroller. Källkoden uppströms såg ren ut, och den skadliga koden laddades bara ner och kördes vid byggtillfället, vilket gjorde den osynlig för användare som inte manuellt inspekterade PKGBUILD-skript .

De skadliga nyttolasterna: Stöldprogram och rootkit

Maskiner som byggde de komprometterade paketen fick en tvåstegs-nyttolast utformad för spionage och uthållighet.

• Rust-baserat stöldprogram för inloggningsuppgifter: En fokuserad binär som skördade utvecklarhemligheter, inklusive webbläsarsessioner, SSH-nycklar, GitHub-tokens, npm-tokens, Slack/Teams-sessioner, Vault-tokens, Docker/Podman-inloggningsuppgifter och åtkomstnycklar för molntjänster .
• eBPF-rootkit (endast root): Om paketet byggdes med root-privilegier distribuerade den skadliga koden ett eBPF-rootkit kapabelt att dölja sina egna filer, processer och nätverksaktivitet från standardverktyg för upptäckt som ps och htop. Rootkitet använde /sys/fs/bpf/ för uthållighet, vilket gör det exceptionellt svårt att ta bort .

Kombinationen av ett stöldprogram för inloggningsuppgifter och ett rootkit på kärnnivå gjorde detta till ett allvarligt hot, särskilt för utvecklare vars arbetsstationer ofta innehåller privilegierade åtkomstnycklar och känslig data.

Respons från community och utvecklare

Arch Linux-communityn och säkerhetsbranschen agerade snabbt, men responsen komplicerades av attackens omfattning.

• Arch-teamets åtgärder: Arch-bidragsgivare öppnade en konsoliderad AUR-rapporttråd den 11 juni och påbörjade arbetet med att återställa skadliga incheckningar, banna angriparnas konton och städa upp bland de övergivna paketen. Arch Linux stoppade även nyregistreringar på AUR följande måndag för att förhindra ytterligare missbruk . Arch-paketeraren Jonathan Grotelüschen bekräftade att teamet arbetade med att "återställa eller radera alla skadliga incheckningar och banna de ansvariga kontona" .
• Splittring inom communityn: Attacken utlöste intensiv debatt. I hetsiga diskussioner på plattformar som PrivacyGuides-forumet krävde vissa community-medlemmar att AUR helt skulle stängas ner, med argumentet att dess tillitsbaserade modell var fundamentalt trasig vid denna komprometteringsskala .
• Tredjepartsrespons: Säkerhetsföretag som Sonatype, Corgea, Cloud Security Alliance (CSA) och TrueSec publicerade detaljerade analyser, indikatorer på kompromettering (IoC) och gemenskapsskript för upptäckt (såsom aur-malware-check) för att hjälpa användare att granska sina system .

En viktig källa till friktion var att det officiella Arch-teamet inte omedelbart publicerade en enda, kanonisk lista över alla drabbade paket, vilket ledde till att användare förlitade sig på tredjepartslistor från källor som SafeDep och Corgea .

Lärdomar för Linux-ekosystemet

Atomic Arch-attacken blottlägger strukturella svagheter i tillitsbaserade community-förråd som förlitar sig på frivilligt underhåll.

• Övergivna paket-fällan är en systemrisk: Möjligheten för vilken användare som helst att omedelbart adoptera och modifiera ett övergivet paket utan identitetsverifiering eller obligatorisk kodgranskning förvandlade en bekvämlighetsfunktion till en attackvektor med hög påverkan .
• Byggtidsinjektion kringgår integritetskontroller: Traditionella försvarsmekanismer är beroende av att verifiera integriteten hos källkodsarkiv. Eftersom Atomic Arch förgiftade byggskripten istället för källkoden gav standardkontrollsummor inget skydd .
• Tvär-ekosystem leveranskedjor är den nya frontlinjen: Attacken beväpnade npm- och Bun-registren för att distribuera skadlig kod in i Linux-ekosystemet, vilket bevisar att ett enda komprometterat paket i ett register kan få kaskadeffekter över plattformar .

Vad drabbade användare måste göra nu

Säkerhetsforskare och vägledningen från Arch-communityn är enig: det här är inte ett fall där det räcker att ta bort ett enskilt paket.

1. Utgå från fullständig kompromettering: Behandla alla värdar som byggde eller uppdaterade ett AUR-paket mellan 9 och 12 juni 2026 som fullständigt komprometterade .
2. Ominstallera från rent media: En enkel skadlig kod-skanning är opålitlig eftersom eBPF-rootkitet är utformat för att gömma sig från upptäcktsverktyg. Den enda garanterade åtgärden är att bygga om det drabbade systemet från pålitligt installationsmedia .
3. Rotera alla inloggningsuppgifter omedelbart: Utgå från att stöldprogrammet har exfiltrerat varje hemlighet som var tillgänglig på maskinen: SSH-nycklar, GitHub- och npm-tokens, Vault-tokens, åtkomstnycklar för molntjänster, webbläsarsessioner och Docker/Podman-inloggningsuppgifter .
4. Granska AUR-historik: Kör

   pacman -Qm

   för att lista alla externa paket installerade på systemet och korsreferera dem mot community-publicerade listor över skadliga paket .
5. Kontrollera efter indikatorer på kompromettering: Sök efter spår av atomic-lockfile, lockfile-js eller js-digest i byggcache, samt misstänkta poster under /sys/fs/bpf/ .
6. Behandla detta som en incidenthanteringshändelse: Organisationer bör inte behandla detta som en enkel skanningsövning. Alla Arch-utvecklares arbetsstationer eller CI-byggservrar som hämtade från AUR under attackfönstret bör behandlas som en säkerhetsincident som kräver fullständig respons .