Atomic Aur
Chi utilizza Arch Linux da qualche anno conosce bene il valore dell’AUR. È uno degli elementi che rendono l’ecosistema Arch così flessibile: migliaia di pacchetti mantenuti dalla comunità, software non presente nei repository ufficiali e la possibilità di installare praticamente qualsiasi cosa con pochi comandi.
Ma proprio questa fiducia distribuita è stata recentemente messa alla prova da uno degli attacchi alla supply chain più significativi che abbiano colpito l’ecosistema Arch Linux.
Atomic Arch: cosa è successo
Nei primi giorni di giugno 2026 diversi ricercatori di sicurezza hanno individuato una campagna malevola che ha preso di mira l’Arch User Repository (AUR). Gli attaccanti hanno sfruttato un meccanismo legittimo dell’AUR: l’adozione dei pacchetti abbandonati (orphan packages).
In pratica, quando un manutentore smette di seguire un pacchetto, altri utenti possono richiederne la gestione. Un processo utile per mantenere vivo l’ecosistema, ma che in questo caso è stato sfruttato per acquisire il controllo di numerosi pacchetti esistenti e considerati affidabili.
Una volta ottenuto il controllo, gli aggressori hanno modificato i file PKGBUILD inserendo istruzioni che scaricavano una dipendenza esterna chiamata atomic-lockfile tramite npm durante l’installazione del pacchetto.
Il codice malevolo non era quindi presente direttamente nel pacchetto AUR, ma veniva recuperato dinamicamente durante il processo di build. Una tecnica che rende molto più difficile individuare il problema con una semplice occhiata al sorgente.
Perché questo attacco è interessante
Dal punto di vista tecnico non è stato compromesso Arch Linux.
Non sono stati violati i repository ufficiali, né l’infrastruttura della distribuzione. È stata invece sfruttata una caratteristica sociale e organizzativa dell’ecosistema open source: la fiducia.
L’attaccante non ha creato un nuovo pacchetto sospetto. Ha ereditato la reputazione di pacchetti già esistenti e utilizzati da altri utenti. Come osservato dai ricercatori di Sonatype:
Gli attaccanti non hanno costruito la fiducia. L’hanno ereditata.
È una dinamica che abbiamo già visto nel mondo npm, PyPI e persino nei repository GitHub: un progetto abbandonato può diventare una porta d’ingresso molto interessante.
Cosa faceva il malware
Le analisi preliminari indicano che il payload era orientato al furto di credenziali e informazioni sensibili. Tra gli obiettivi individuati figurano:
- chiavi SSH;
- token GitHub;
- credenziali npm;
- cookie e sessioni browser;
- dati provenienti da applicazioni come Slack, Discord e Teams;
- segreti utilizzati nei processi CI/CD.
In alcuni casi il malware era anche in grado di installare un rootkit basato su eBPF per aumentare le capacità di persistenza e occultamento.
Non si tratta quindi del classico malware “rumoroso”, ma di qualcosa progettato per colpire sviluppatori, amministratori di sistema e infrastrutture di build.
La lezione più importante
L’aspetto che mi ha colpito maggiormente non è la tecnica utilizzata, ma quanto facilmente molti di noi abbiano normalizzato l’utilizzo dell’AUR.
Strumenti come yay o paru hanno reso l’esperienza quasi indistinguibile da quella dei repository ufficiali:
yay -S nome-pacchetto
Un comando, pochi secondi di attesa e il software è installato.
La comodità però rischia di farci dimenticare una differenza fondamentale:
i pacchetti AUR non sono pacchetti ufficiali.
Quando installiamo da AUR stiamo eseguendo script scritti e mantenuti da terzi. Nella maggior parte dei casi il processo è sicuro grazie al lavoro della comunità, ma richiede comunque un livello minimo di verifica e consapevolezza.
Come difendersi
Non esiste una soluzione perfetta, ma alcune buone pratiche possono ridurre significativamente il rischio:
Leggere i PKGBUILD
Sembra banale, ma spesso non lo facciamo più.
Un rapido controllo delle modifiche introdotte può evidenziare dipendenze sospette, download esterni o script inattesi.
Preferire i repository ufficiali
Se un pacchetto è disponibile nei repository ufficiali, è generalmente la scelta più sicura.
Controllare i manutentori
Per i pacchetti meno diffusi può essere utile verificare chi li mantiene e se il progetto è ancora attivamente seguito.
Prestare attenzione agli aggiornamenti inattesi
Un pacchetto fermo da anni che improvvisamente riceve modifiche sostanziali merita sempre qualche verifica aggiuntiva.
Conclusioni
L’incidente Atomic Arch non è un problema esclusivo di Arch Linux.
È l’ennesima dimostrazione di come la sicurezza moderna non riguardi soltanto vulnerabilità software o bug di programmazione, ma anche processi, governance e fiducia.
L’open source continua a essere uno dei modelli più efficaci per costruire software di qualità. Tuttavia, più cresce la nostra dipendenza dalle catene di distribuzione automatizzate, più diventa importante ricordare che ogni dipendenza aggiunta, ogni script eseguito e ogni pacchetto installato rappresentano un anello della supply chain.
E come spesso accade, la sicurezza dell’intera catena dipende dall’anello più debole.
Le opinioni in quanto tali sono opinabili e nulla ti vieta di approfondire l’argomento.
Risorse: