Atomic Arch: 1.500 pacchetti AUR dirottati, developer e CI nel…

L'operazione Atomic Arch ha sottratto oltre 1.500 pacchetti AUR a repository orfani per diffondere un infostealer Rust con rootkit eBPF. Ecco come funziona

Il 11 giugno 2026, i ricercatori di Sonatype hanno reso pubblica l'operazione Atomic Arch: una campagna di supply-chain attack che ha dirottato oltre 400 pacchetti del Arch User Repository (AUR) per iniettare via PKGBUILD un pacchetto npm malevolo, atomic-lockfile. Entro il 12 giugno, i responsabili avevano già innescato una seconda ondata, estendendo la superficie di attacco a circa 1.500 pacchetti e introducendo installazioni basate su Bun. Il cuore del problema non è una vulnerabilità software tradizionale, ma un difettuoso meccanismo di trasferimento della proprietà che premia la storia su chi detiene effettivamente il pacchetto.

Punti chiave

Gli attaccanti hanno sfruttato il meccanismo di ownership transfer dei pacchetti orfani nell'AUR per ereditarne nome, cronologia e reputazione
Il payload principale è un infostealer scritto in Rust che ruba chiavi SSH, token GitHub, credenziali npm, API key cloud e sessioni browser
Un componente opzionale basato su eBPF assicura persistenza e occultamento di processi, file e socket inode quando l'esecuzione avviene con privilegi di root
La seconda ondata, emersa il 12 giugno 2026, ha introdotto pacchetti js-digest e lockfile-js con installazione via Bun, portando il totale stimato a circa 1.500 pacchetti

Come si eredita un pacchetto e perché è letale

L'AUR, repository gestito dalla comunità di Arch Linux, permette a chiunque di "adottare" pacchetti abbandonati. Il meccanismo è semplice: si richiede il trasferimento della proprietà, e la nuova identità eredita non solo il nome ma l'intera cronologia di download, le recensioni accumulate, la visibilità nei motori di ricerca. I responsabili di Atomic Arch hanno capito che questa ereditarietà di fiducia batte il typosquatting: non serve ingannare con nomi simili, basta appropriarsi di quelli autentici.

Secondo l'analisi di StepSecurity, "if a maintainer abandons a package, another user can request to adopt it, inheriting the package name and its reputation". I ricercatori di The Hacker News hanno rilevato un affinamento ulteriore: gli attaccanti hanno contraffatto i metadati dei commit git per far apparire le modifiche come provenienti da un manutentore storico. Un Trusted User di Arch Linux ha poi confermato che quell'account non era stato compromesso: la falsificazione era puramente cosmetica, ma sufficiente a ritardare il rilevamento.

I pacchetti confermati come compromessi includono alvr e premake-git, entrambi con storicità significativa nell'ecosistema. La comunità ha successivamente identificato 408 pacchetti contaminati tramite grep su mirror git dell'AUR, sebbene il conteggio esatto resti in evoluzione.

Dal PKGBUILD al rootkit: la catena tecnica

Il meccanismo di consegna passa attraverso la modifica degli script PKGBUILD, i file di build che AUR esegue localmente sulle macchine degli utenti. Questi script contengono istruzioni per scaricare dipendenze, compilare sorgenti, installare componenti. Gli attaccanti vi hanno inserito la direttiva npm install atomic-lockfile (o varianti successive), ponte verso il payload effettivo.

Il pacchetto npm atomic-lockfile@1.4.2, analizzato in reverse engineering dal ricercatore indipendente noto come Whanos, contiene un hook preinstall che esegue un binario ELF Linux denominato deps. Questo è l'infostealer Rust vero e proprio. Secondo Sonatype, la campagna è tracciata internamente come Sonatype-2026-003775, con un punteggio CVSS di 8.7. Non è stato assegnato un identificatore CVE pubblico.

