Attacco "Atomic Arch": 408 pacchetti AUR compromessi con rootkit eBPF e infostealer (aggiornato: 12 giugno 2026, ore 20:25)

Oltre quattrocento pacchetti compromessi, un infostealer, un rootkit eBPF e una catena di fiducia spezzata nel punto più fragile. L'attacco che ha colpito l'Arch User Repository - il vasto archivio di pacchetti gestito dalla comunità di Arch Linux - non è un semplice incidente di sicurezza. È la dimostrazione plastica di un rischio sistemico che la comunità Linux conosce da sempre ma ha sempre trattato con una scrollata di spalle: l'AUR non è sottoposto a revisione formale, e chiunque può adottare un pacchetto abbandonato. Basta avere un account. I ricercatori di Sonatype hanno battezzato la campagna «Atomic Arch», e i numeri suggeriscono che si tratti dell'attacco più esteso nella storia dell'AUR.

Come funziona l'attacco: pacchetti orfani e fiducia ereditata

Il meccanismo è tanto semplice quanto efficace. L'AUR consente a qualsiasi utente registrato di adottare un pacchetto marcato come non mantenuto - i cosiddetti pacchetti orfani - e gli aggressori hanno sfruttato esattamente questa politica, prendendo il controllo di centinaia di progetti legittimi ma abbandonati. Automatizzare la ricerca di pacchetti orfani, peraltro, non è nemmeno un'operazione insolita nell'ecosistema AUR: esistono script e strumenti noti per farlo.

Una volta ottenuta la proprietà, il passo successivo era chirurgico. I file PKGBUILD - gli script di compilazione che definiscono come un pacchetto viene costruito e installato - venivano modificati per introdurre uno script di post-installazione. Lo script eseguiva un comando apparentemente innocuo: npm install atomic-lockfile minimist chalk. Con questa singola riga, il sistema della vittima scaricava e installava il pacchetto npm malevolo atomic-lockfile, mantenuto su npm dall'utente herbsobering. Una ricerca su GitHub associata a quello stesso nome utente rivela un'unica immagine container descritta come strumento per reverse shell e proxy. Nessuna ambiguità sulle intenzioni.

Il codice malevolo non risiede nel pacchetto AUR in sé: viene recuperato a valle, tramite una dipendenza npm. Questo approccio indiretto è particolarmente insidioso perché elude gli strumenti di rilevamento tradizionali, che tipicamente analizzano il contenuto del pacchetto al momento dell'installazione ma non le dipendenze scaricate dinamicamente da registri esterni.

Esiste anche una seconda variante. Gli aggressori utilizzavano Bun - un runtime JavaScript alternativo - per installare un pacchetto chiamato js-digest, successivamente rimosso da npm grazie all'intervento di Socket.dev. L'hash SHA256 dell'eseguibile Linux malevolo incorporato in js-digest è stato pubblicato per consentire la verifica: 7883bda1ff15425f2dbe622c45a3ae105ddfa6175009bbf0b0cad9bf5c79b316.

Il carico malevolo: non solo furto di credenziali

Ciò che distingue Atomic Arch da un attacco di supply chain «ordinario» è la profondità del carico malevolo. Secondo l'analisi di Sonatype, il payload Linux incorporato in atomic-lockfile è progettato per raccolta di credenziali, tecniche di occultamento, meccanismi anti-debug e potenziale esfiltrazione di dati. Un infostealer completo, con funzionalità da keylogger.

Ma il vero salto di qualità è altrove. L'attacco distribuisce anche un rootkit basato su eBPF - una tecnica che permette di agganciare codice direttamente a livello kernel sfruttando il sottosistema eBPF di Linux. In un attacco di supply chain di questa natura, arrivare a distribuire un rootkit è un'escalation rara. Un rootkit eBPF può intercettare chiamate di sistema, nascondere processi e connessioni di rete, e rendere sostanzialmente inaffidabile qualsiasi strumento di diagnostica eseguito sul sistema compromesso - il che pone un problema metodologico non da poco per chi cerca di capire cosa sia successo sulla propria macchina.

Sonatype ha assegnato all'incidente l'identificativo Sonatype-2026-003775 con un punteggio CVSS di 8.7, classificandolo come ad alta gravità. L'analisi è stata condotta dal ricercatore Adam Reynolds, dopo che l'ingegnere Eyad Hasan aveva inizialmente segnalato l'attività sospetta.

408 pacchetti, o forse di più

Sul numero esatto di pacchetti compromessi esiste una discrepanza tra le fonti. Le prime segnalazioni di Sonatype parlavano di «oltre 20 pacchetti AUR», con la precisazione che il conteggio sarebbe cresciuto man mano che i pacchetti orfani venivano sottoposti a verifica. Report successivi - aggiornati al 12 giugno 2026 - indicano oltre 408 pacchetti coinvolti. La differenza riflette probabilmente la rapidità con cui la portata dell'attacco si è rivelata nelle ore successive alla scoperta; l'attacco è descritto come ancora in corso, con indicatori di compromissione in evoluzione.

