Un attacco alla supply chain ha preso di mira i repository AUR di Arch Linux. Le stime iniziali parlavano di circa 400 pacchetti compromessi, poi saliti a 900, fino ad arrivare a oltre 1.579 pacchetti secondo la lista pubblicata dagli sviluppatori stessi e si tratta di una lista parziale, ma comunque, sappiamo che non è di certo la prima volta che un attacco alla supply chain colpisce i repository di Arch.

La campagna è stata battezzata “Atomic Arch” dai ricercatori di Sonatype, che l’hanno definita uno degli attacchi più estesi mai registrati contro l’AUR.

Per chi non lo sapesse già, l’Arch User Repository è una raccolta di pacchetti non ufficiali mantenuti dalla community. Lo stesso Arch Wiki avverte esplicitamente che i pacchetti non vengono sottoposti a una verifica completa e che il loro utilizzo è a rischio dell’utente. Questa caratteristica strutturale lo rende un vettore di attacco particolarmente interessante. Non stiamo parlando di un attacco che compromette i pacchetti ufficiali di Arch, ma è comunque una suite di pacchetti che chiunque usa questa distribuzione ha utilizzato almeno una volta grazie alla vastità del software disponibile.

Gli attaccanti hanno sfruttato il processo con cui i membri della community possono richiedere la gestione di pacchetti abbandonati dai loro maintainer originali (pacchetti orfani). Una volta ottenuto il controllo, il pacchetto mantiene nome, storico e reputazione e cambia solo chi ne gestisce le istruzioni di build.
Il punto critico è proprio questo: gli attaccanti non hanno modificato i pacchetti in sé, ma i loro PKGBUILD, ovvero i file che descrivono come il pacchetto viene compilato e installato. Questo ha permesso di aggirare i metodi tradizionali di rilevamento del malware basati sull’analisi dei binari. Un esempio preso direttamente dai commit compromessi è mostrato nello screenshot seguente, dove tramite post_install() si inietta del codice:

Il package maintainer Campbell Jones afferma, con un post rilasciato direttamente nelle news di Arch Linux:

We are currently experiencing a high volume of malicious package adoptions and updates in the Arch User Repository. We are actively working to track down existing malicious commits and attempting to prevent additional malicious commits from being pushed.

Al momento stiamo riscontrando un elevato numero di installazioni e aggiornamenti di pacchetti dannosi nell’Arch User Repository.
Stiamo lavorando attivamente per individuare i commit dannosi esistenti e cercare di impedire che ne vengano inviati altri.

Una volta eseguito, il malware che colpisce i pacchetti effettua recon sul filesystem e stabilisce connessioni di rete. I ricercatori hanno individuato riferimenti espliciti a:

• chiavi SSH
• database dei cookie del browser
• storage di dati di applicazioni come Discord, Slack e Telegram

Tutti indicatori chiari di un’operazione di credential stealing e data exfiltration.

Tra i pacchetti colpiti figurano componenti Node.js, applet per Plasma 6, pacchetti Firefox, il browser Aura, estensioni per LibreWolf e plugin per NeoVim.

Il giorno successivo alla pubblicazione della lista dei pacchetti compromessi, il developer a821 ha segnalato una seconda ondata di pacchetti infetti, questa volta con tecniche di offuscamento più elaborate rispetto alla prima. Poco dopo, Nicolas Boichat ha identificato ulteriori pacchetti malevoli, in questo caso utilizzando un modello AI locale (Gemma) per analizzare il codice sospetto.

Alcuni utenti della community di Arch, per difendersi, hanno creato dei gist per controllare se il proprio sistema è compromesso. Per fare un rapido check sul proprio sistema basta scaricare gli script bash ed eseguirli.

bash aur_check.sh

Al momento della stesura di questo articolo il problema risulta formalmente risolto: gli sviluppatori di Arch Linux hanno dichiarato di aver rimosso tutti i commit malevoli di cui erano a conoscenza. I pacchetti attualmente presenti nell’AUR non dovrebbero essere più compromessi.

Rimane però aperta la questione strutturale: il processo di adozione dei pacchetti orfani è ancora troppo poco controllato (almeno su Arch), e questo attacco ne ha dimostrato concretamente i limiti. Il 2026 si sta poi confermando un anno particolarmente difficile sul fronte della sicurezza alla supply chain, con attacchi che colpiscono sempre più spesso repository di pacchetti e infrastrutture di sviluppo, come abbiamo già visto in occasione della compromissione di Trivy, Checkmarx e LiteLLM e del recente attacco ai repository ufficiali GitHub.