L'esfiltrazione dei dati rubati avviene in due fasi: upload iniziale via HTTP verso temp.sh, poi comunicazione con un server C2 raggiungibile tramite servizio onion Tor, con proxy locale su loopback. I dati presi di mira includono chiavi SSH, token GitHub, token npm, API key di servizi cloud, credenziali Docker/Podman e sessioni browser. Questa profilazione è esplicitamente orientata a macchine developer e runner CI/CD.

Quando il payload ottiene esecuzione come root, attiva un componente aggiuntivo basato su eBPF. Il rootkit utilizza pinned BPF maps con nomi specifici — hidden_pids, hidden_names, hidden_inodes — per mascherare processi, attività su file e inode di socket. La persistenza meccanica è affidata a un servizio systemd con direttiva Restart=always.

"Ownership hijacking beats typosquatting. Instead of publishing lookalike packages, the attackers targeted abandoned but trusted packages, inheriting users and reputation in one move." — StepSecurity analysis

La seconda ondata e la chiusura dell'AUR

La velocità di adattamento dei responsabili ha sorpreso gli analisti. Entro il 12 giugno 2026, emergono segnalazioni di una seconda ondata che sostituisce il percorso di installazione npm con bun install js-digest, sfruttando l'alternativa runtime JavaScript Bun per aggirare eventuali filtri sui pacchetti npm. SecurityWeek e Sonatype documentano anche l'uso di lockfile-js come variante di denominazione. Il totale stimato di pacchetti compromessi sale così a circa 1.500, contro i 400+ inizialmente segnalati da StepSecurity e The Hacker News.

La risposta di Arch Linux è stata la sospensione delle nuove registrazioni di account AUR, misura tesa a contenere ulteriori adozioni fraudolente durante le operazioni di pulizia. Non risultano, dalle fonti disponibili, pacchetti nei repository ufficiali di Arch Linux compromessi: l'attacco si è limitato all'AUR.

Il pattern cross-ecosistema: fiducia ereditata, non verificata

L'architettura di Atomic Arch non è circoscritta ad Arch Linux. Il problema fondamentale — la trasferibilità della proprietà che conserva la fiducia storica — si replica in Homebrew (tap e formula abandonment), npm (package transfer e maintainership), PyPI (PEP 541 transfer requests) e GitHub Actions (marketplace action versioning e maintainer change). In ogni caso, un cambio di guardia silenzioso può trasformare un artefatto legittimo in vettore di attacco senza alterarne l'identità apparente.

Il dossier non quantifica il numero di macchine effettivamente compromesse, né identifica gli operatori della campagna. Rimangono aperti anche il ruolo di un file monero-wallet-gui rilevato in alcune istanze — funzionale o di disturbo — e la durata complessiva dell'operazione prima della disclosure.

Cosa fare adesso

Le seguenti azioni emergono direttamente dalle indicazioni fornite dalle fonti:

Ricostruire da media puliti qualsiasi host che abbia eseguito build da pacchetti AUR nel periodo di attività della campagna: la persistenza eBPF e systemd rende insufficiente una semplice scansione malware
Ruotare tutte le credenziali esposte su macchine developer o runner CI, comprese chiavi SSH, token GitHub, token npm e API key cloud
Verificare l'installazione di pacchetti Bun come js-digest o varianti lockfile-js come percorso di compromissione secondario
Rivalutare le policy di adozione nei repository gestiti dalla comunità, richiedendo periodi di osservazione o verifica identitaria prima del trasferimento della proprietà di pacchetti con storicità significativa

La lezione che non riguarda solo Arch

Atomic Arch dimostra che la supply-chain non inizia con il codice sorgente, ma con il sistema che ne regola la custodia. L'attacco non ha sfruttato buffer overflow né logic flaw: ha sfruttato la supposizione, radicata in ogni ecosistema di packaging, che chi possiede un nome ne meriti la fiducia. Finché i meccanismi di trasferimento manterranno questa ereditarietà incondizionata, il pattern di Atomic Arch resterà riproducibile — su qualunque piattaforma consenta a un nuovo arrivato di indossare l'abito di un predecéssore.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti