---
title: "L'attacco alla supply chain di arrayref, e perché il tuo wallet non ha bisogno di un singolo punto di guasto"
description: "Una breach di 2 ore di un crate Rust con 245 milioni di download, e cosa significa per il software che muove i tuoi soldi."
lang: "it"
type: "knowledge-guide"
datePublished: "2026-08-21"
dateModified: "2026-08-21"
canonical: "https://nuri.com/it/conoscenza/attacco-a-arrayref-nella-cadena-di-fornitura"
tags: ["attacco alla supply chain","crate arrayref","singolo punto di guasto","self-custody","sicurezza del wallet bitcoin","MuSig2","co-firma stateless"]
---

# L'attacco alla supply chain di arrayref, e perché il tuo wallet non ha bisogno di un singolo punto di guasto

**TL;DR:** I gliattor hanno compromesso l'account di una nota libreria Rust e pubblicato una versione falsa che eseguiva malware sulla macchina nel momento in cui qualcuno la compilava. La versione malevola è rimasta online per circa 86 minuti, e la libreria ha 245 milioni di download. Questo fa parte di un'onda di attacchi alla supply chain che diventano più frequenti e più aggressivi. La lezione più grande per chiunque i cui soldi dipendono da un software è che il codice e i server tra te e i tuoi fondi sono un singolo punto di guasto. Nuri è costruito in modo che nessuna singola breach, né un'app compromessa né un server violato, esponga la chiave che controlla il tuo bitcoin. Solo una chiave sta mai sul telefono. La seconda parte vive in un servizio stateless. Rubare i soldi richiede entrambe.

## Indice