Una precisazione sull'attribuzione: una versione iniziale di uno dei report indicava che un account di un manutentore noto fosse responsabile dell'iniezione del codice. Quella informazione si è rivelata inesatta. L'account era stato falsificato - un nuovo utente aveva impersonato un manutentore di fiducia per adottare i pacchetti e infettarli. L'aggressore non ha dovuto costruire credibilità da zero: l'ha semplicemente ereditata acquisendo progetti con una storia e una reputazione consolidata.

La vulnerabilità strutturale dell'AUR

Per chi non ha familiarità con l'ecosistema di Arch Linux, una distinzione è d'obbligo. I repository ufficiali di Arch Linux - quelli gestiti dai Trusted User e dal team di sviluppo - non sono stati coinvolti. L'AUR è un'entità completamente separata: un archivio di script PKGBUILD caricati e gestiti dalla comunità, privo di qualsiasi processo formale di revisione del codice prima della pubblicazione.

Questa architettura è una scelta deliberata. L'AUR esiste per dare agli utenti la massima libertà di condividere e distribuire software non presente nei repository ufficiali, e il compromesso è esplicito: chi usa l'AUR accetta la responsabilità di esaminare ogni PKGBUILD prima di installarlo. Il wiki di Arch lo ripete da anni.

Il problema è che nella pratica quasi nessuno lo fa. Strumenti come yay, paru e altri AUR helper hanno reso l'installazione di pacchetti AUR un'operazione in un solo comando, indistinguibile - dal punto di vista dell'esperienza utente - dall'installazione di un pacchetto ufficiale con pacman. La comodità ha eroso la cautela. Quando un aggressore modifica un PKGBUILD per aggiungere una sola riga di codice che scarica una dipendenza esterna, anche un utente esperto che dà un'occhiata superficiale allo script potrebbe non notare nulla di anomalo.

Atomic Arch sfrutta un pattern strutturale analogo alla compromissione del pacchetto npm axios, in cui gli aggressori avevano aggiunto una dipendenza malevola (plain-crypto-js@4.2.1) a un progetto legittimo. L'uso di uno script di preinstallazione per eseguire un binario incorporato ricorda anche la campagna nota come IronWorm, che coinvolgeva il pacchetto atomic-notes, sebbene non sia confermata alcuna relazione tra le due operazioni.

La risposta della comunità e le azioni di mitigazione

Il lavoro di contenimento è iniziato l'11 giugno e prosegue. Il packager di Arch Jonathan Grotelüschen ha confermato che gli interventi per «ripristinare o eliminare tutti i commit malevoli e bannare gli account responsabili» sono in corso. La mailing list dell'AUR è stata utilizzata per identificare ulteriori pacchetti compromessi con profili di malware differenti rispetto alla variante principale.

Sul fronte npm, Socket.dev ha rimosso il pacchetto js-digest e mantiene un'analisi pubblica del pacchetto atomic-lockfile. Quest'ultimo ha registrato 134 download - un numero che può sembrare modesto, ma in un contesto dove ogni download corrisponde a un sistema potenzialmente compromesso a livello kernel, è tutt'altro che trascurabile.

Cosa fare se si utilizza l'AUR

Le indicazioni per gli utenti Arch sono nette. Chi ha installato pacchetti dall'AUR negli ultimi giorni deve consultare la lista dei pacchetti coinvolti ed eseguire lo script di verifica aur_check.sh, disponibile su GitHub. Se il sistema risulta compromesso, la raccomandazione è drastica ma logica: ruotare tutte le credenziali e considerare una reinstallazione completa di Arch Linux. La presenza di un rootkit eBPF significa che il sistema operativo stesso non è più affidabile - qualsiasi strumento di analisi eseguito sulla macchina compromessa potrebbe restituire risultati falsati.

Sonatype è ancora più esplicita: i sistemi colpiti vanno trattati come completamente compromessi. La sola rimozione del pacchetto non è sufficiente se il payload di secondo stadio ha già avuto modo di eseguirsi. Il blog di Ioctl pubblica gli indicatori di compromissione; se vengono riscontrati, il consiglio è di preservare il sistema per un'indagine forense prima di procedere alla reinstallazione.

Chi non utilizza Arch Linux non è coinvolto dall'attacco. La lezione, però, vale per tutto l'ecosistema del software open source: i repository comunitari non verificati, indipendentemente dalla distribuzione, rappresentano una superficie di attacco significativa. L'AUR è un caso estremo per la sua apertura architettonica, ma il pattern - adottare progetti abbandonati per iniettare codice malevolo - è replicabile ovunque esistano meccanismi analoghi di trasferimento della proprietà di un pacchetto. La comodità degli strumenti automatici non cancella la necessità di verificare ciò che si installa. Semmai, la rende ancora più urgente.

Fonti: phoronix.com, reddit.com, sonatype.com