Atomic Arch: Jak hackeři proměnili 1 900 opuštěných AUR balíčků ve zbraň

V červnu 2026 zasáhl Arch User Repository (AUR) masivní útok na dodavatelský řetězec, který zkompromitoval téměř 1 900 komunitou spravovaných balíčků. Kampaň, kterou výzkumníci ze společnosti Sonatype pojmenovali Atomic Arch a sledují ji pod označením Sonatype-2026-003775 s CVSS skóre 8.7, systematicky zneužila legitimní mechanismus důvěry k tiché instalaci malwaru pro krádež přihlašovacích údajů a rootkitu na úrovni jádra na počítače vývojářů .

Rozsah a časová osa

To, co zpočátku vypadalo jako omezený incident, se během jediného víkendu rozrostlo do rozsáhlého kompromitování.

• 11. června 2026 (První vlna): Společnost Sonatype identifikovala první vlnu a potvrdila přibližně 408 kompromitovaných balíčků .
• 12. června 2026 (Druhá vlna): Druhá vlna útok ještě rozšířila. Komunitní konsolidační úsilí a výzkumníci z PrivacyGuides informovali, že počet přesáhl 1 500 balíčků .
• 14.–15. června 2026 (Eskalace): Další analýza společnosti Corgea Research ověřila nejméně 1 619 unikátních jmen škodlivých balíčků, zatímco server Risky.biz informoval, že konečný počet překročil 1 900 .

Stránka kampaně SafeDep a komunitou sestavené seznamy nakonec vyčíslily 1 937 zasažených jmen AUR balíčků, což podtrhuje obrovský dosah útoku . Je kriticky důležité zdůraznit, že oficiální repozitáře Arch Linuxu (core, extra, community) nebyly zasaženy – jednalo se výhradně o incident v rámci AUR .

Metoda útoku: Zneužití pracovního postupu založeného na důvěře

Atomic Arch nebyl průlomem do infrastruktury Archu. Místo toho šlo o precizní zneužití procesu adopce opuštěných balíčků v AUR. Tento proces umožňuje kterémukoli členovi komunity přihlásit se o vlastnictví opuštěných balíčků .

Útok proběhl ve dvou odlišných vlnách, přičemž útočníci svůj přístup zdokonalovali, aby se vyhnuli detekci.

Vlna 1: Háček na npm (11. června)

Útočníci systematicky adoptovali opuštěné balíčky. Jakmile získali oprávnění správce, nezměnili samotný zdrojový kód softwaru – což by porušilo kontrolní součty a spustilo alarmy. Místo toho upravili build skripty PKGBUILD, do kterých vložili škodlivé závislosti na npm: atomic-lockfile (v1.4.2) a js-digest (v4.2.2) . Tyto balíčky byly nakonfigurovány tak, aby se automaticky spustily během procesu makepkg. Aby byla škodlivá aktivita ještě lépe skryta, kód byl vložen do .install skriptů a maskován pomocí technik, jako je rozdělování řetězců v shellu, kombinované uvozovky a hexadecimální escapování .

Vlna 2: Přechod na Bun (12. června)

Jen o den později se objevila druhá vlna. Tentokrát útočníci nahradili instalační cestu přes npm procesem instalace pomocí Bun a použili jiný škodlivý balíček s názvem lockfile-js (v1.4.2) . Tato změna zkomplikovala detekci, protože mnoho počátečních indikátorů kompromitace (IoC) se zaměřovalo na registr npm a bezpečnostní nástroje musely být aktualizovány, aby monitorovaly i nové běhové prostředí a závislost .

Tím, že útočníci „otrávili“ pouze pokyny pro sestavení, a nikoli software samotný, obešli tradiční kontroly integrity. Zdrojový kód se jevil jako čistý a malware byl stažen a spuštěn až v době sestavování balíčku, což ho činilo neviditelným pro uživatele, kteří ručně nekontrolovali skripty PKGBUILD .

Škodlivé složky: Krádež dat a rootkit

Stroje, které sestavily kompromitované balíčky, obdržely dvoufázovou výbavu navrženou pro špionáž a zajištění perzistence.

• Nástroj pro krádež přihlašovacích údajů napsaný v Rustu: Specializovaný binární soubor, který sklízel tajemství vývojářů, včetně relací prohlížeče, SSH klíčů, GitHub tokenů, npm tokenů, relací Slack/Teams, Vault tokenů, přihlašovacích údajů pro Docker/Podman a cloudových přístupových klíčů .
• eBPF Rootkit (pouze s právy root): Pokud byl balíček sestaven s administrátorskými právy, malware nasadil eBPF rootkit schopný skrýt své vlastní soubory, procesy a síťovou aktivitu před standardními detekčními nástroji, jako jsou ps a htop. Rootkit využíval /sys/fs/bpf/ pro zajištění své perzistence, což jeho odstranění mimořádně ztěžuje .