- [La risposta rapida](#quick-answer)
- [Cosa è successo davvero](#what-happened)
- [Perché questa è la nuova normalità](#new-normal)
- [Cosa dicono gli sviluppatori](#what-developers-say)
- [Quando il codice controlla i soldi](#why-it-matters)
- [Il problema del singolo punto di guasto](#single-point)
- [Come Nuri lo rimuove](#how-nuri)
- [Modelli di wallet, confrontati su una domanda](#comparison)
- [Il piccolo glossario](#glossary)
- [Domande che la gente pone](#faqs)

## La risposta rapida

**In breve:** Una versione falsa di una libreria popolare eseguiva malware sulle macchine durante la compilazione. La lezione: il software tra te e i tuoi soldi è un singolo punto di guasto, quindi progetta in modo che nessuna singola breach vinca.

Il 20 agosto 2026 è arrivato un rapporto che un crate Rust chiamato proc-macro1 era malevolo. Il Rust Security Response Team lo ha confermato in pochi minuti: il crate portava un build script che scaricava ed eseguiva un payload remoto. Compilare qualsiasi progetto che includeva il crate era sufficiente per eseguirlo. Nessuno doveva chiamare alcuna funzione. La compilazione stessa era l'innesco.

Il vero obiettivo era arrayref, un crate piccolo e noto usato da un numero enorme di altri progetti. Il suo account di proprietario era stato compromesso. L'attaccante ha pubblicato una nuova versione di arrayref che dipendeva dal crate falso, e ha ritirato in silenzio le versioni vecchie perché il tool di compilazione indirizzasse gli utenti alla versione cattiva.

Nulla di questo riguarda specificamente Rust. Riguarda come viene costruito il software: tutti facciamo affidamento su migliaia di pezzi scritti da altre persone, e uno di loro può essere quello velenoso. Quando la cosa che tiene i tuoi soldi è un software, questo smette di essere un problema di sviluppatore e diventa un problema di soldi.

## Cosa è successo davvero

**In breve:** Un account manutentore compromesso ha pubblicato una dipendenza falsa. Compilare il crate scaricava ed eseguiva un backdoor che ruba credenziali. Tutto è rimasto online meno di due ore.

L'attaccante non ha riscritto la libreria. Ha aggiunto una riga: una dipendenza su proc-macro1, un errore deliberato nella scrittura di proc-macro2, uno dei crate più scaricati di tutto l'ecosistema. Il crate falso è una copia genuina di quello vero, quindi la build va a buon fine e il software continua a funzionare. Questo è esattamente il punto. Nulla sembra rotto. Il payload si esegue prima che tu noti qualsiasi cosa.

Il build script ricostruiva in silenzio l'indirizzo del server dell'attaccante a partire da pezzi di testo codificato, disattivava il controllo di sicurezza che verifica l'identità del server e scaricava un programma scelto per il tuo sistema operativo e processore. Su Mac e Linux scriveva il file in una cartella temporanea e lo lanciava in background. Su Windows scriveva uno script e lo avviava nascosto. L'attaccante ha scelto tutto questo per evitare di essere notato durante la compilazione.

Il backdoor scaricato è malware vero, non un test. I ricercatori di sicurezza che l’hanno analizzato hanno trovato che chiama a casa, legge il nome del computer e l’utente, elenca i programmi installati e cerca nei profili del browser i login salvati. Si installa per tornare dopo il riavvio. Può scaricare ed eseguire più codice su richiesta. Se il server principale va giù, genera nuovi nomi di dominio per trovarne uno nuovo.

Le versioni malevole sono state rimosse rapidamente: arrayref 0.3.10 è rimasto online circa 86 minuti, e i due crate correlati circa 90 e 107 minuti. Il team Rust ha bloccato l'account del proprietario come precauzione e ha dichiarato di non credere che l'autore agisse in mala fede. È più probabile che il suo computer o il suo login siano stati compromessi. L'autore di arrayref mantiene il crate dal 2009.

Wiz, un’azienda di sicurezza, ha trovato che l’infrastruttura dell’attaccante sovrappone operazioni recenti attribuite alla Corea del Nord, incluse campagne contro altre librerie popolari. Non è stato un evento isolato di un dilettante casuale. È stata una campagna organizzata usando un pattern che avevano già usato prima.

- Obiettivo: arrayref 0.3.10, internment 0.8.7 e append-only-vec 0.1.9, tutti da un account compromesso.
- Veicolo: una nuova dipendenza, proc-macro1, un errore di scrittura dell’onnipresente proc-macro2.
- Innesco: la build stessa. Eseguire cargo build su un progetto interessato eseguiva il payload.
- Online: da 86 a 107 minuti prima della rimozione il 2026-08-20.
- Scala: arrayref ha 245 milioni di download e compare nella maggioranza degli ambienti che usano Rust.

## Perché questa è la nuova normalità

**In breve:** Gli attacchi alla supply chain non sono un caso raro. Sono una parte in crescita, industrializzata e sempre più automatizzata di come viene attaccato internet.

L'attacco ad arrayref sembra shockante perché ha colpito una libreria popolare e di fiducia. Ma i numeri dicono che non dovrebbe esserlo. La stessa classe di attacco opera da anni contro ogni registry di pacchetti maggiore, e il tasso sale.

I vendor che monitorano questo riportano oltre un milione di pacchetti malevoli su npm, PyPI, Maven, NuGet e Hugging Face, con il conteggio di pacchetti malevoli nuovi nel 2025 in aumento di circa il 75 per cento rispetto all’anno prima. Il costo stimato degli attacchi alla supply chain ha raggiunto circa 60 miliardi di dollari nel 2025, con proiezioni vicine a 138 miliardi entro il 2030. Circa il 30 per cento delle breach di dati coinvolge ora un terzo, e la maggior parte delle vulnerabilità nel software commerciale si trova non nel codice principale ma nelle dipendenze che incorpora.

Due cose lo peggiorano allo stesso tempo. Primo, il tooling che costruisce ed esegue il software è diventato più complesso, quindi ci sono più parti mobili che un attaccante può toccare. Secondo, gli attaccanti usano l’IA per trovare bersagli, scrivere il codice malevolo e scalare la campagna, mentre le persone responsabili di revisionare ogni dipendenza sono per lo più volontari non retribuiti.

Su Hacker News, dove il thread principale ha raggiunto 400 punti e centinaia di commenti, la verità scomoda è che gli sviluppatori lo vedono arrivare. Una delle osservazioni più votate era che il tooling di build esegue codice sulla tua macchina senza il tuo consenso, quindi aggiungere una dipendenza basta a comprometterti prima ancora di revisionare il codice. Un’altra ha notato che la stessa cosa è successa con la breach della libreria di compressione xz, e che nessuno può leggere ogni piccolo pacchetto dell’albero profondo delle dipendenze per dimostrarlo pulito.

## Cosa dicono gli sviluppatori

**In breve:** La reazione non è panico. È un riconoscimento stanco e informato che il tooling di build non era mai stato progettato come un confine di sicurezza.

La discussione su Hacker News è stata insolitamente calma e specifica, che di solito è il segno di una community esperta che affronta un problema noto. Ecco cosa continuava a venire, nelle loro parole, leggermente ridotta.

Su perché continua a succedere: "Dopo molti attacchi precedenti alla supply chain, perché i manutentori dei registry di pacchetti permettono ancora a chiunque di caricare pacchetti e spingere aggiornamenti senza audit di sicurezza?" Questa domanda non era retorica. Il seguito era il vero problema: "Chi finanzia questo audit di sicurezza? La gente dovrebbe fare volontariato del suo tempo libero?"

Sul tooling di build: "Il problema è che i build script si eseguiscono automaticamente senza consenso o intervento dell’utente. Aggiungere una dipendenza basta a comprometterti, prima che tu abbia la possibilità di revisionare il codice." Diversi hanno notato che altri package manager hanno controlli che Cargo non ha, come l’allowlist dei script di installazione e un cooldown sulle dipendenze di giornata.

Sull'obiettivo: "Le macchine degli sviluppatori sono bersagli molto succosi. Tendono ad avere ogni sorta di credenziali sparse, quindi spesso non è troppo difficile escalare da lì a compromettere i tuoi account cloud." Questo è il vero premio nella maggior parte di questi attacchi. Non è la macchina. È tutto ciò che quella macchina può raggiungere.

Su se la lingua conti: "Rust sembra appena meglio di Node in questo." La controargomentazione, anch’essa ampiamente condivisa, è che l’ecosistema ha già strumenti di audit, e diverse grandi aziende pubblicano audit dei crate di cui dipendono. Il gap è che l’audit è l’eccezione, non la norma.

Un dettaglio ha colpito. Diversi hanno chiesto cosa facesse esattamente il codice malevolo, e la risposta era che nessuno poteva esserne sicuro, perché l’account dell’autore era stato eliminato e le pubblicazioni malevole erano state cancellate dal registry anziché solo ritirate. L’attaccante si è pulito dietro. È il marchio di un’operazione che ha già fatto questa cosa prima.

## Quando il codice controlla i soldi

**In breve:** Un attacco alla supply chain su un sito web è fastidioso. Uno sul software che tiene i tuoi soldi è un problema completamente diverso.

La maggior parte degli attacchi alla supply chain colpisce sviluppatori e aziende, e il danno sono credenziali rubate, dati rubati o una pulizia lenta e costosa. L'area d'impatto è un server di build o un account aziendale.

Un wallet è diverso. Il punto intero del software è poter muovere i tuoi soldi. Se il codice in quel software, o i server di cui dipende, può essere compromesso, la breach può andare dritta ai fondi. Non c’è un livello di "ops, abbiamo perso qualche login" tra l’attaccante e il tuo saldo.

Per questo il problema della supply chain e il problema del self-custody sono lo stesso problema. Entrambi riguardano dove vive davvero la chiave che controlla i tuoi soldi, e se un singolo punto della catena, una libreria, un’azienda, un server, un manutentore, un provider, può prenderla.

## Il problema del singolo punto di guasto

**In breve:** Un singolo punto di guasto è la cosa che, se si rompe o viene presa, fa perdere tutto. La maggior parte dei wallet ne ha uno. L’obiettivo è non averne.

Un singolo punto di guasto è semplice da definire e difficile da progettare via. È l’unica componente che, se compromessa o in disavvio, fa fallire l’intero sistema. Per un exchange in custodia, sono i suoi server. Se vengono violati, o semplicemente congelano il tuo account, i tuoi soldi sono alla loro mercé. Per un wallet software che deriva la tua chiave da un segreto sul tuo dispositivo, è quel singolo segreto. Se l’app viene compromessa tramite un update velenoso, o il tuo dispositivo viene preso, il segreto è esposto.

Il motivo per cui questi design hanno un singolo punto di guasto è che sono comodi. Un posto per mettere la chiave significa un posto per firmare e un posto per fare il backup. Comodità e sicurezza tirano in direzioni opposte, e la maggior parte dei prodotti sceglie la comodità.

Esiste una forma migliore. Dividi l’autorità di muovere i tuoi soldi in due o più cose che un attaccante dovrebbe prendere insieme, e assicurati che nessuna di esse tenga la chiave intera da sola. Allora nessuna singola breach, una libreria cattiva, un server violato, un telefono rubato, un update malevolo, vince da sola. L’attaccante deve avere successo due volte, in due posti diversi, nello stesso momento. Questa è la differenza tra un bersaglio e una fortezza.

## Come Nuri lo rimuove

**In breve:** Nuri usa un modello di firma divisa in cui solo una chiave sta mai sul telefono, e la seconda parte è stateless, quindi né l’app né il server da soli espongono la tua chiave.

Nuri è costruito su uno schema di firma divisa chiamato MuSig2, nella forma 2-di-2 che può essere espansa a 2-di-3. Servono due parti separate per firmare e muovere i fondi, e nessuna parte da sola può farlo.

Sul tuo telefono, solo una chiave esiste mai: la tua chiave. È derivata localmente dal tuo passkey, la credenziale biometrica o di dispositivo che sblocca il tuo telefono, attraverso una funzione che la trasforma in una chiave. Questa chiave è generata sul tuo dispositivo e non lo lascia mai. Non viene caricata, non viene inviata a un server per essere memorizzata, e non è incorporata nell’app come qualcosa che potrebbe essere estratto da un build compromesso.

La seconda parte è tenuta dal servizio di co-firma di Nuri. Qui sta la parte che conta per questa storia. Questo servizio è costruito per essere stateless. Tiene l’autorità di co-firmare entro la policy che hai impostato per il tuo wallet, ma non memorizza una copia della tua chiave. Non c’è un vault di chiavi utente sui server Nuri da violare. Se l’app che esegui viene compromessa tramite un bug di supply chain, l’attaccante ottiene un’app compromessa, non la tua chiave. Se i server Nuri vengono violati, l’attaccante ottiene un servizio stateless senza chiavi utente da prendere. Nessuno dei due eventi, da solo, espone la chiave privata.

Il risultato è che il pattern di arrayref, una dipendenza velenosa che esegue codice in build, non si traduce in un wallet rubato. La chiave che conta è sul telefono, derivata da qualcosa sul telefono, e il secondo pezzo di firma vive con un servizio che non ha nulla da cedere. Rubare i soldi richiede due parti intere, e stanno in due posti diversi che l’attaccante dovrebbe raggiungere insieme.

Il design mantiene anche un’uscita. L’accordo di co-firma ha un limite di tempo. Dopo una finestra fissa, l’utente ha un percorso di recupero indipendente che non dipende dal co-firmante. E se vuoi ancora più separazione, si può aggiungere un hardware wallet come terza parte, rendendolo 2-di-3, in modo che nessun singolo dispositivo o servizio, telefono o server, tenga abbastanza per muovere i tuoi fondi.

## Modelli di wallet, confrontati su una domanda

**In breve:** Fai a ogni modello la stessa domanda: se l’unica cosa si rompe, i tuoi soldi sono finiti?

Il confronto che conta non sono le funzioni. È cosa espone una singola breach. Ecco quattro modelli di custodia comuni a cui viene posta la stessa domanda.

| Modello | Dove sta la chiave | L'app è compromessa | Il server del provider è violato | Cosa serve all’attaccante |
| --- | --- | --- | --- | --- |
| Exchange in custodia | Sui server dell’exchange | Non puoi muovere i tuoi soldi | I fondi possono essere congelati o presi | Una cosa, l’exchange |
| Wallet software a chiave singola | Un segreto sul tuo dispositivo | Il segreto può essere esposto | Di solito non nel percorso, ma l’app è il rischio | Una cosa, il segreto del tuo dispositivo |
| MPC con parte memorizzata sul server | Divisa, una parte sul server | L'app può esporre la gestione della parte | Una parte memorizzata può essere rubata | La parte memorizzata più quella del dispositivo |
| Nuri, co-firma stateless | Una chiave sul telefono, una parte stateless su Nuri | Nessuna chiave utilizzabile nell’app | Nessuna chiave utente memorizzata da prendere | Due parti intere, in due posti |

- Non documentato significa che la capacità non fa parte del design descritto, non che non possa mai esistere.
- La colonna Nuri descrive il modello 2-di-2 con un co-firmante stateless, espandibile a 2-di-3 con un backup hardware.
- Nessun modello è immune a ogni attacco. Questo è un confronto del singolo punto di guasto che ognuno lascia dietro.

## Il piccolo glossario

**In breve:** Le parole che questa storia usa, una riga ciascuna.

**Attacco alla supply chain:** Una compromise di una componente o dipendenza su cui altri si fidano, in modo che l'attaccante raggiunga tutti quelli che la usano.

**Typosquat:** Un nome che sembra uno noto con un piccolo cambio di ortografia, per essere preso per errore. proc-macro1 per proc-macro2.

**Build script:** Codice che si esegue automaticamente quando si compila un progetto. In Rust può eseguire prima del tuo codice, motivo per cui è un bersaglio privilegiato.

**Singolo punto di guasto:** L'unica componente la cui perdita o compromissione fa fallire l'intero sistema.

**Self-custody:** Tu tieni l’autorità di muovere i tuoi soldi, invece di una compagnia che li tiene per te.

**MuSig2:** Uno schema di firma che può dividere il diritto di firmare tra più chiavi, in modo che nessuna singola chiave possa muovere i fondi da sola.

**Stateless:** Il servizio non mantiene una copia persistente della tua chiave. Non c’è nulla di memorizzato che una breach possa rubare.

**Passkey:** La credenziale biometrica o di dispositivo che sblocca il tuo telefono, usata qui per derivare localmente la tua chiave.

## Domande che la gente pone

**In breve:** Gli attacchi alla supply chain sono un rischio reale e in crescita per il software attorno ai tuoi soldi. Nuri è progettato in modo che nessuno di essi, da solo, esponga la tua chiave.

### Cosa c’entra questo attacco Rust con il mio wallet?

Indirettamente, molto. La lezione non è su Rust. È che il software tra te e i tuoi soldi è fatto di pezzi che non controlli, e uno di loro può essere velenoso. Un wallet è un software il cui lavoro è muovere i tuoi fondi, quindi una compromise di supply chain è un rischio diretto per quei soldi, non solo per una macchina di sviluppo.

### Questo attacco ha colpito qualche wallet o qualche utente bitcoin?

Non c’è evidenza che le versioni malevole siano state usate per colpire qualche wallet o qualche persona. Il team Rust ha riportato evidenze di uso reale, e non esiste una versione corretta perché la correzione è stata eliminare le pubblicazioni cattive. Il rischio è il pattern, che si applica a qualsiasi software che dipende da codice di terze parti, e i wallet sono bersagli ad alto valore per quel pattern.

### Il self-custody mi protegge dagli attacchi alla supply chain?

Dipende dal design. Self-custody significa che tu tieni l'autorità, ma se quell'autorità è una chiave in un posto, una singola compromise vince comunque. La protezione viene dal rimuovere il singolo punto di guasto, in modo che l'autorità sia divisa e nessuna singola componente, app, server o dispositivo, tenga abbastanza da sola.

### Cosa dovrei fare io adesso?

Per il tuo software, mantieni le versioni delle dipendenze fissate e aggiornate, e tieni d’occhio nuovi nomi di dipendenze malevole dopo incidenti come questo. Per i tuoi soldi, scegli un modello di custodia in cui una singola breach non esponga la tua chiave. Se usi Nuri, non c’è nulla da fare. Il design mantiene già una chiave sul tuo telefono e una parte stateless dal nostro lato, quindi un’app compromessa o un server violato non consegnano all’attaccante la tua chiave.

### Un hardware wallet risolve questo?

Un hardware wallet sposta la firma via dal telefono e dall’app, che rimuove molto del rischio di supply chain dell’app. È una scelta forte. Nuri può usarne uno come terza parte in un setup 2-di-3, che aggiunge separazione sopra la co-firma stateless invece di sostituirla.

### Cosa significa stateless per il server Nuri?

Significa che il servizio di co-firma non memorizza la tua chiave. Tiene la capacità di co-firmare entro la policy del tuo wallet, non una copia della chiave privata in sé. Quindi non c'è un vault di chiavi sui server Nuri per un attaccante da violare. La chiave privata è derivata sul tuo telefono dal tuo passkey e resta lì.

### Se l'app è compromessa, può un attaccante vedere il mio saldo o inviare soldi?

Un'app compromessa può vedere ciò che l'app stessa può vedere, e un update malevolo potrebbe mostrare informazioni false. Ma muovere i tuoi soldi richiede una firma, e la firma ha bisogno di entrambe le parti che lavorino insieme. Un co-firmante stateless senza chiave memorizzata non può produrre quella firma da solo, e la chiave del telefono non lascia mai il dispositivo.

### Perché un attaccante dovrebbe curarsi di un wallet?

Perché è denaro diretto. Il backdoor di arrayref è stato costruito per rubare credenziali, che possono essere scambiate o usate per raggiungere altro. Una chiave di wallet è la credenziale più diretta che esista. Ecco perché esattamente il singolo punto di guasto è la cosa da rimuovere. Rendi la chiave impossibile da ottenere da un solo posto, e l’attaccante deve essere doppio fortunato e doppio coordinato.

### Cosa posso fare io come sviluppatore per proteggere le mie build?

Fissa le versioni delle tue dipendenze e non aggiornare automaticamente a una pubblicazione di giornata il giorno in cui esce. Molte team aspettano pochi giorni perché auditor e aziende di sicurezza guardino prima una versione nuova. Mantieni un audit del tuo albero di dipendenze, e tieni d’occhio nomi di dipendenze nuovi dopo un incidente come questo. Questi passi riducono la finestra in cui una pubblicazione velenosa può raggiungerti.

### Come spesso succedono attacchi come questo?

Più di quanto i titoli suggeriscano. I vendor che monitorano i registry contano migliaia di pacchetti malevoli nuovi ogni trimestre, e il numero continua a crescere anno su anno. La maggior parte non fa mai notizia perché sono typosquat che nessuno installa. Quelli che fanno notizia, come arrayref, sono quelli che colpiscono un pacchetto popolare e di fiducia. Questa è la classe di evento che conta per chiunque i cui soldi dipendono da un software.

## Fonti e nota di aggiornamento

I dettagli dell'attacco sono al 2026-08-21 e provengono dal post del team Rust collegato, dai rapporti delle aziende di sicurezza e dal thread di Hacker News. Le statistiche sono stime dai rapporti di industria 2026 collegati e variano per fonte. Conferma i numeri attuali prima di affidarti a essi per una decisione.

1. [Blog Rust: attacco alla supply chain di arrayref](https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on-arrayref/)
2. [The Hacker News: attacco Rust mette malware in build nei crate](https://thehackernews.com/2026/08/rust-supply-chain-attack-puts-build.html)
3. [Wiz: attacco alla supply chain Rust su arrayref, sovrapposizione DPRK](https://www.wiz.io/blog/rust-supply-chain-attack-on-arrayref-significant-overlap-with-dprk-campaigns)
4. [Socket: crate Rust popolari compromesse](https://socket.dev/blog/popular-rust-crates-compromised)
5. [BleepingComputer: hacker avvelenano il crate Rust arrayref](https://www.bleepingcomputer.com/news/security/hackers-poison-arrayref-rust-crate-to-push-infostealer-malware/)
6. [Hacker News: crate malevola Rust Arrayref esegue un payload in build](https://news.ycombinator.com/item?id=49374269)
7. [Avviso RustSec RUSTSEC-2026-0260](https://rustsec.org/advisories/RUSTSEC-2026-0260.html)
8. [CVE-2026-77651: compromise di supply chain di arrayref](https://cvefeed.io/vuln/detail/CVE-2026-77651)
9. [AppSec Santa: statistiche attacchi alla supply chain 2026](https://appsecsanta.com/research/supply-chain-attack-statistics)

## Disponibile anche in

- [The arrayref supply chain attack, and why your wallet needs no single point of failure](https://nuri.com/knowledge/supply-chain-attack-arrayref) (en)
- [Der arrayref-Supply-Chain-Angriff, und warum deine Wallet keine einzelne Angriffsfläche braucht](https://nuri.com/de/wissen/arrayref-supply-chain-angriff) (de)
- [El ataque a la cadena de suministro de arrayref, y por qué tu wallet no necesita un punto único de fallo](https://nuri.com/es/conocimiento/ataque-de-cadena-de-suministro-arrayref) (es)