Tre crate Rust compromessi distribuiscono malware durante la compilazione

Tre release malevole rimosse da crates.io

Il progetto Rust ha rimosso da crates.io tre versioni compromesse di crate ampiamente utilizzati: arrayref 0.3.10, internment 0.8.7 e append-only-vec 0.1.9.

Le release sono state pubblicate il 20 agosto 2026 dallo stesso account proprietario e sono rimaste disponibili tra 86 e 107 minuti:

• arrayref 0.3.10: dalle 07:15:00Z alle 08:41:40Z;
• internment 0.8.7: dalle 07:34:07Z alle 09:04:11Z;
• append-only-vec 0.1.9: dalle 07:37:49Z alle 09:25:24Z.

Il Rust Security Response Team ha ricevuto la prima segnalazione alle 07:15 UTC, dopo la scoperta di un crate malevolo denominato proc-macro1. Il nome imita quello legittimo proc-macro2, una tecnica di typosquatting pensata per passare inosservata nei manifest delle dipendenze.

Sono inoltre considerate compromesse, in qualunque versione, proc-macro1, proc-macro-en, aovine, arone, aronenao e tinymember.

Non è stato assegnato alcun identificativo CVE. Le advisory RustSec non riportano evidenze di utilizzo effettivo delle versioni malevole. Non è indicata neppure la presenza dell’incidente nel catalogo KEV della CISA.

L’attacco partiva da una normale compilazione Cargo

Il problema non richiedeva di usare una specifica funzione dei crate compromessi. Era sufficiente eseguire cargo build, cargo check o cargo test su un progetto che risolvesse la dipendenza alterata.

Il manifest delle release includeva una riga aggiuntiva per introdurre proc-macro1. Il crate contraffatto conteneva il codice sorgente autentico di proc-macro2, così da mantenere un comportamento apparentemente normale. L’elemento malevolo era un build script eseguito automaticamente durante la compilazione.

Lo script ricostruiva da frammenti codificati in Base64 l’indirizzo del server di comando e controllo e quello utilizzato per scaricare il payload. Installava inoltre un verificatore TLS personalizzato le cui tre funzioni di validazione restituivano sempre un esito positivo. In pratica, il controllo dei certificati veniva disattivato.

Il codice sceglieva poi uno tra quattro payload in base al sistema operativo e all’architettura del processore. Su Unix e macOS il file veniva scritto in /tmp/rust-setup, reso eseguibile e avviato in background, con l’indirizzo C2 passato come primo argomento.

Su Windows venivano creati due file nella directory temporanea dell’utente:

• %TEMP%\rust-setup.ps1;
• %TEMP%\rust-setup-launch.vbs.

Il secondo veniva eseguito tramite wscript.exe in modalità nascosta. Il processo figlio veniva quindi separato dal job object di Cargo, impedendo alla compilazione di attenderne la terminazione.

Il risultato è una catena di attacco inserita nella fase di build, prima ancora che l’applicazione venga eseguita. È una differenza sostanziale rispetto a un malware attivato soltanto dal comportamento runtime del programma.

Il ritiro delle versioni precedenti ha favorito la distribuzione

La pubblicazione di arrayref 0.3.10 è stata accompagnata, nello stesso minuto, dal ritiro delle versioni legittime dalla 0.3.5 alla 0.3.9. In questo modo la release malevola risultava l’unica disponibile nella serie compatibile.

Cargo utilizza intervalli caret per molte dipendenze. Un vincolo come arrayref ^0.3.6 accetta quindi tutte le versioni compatibili della serie 0.3.x, compresa la 0.3.10. Il ricercatore GitHub jhobern ha riferito di essersi imbattuto nell’attacco proprio attraverso questo meccanismo.

La portata potenziale di arrayref è rilevante. Una verifica tramite API di crates.io, effettuata il 21 agosto 2026, ha rilevato:

• 245.385.500 download complessivi;
• 53.905.601 download nei 90 giorni terminati il 20 agosto;
• 403 crate distinti che lo indicavano come dipendenza.

Tra le catene di dipendenza figura winit, che richiede sctk-adwaita ^0.10.1; quest’ultimo dipende da tiny-skia ^0.11, che a sua volta richiede arrayref ^0.3.6.