Kombinace nástroje pro krádež přihlašovacích údajů a rootkitu na úrovni jádra z toho učinila vážnou hrozbu, zejména pro vývojáře, jejichž pracovní stanice často obsahují privilegované přístupové klíče a citlivá data.

Reakce komunity a vývojářů

Komunita Arch Linuxu a bezpečnostní průmysl se rychle zmobilizovaly, ale reakce byla komplikována rozsahem útoku.

• Akce týmu Archu: Přispěvatelé Archu založili 11. června konsolidované diskuzní vlákno na AUR a zahájili proces navracení škodlivých commitů, blokování účtů útočníků a čištění fondu opuštěných balíčků. Následující pondělí Arch Linux také pozastavil registrace nových účtů na AUR, aby zabránil dalšímu zneužití . Správce balíčků Archu, Jonathan Grotelüschen, potvrdil, že tým pracuje na „obnovení nebo smazání všech škodlivých commitů a zablokování odpovědných účtů“ .
• Konflikt v komunitě: Útok vyvolal intenzivní debatu. Na platformách, jako je fórum PrivacyGuides, se strhly vášnivé diskuze, přičemž někteří členové komunity volali po úplném uzavření AUR s argumentem, že jeho model založený na důvěře je při takovém rozsahu kompromitace fatálně vadný .
• Reakce třetích stran: Bezpečnostní firmy včetně Sonatype, Corgea, Cloud Security Alliance (CSA) a TrueSec publikovaly podrobné analýzy, Indikátory kompromitace (IoC) a komunitní detekční skripty (jako je aur-malware-check), které uživatelům pomáhají auditovat jejich systémy .

Klíčovým zdrojem třenic bylo, že oficiální tým Archu okamžitě nezveřejnil jediný, kanonický seznam všech zasažených balíčků, což vedlo uživatele k spoléhání se na manifesty třetích stran ze zdrojů, jako jsou SafeDep a Corgea .

Poučení pro linuxový ekosystém

Útok Atomic Arch odhaluje strukturální slabiny v komunitních repozitářích založených na důvěře, které se spoléhají na dobrovolnou údržbu.

• Past v podobě opuštěných balíčků je systémové riziko: Schopnost jakéhokoli uživatele okamžitě převzít a upravit opuštěný balíček bez ověření identity nebo povinné kontroly kódu proměnila užitečnou funkci ve vysoce účinný vektor útoku .
• Injektáž v době sestavení obchází kontroly integrity: Tradiční obranné mechanismy spoléhají na ověření integrity zdrojových kódů (tarballů). Protože Atomic Arch "otrávil" build skripty namísto zdrojového kódu, standardní kontrolní součty neposkytly žádnou ochranu .
• Dodavatelský řetězec napříč ekosystémy je novou hranicí: Útok použil registry npm a Bun jako zbraň k distribuci malwaru do linuxového ekosystému, což dokazuje, že jediný kompromitovaný balíček v jednom registru může mít kaskádové účinky napříč platformami .

Co musí zasažení uživatelé udělat nyní

Bezpečnostní výzkumníci a pokyny komunity Archu jsou jednotné: toto není případ, kdy stačí odstranit jediný balíček.

1. Předpokládejte úplnou kompromitaci: Považujte jakýkoli počítač, který sestavil nebo aktualizoval AUR balíček mezi 9. a 12. červnem 2026, za zcela kompromitovaný .
2. Přeinstalujte z čistého média: Jednoduchá kontrola malwarem je nespolehlivá, protože eBPF rootkit je navržen tak, aby se před detekčními nástroji skrýval. Jedinou zaručenou nápravou je přebudování postiženého systému z důvěryhodného instalačního média .
3. Okamžitě změňte všechny přístupové údaje: Předpokládejte, že nástroj pro krádež přihlašovacích údajů exfiltroval všechna tajemství přístupná na počítači: SSH klíče, tokeny GitHub a npm, Vault tokeny, cloudové přístupové klíče, relace prohlížeče a přihlašovací údaje pro Docker/Podman .
4. Auditujte historii AUR: Spusťte příkaz

   pacman -Qm

   pro výpis všech cizích balíčků nainstalovaných v systému a porovnejte je s komunitou zveřejněnými seznamy škodlivých balíčků .
5. Zkontrolujte indikátory kompromitace: Hledejte stopy atomic-lockfile, lockfile-js nebo js-digest v build vyrovnávacích pamětech, stejně jako podezřelé položky v /sys/fs/bpf/ .
6. Považujte to za událost reakce na incident: Organizace by to neměly brát jako jednoduché prověření. Jakákoli vývojářská pracovní stanice s Archem nebo CI/build server, který stahoval z AUR během okna útoku, by měl být považován za bezpečnostní incident vyžadující plnou reakci .