Attacco coordinato alla supply chain colpisce i popolari crate Rust con malware in fase di build
Punti chiave
- •Le versioni dannose dei crate Rust arrayref, internment e append-only-vec sono state modificate per dipendere da proc-macro1, un typosquat di proc-macro2 che eseguiva malware durante le build di Cargo.
- •L'implant multipiattaforma ha infettato sistemi Linux, macOS e Windows, raccogliendo dettagli di sistema e dati di navigazione da Chromium mentre stabiliva persistenza e comunicazione di command-and-control.
- •Il Rust Security Response Team ha rimosso le release contagiate e bloccato l'account del maintainer, concludendo che la macchina dello sviluppatore o le credenziali di pubblicazione erano probabilmente state compromesse, piuttosto che il maintainer avesse agito con intento doloso.
- •arrayref aveva accumulato circa 152 milioni di download e compare in alberi di dipendenze che includono componenti legati a Solana, creando una vasta superficie d'attacco su macchine degli sviluppatori e infrastrutture CI/CD.
- •Poiché Cargo scarta le versioni ritirate (yanked) nel calcolo di nuovi alberi di dipendenze ma onora le versioni già registrate nei file Cargo.lock, l'esposizione effettiva dipende dal lockfile bloccato di ciascun progetto.

Il 20 agosto 2026 ricercatori di sicurezza hanno individuato un attacco coordinato alla supply chain contro tre crate Rust ampiamente utilizzati pubblicati su crates.io. I pacchetti compromessi—arrayref versione 0.3.10, internment 0.8.7 e append-only-vec 0.1.9—sono stati alterati per includere una dipendenza dannosa che eseguiva codice remoto durante la compilazione standard. Il Rust Security Response Team ha prontamente rimosso le release interessate e bloccato l'account del maintainer, dichiarando che la macchina dello sviluppatore legittimo o le sue credenziali di pubblicazione erano probabilmente state compromesse, piuttosto che trattarsi di un'azione dolosa da parte del maintainer.
La dipendenza typosquat ha consegnato il payload
L'attacco ha sfruttato un crate typosquat denominato proc-macro1, che impersonava la libreria legittima proc-macro2. Quando Cargo risolveva la dipendenza, eseguiva automaticamente uno script di build dannoso che ricostruiva gli indirizzi di command-and-control a partire da dati offuscati in Base64, disabilitava la verifica TLS e scaricava un payload specifico per piattaforma da un server controllato dagli attaccanti. Poiché la compromissione avveniva in fase di build, la semplice compilazione di un progetto che dipendeva in modo transitivo da uno dei crate dannosi poteva infettare una workstation di sviluppo o un host di integrazione continua, anche se il codice dell'applicazione non ha mai invocato direttamente alcuna funzione sospetta.
L'impersonazione ha preso di mira uno dei componenti più ubiqui di Rust—proc-macro2 è alla base della gestione delle macro per una larga quota dei crate pubblicati—and i registry come crates.io, npm e PyPI assegnano i nomi dei pacchetti secondo il criterio «primo arrivato, primo servito», una politica che da tempo rende il typosquatting una tecnica di supply chain privilegiata negli ecosistemi dei linguaggi.
Comportamento della backdoor multipiattaforma
Il malware operava su Linux, macOS e Windows. Su Linux e macOS depositava un eseguibile nelle directory temporanee e lo avviava come processo separato (detached). Su Windows impiegava script PowerShell e Visual Basic per aggirare i criteri di esecuzione ed eseguire processi nascosti. La backdoor di secondo stage profilava quindi il sistema infetto, raccogliendo nomi utente, nomi host, applicazioni installate e dati di navigazione dai browser basati su Chromium. Stabiliva una persistenza a livello utente tramite run key del registro, servizi utente systemd o LaunchAgents di macOS, manteneva la comunicazione con un endpoint di command-and-control e supportava istruzioni remote per ulteriori esecuzioni e modifiche di configurazione.
La società di sicurezza Socket ha documentato la compromissione su X:
Popular Rust crates compromised: Affected versions of arrayref, internment, and append-only-vec were modified to depend on proc-macro1, a malicious typosquat of proc-macro2. Its build script downloaded and executed malware during Cargo builds. Analysis:
— Socket (@SocketSecurity), August 20, 2026
Esposizione più ampia dell'ecosistema e rimedi
L'incidente ha implicazioni significative per l'ecosistema Rust e per l'infrastruttura blockchain adiacente. Solo arrayref aveva accumulato circa 152 milioni di download prima della compromissione e si trova all'interno di alberi di dipendenze che includono componenti legati a Solana e diffusi framework di interfaccia grafica. Sebbene i progetti a valle non fossero automaticamente compromessi, a meno che non risolvessero e compilassero esplicitamente le versioni dannose, l'ampio uso transitivo del crate crea una vasta superficie d'attacco che comprende ambienti di sviluppo, pipeline CI/CD e infrastrutture di release automatizzate che spesso ospitano token sensibili e materiale di firma.
L'episodio arriva inoltre nel bel mezzo di un'onda più ampia di compromissioni di registry. Nell'agosto 2025 una campagna tracciata come rk0x ha utilizzato credenziali di maintainer rubate per pubblicare versioni infette di malware di crate Rust popolari, raccogliendo credenziali dei browser e wallet di criptovalute, mentre npm e PyPI hanno più volte subito campagne di typosquatting e account takeover. La backdoor XZ Utils del marzo 2024 ha parimenti mostrato come una singola libreria open source ampiamente utilizzata possa diventare un punto di strozzatura che raggiunge un numero enorme di sistemi a valle.
Gli investigatori hanno individuato ulteriori crate di staging controllati dagli attaccanti—proc-macro-en, aovine, arone, aronenao e tinymember—successivamente rimossi dal registry. Il threat actor ha inoltre ritirato (yanked) le versioni legittime precedenti di arrayref, potenzialmente orientando la risoluzione delle dipendenze verso la release dannosa prima dell'intervento degli amministratori. Secondo le regole di risoluzione di Cargo, le versioni ritirate (yanked) vengono scartate nel calcolo di nuovi alberi di dipendenze, ma le versioni già registrate in un Cargo.lock continuano a essere compilate, quindi l'esposizione effettiva dipende dai lockfile bloccati e non solo dallo stato del registry.
Alle organizzazioni si consiglia di verificare i file Cargo.lock, gli inventari delle dipendenze e i log di build alla ricerca delle versioni interessate e di indicatori correlati. Qualsiasi sistema che abbia compilato una delle release dannose deve essere considerato potenzialmente compromesso, il che richiede la rotazione dei segreti accessibili all'ambiente di build, la caccia forense agli artefatti di rete e host noti e la ricompilazione del software da ambienti puliti e verificati. I difensori dovrebbero inoltre monitorare le connessioni all'infrastruttura di command-and-control identificata e gli output dell'algoritmo deterministico di generazione dei domini associati all'implant. Gli strumenti dell'ecosistema supportano questo triage: cargo tree elenca le dipendenze transitive da esaminare, mentre il database di advisory RustSec, consultabile tramite cargo audit, cataloga le versioni dei crate note come vulnerabili.
Fonte: Metaverse Post