Anche blake3 dipendeva da arrayref fino alla versione 1.8.6, ma non dalla 1.8.7, pubblicata alle 09:09 UTC. I progetti blake2b_simd e blake2s_simd hanno eliminato la dipendenza in release pubblicate rispettivamente alle 09:25 e alle 09:26 UTC.

Il metodo di compromissione dell’account non è noto. Il proprietario legittimo di arrayref è l’utente crates.io 2402, David Roundy, registrato nell’ottobre 2009. Il team Rust ritiene probabile una compromissione del computer o delle credenziali, non un’azione intenzionale dell’autore.

Il payload installava persistenza e rubava dati dai browser

Secondo l’analisi di Wiz, lo stage successivo comunicava tramite richieste HTTPS POST verso il percorso /49890878. Il malware poteva installare meccanismi di persistenza specifici per il sistema operativo:

• una chiave Registry Run su Windows;
• un LaunchAgent su macOS;
• un servizio systemd dell’utente su Linux.

Il componente supportava quattro categorie di comando: terminazione, modifica del server C2, installazione della persistenza e download ed esecuzione di ulteriori script.

Wiz ha osservato anche il furto di credenziali dai database SQLite di Chrome, Brave ed Edge. L’analisi Nextron del payload Windows ha però rilevato soltanto la lettura dei campi origin_url e username_value, senza estrazione diretta di password_value.

I payload per Linux e macOS erano disponibili soltanto in forma hash e non sono stati analizzati. Non è quindi possibile estendere automaticamente ai due sistemi operativi le conclusioni osservate sul campione Windows.

L’attribuzione resta aperta. Wiz ha segnalato sovrapposizioni infrastrutturali con precedenti campagne nordcoreane contro la supply chain, comprese le compromissioni di Mastra npm e axios. Microsoft ha associato l’operazione Mastra a Sapphire Sleet, mentre GTIG ha attribuito l’incidente axios a MIDNIGHT NEPTUNE, precedentemente indicato come UNC1069.

Nessun vendor ha però attribuito questa campagna su crates.io a uno specifico gruppo.

Cosa devono verificare gli sviluppatori

Il Rust Security Response Team ha rimosso le release malevole e ha revocato il precedente stato di yanked per gestire l’incidente. Per arrayref, la raccomandazione è mantenersi alla versione 0.3.9 o precedente. Non esiste una release corretta delle tre versioni compromesse.

Gli sviluppatori dovrebbero:

1. controllare ~/.cargo/registry/cache alla ricerca dei pacchetti eliminati;
2. riesaminare i progetti compilati con cargo build, cargo check o cargo test;
3. cercare connessioni verso gli indicatori noti;
4. verificare la presenza dei file temporanei e dei meccanismi di persistenza;
5. ruotare le credenziali eventualmente utilizzate sui sistemi interessati.

Gli indicatori di rete includono:

• 23.254.165.112:9089, server per il payload;
• 23.254.165.112:443, infrastruttura C2;
• hwsrv-798836.hostwindsdns.com.

I nomi file da cercare sono /tmp/rust-setup, %TEMP%\rust-setup.ps1 e %TEMP%\rust-setup-launch.vbs. Tra i binari sono stati indicati rust-crate_0.1.0, _0.2.0, _0.3.0 e _0.4.0.

Vanno inoltre esaminati i metadati relativi agli account dtolney, identificato come impersonatore, e droundy, associato al proprietario legittimo. È stato segnalato anche l’indirizzo [email protected].

Il caso è documentato, per arrayref, dall’advisory RUSTSEC-2026-0260. Cargo non dispone ancora di una finestra d’attesa predefinita per le dipendenze appena pubblicate: una proposta per rendere stabile global-min-publish-age risultava ancora aperta il 21 agosto 2026.

L’incidente evidenzia il rischio delle dipendenze aggiornate automaticamente e, soprattutto, degli script eseguiti durante la compilazione. In un precedente caso del settembre 2025, due crate malevoli attivavano il codice soltanto a runtime. Qui il punto d’ingresso era invece il processo di build, spesso considerato una fase più affidabile della catena software.