EIP-7702 non è la causa principale del furto di 6,3 miliardi di dollari da parte di Binance; lo è invece il modo in cui è stata ottenuta la firma.

Ora di Pechino, 30 ottobre 2026, 04:24.

I dati on-chain mostrano che i fondi sono usciti dall’indirizzo 0x28C6…1d60, denominato Binance 14, uno dei più grandi wallet caldi Ethereum di Binance, che effettua migliaia di prelievi quotidiani. Questa transazione ha trasferito 167.464 ETH, 1,615 miliardi di USDT e oltre 60 tipi di token, per un valore totale di circa 2,5 miliardi di dollari. Il wallet è rimasto con 1 ETH.

La commissione gas era di 0,0004 ETH, inferiore a 1 dollaro.

Tre minuti prima, alle 04:21, qualcuno ha inviato una transazione di tipo EIP-7702 all’indirizzo, contenente 50 autorizzazioni con nonce compresi tra 18.914.775 e 18.914.824. 49 erano invalide, 1 ha avuto successo. Un successo significa che, da quel momento in poi, ogni chiamata a Binance 14 esegue il contratto deployato dall’attaccante la sera precedente alle 23:59: un contratto ‘spazzino’ non verificato con un’unica funzione di prelievo.

Così Binance 14 non è più un wallet, ma una shell contenente un programma di terzi.

Alle 08:06 la delega era ancora attiva. Trascorse 3 ore e 45 minuti senza che fosse revocata.

Revocare questa delega richiede semplicemente una nuova firma con la stessa chiave. Alle 06:55 di quella mattina, Binance stava ancora usando tale chiave per trasferire indietro nel proprio wallet i token sparsi non ancora prelevati.

EIP-7702 è la causa principale dell’attacco?

La logica di EIP-7702 è la seguente: permette a un indirizzo ordinario (EOA) di ‘noleggiare’ il codice di un contratto intelligente, mantenendo invariati indirizzo, saldo e chiave privata. Il noleggio avviene scrivendo 23 byte nel campo code dell’indirizzo: 0xef0100 seguito dall’indirizzo del contratto. Questi 23 byte non sono codice eseguibile, ma un puntatore. Da quel momento, ogni chiamata a questo indirizzo fa sì che l’EVM carichi ed esegua il codice puntato nel contesto dell’indirizzo stesso: address(this) rimane sé stesso e il saldo resta invariato.

Non presenta alcun bug. Derek Chiang, fondatore di ZeroDev e partecipante a EIP-7702, ha dichiarato chiaramente il giorno dell’incidente: EIP-7702 non ha vulnerabilità e gli utenti di wallet che supportano questo standard non devono preoccuparsi. Ha aggiunto inoltre: per utilizzare 7702, un attaccante deve controllare la chiave privata o ingannare Binance affinché firmi un’autorizzazione 7702.

Non è la prima volta che viene usato come strumento d’attacco. Dopo l’aggiornamento Ethereum Pectra, Wintermute ha scoperto entro poche settimane che oltre il 97% delle deleghe 7702 sulla mainnet puntavano quasi tutte allo stesso contratto ‘spazzino’; ricerche hanno registrato circa 3,66 milioni di transazioni di autorizzazione, di cui circa il 63% legate a contratti malevoli, con perdite confermate di 2,3 milioni di dollari; Blockaid ha verificato quattro incidenti 7702 nel primo semestre 2026, per un totale di circa 1,08 milioni di dollari, prevedendo che il primo caso da sette cifre si sarebbe verificato entro l’anno.

Il risultato è stato invece da dieci cifre, tre ordini di grandezza superiore alla stima.

Ciò ha portato molti a attribuire l’attacco da 5,6 miliardi di dollari a Binance — il più grande della storia — a EIP-7702. Ma è davvero un problema legato a 7702?

Come sono state ottenute le firme

Prima di procedere, va chiarito un punto: 50 autorizzazioni equivalgono a 50 firme — ma come sono state esattamente generate queste 50 firme?

Se l’attaccante avesse avuto accesso completo alle chiavi private, perché avrebbe dovuto tentare ciecamente 50 nonce? Se le chiavi fossero sempre state in mano a Binance, perché 11 wallet sono stati compromessi simultaneamente entro 12 minuti? Nessuna spiegazione è stata fornita.

Ventiquattro secondi dopo la principale operazione di prelievo, Binance 16 ha trasferito 28.005,6 ETH, 55,7 milioni di USDT, 25,9 milioni di RLUSD e 84,5 WBTC, tutti allo stesso indirizzo ricevente.

Entro 12 minuti, altri 10 wallet caldi di Binance hanno effettuato operazioni analoghe su quattro blockchain: Binance 55 su Optimism ha trasferito 44,2 milioni di OP; quattro wallet su Arbitrum hanno trasferito 74,6 milioni di ARB e 8.426 ETH; quattro wallet su Avalanche hanno trasferito 1,81 milione di AVAX e 8,41 milioni di USDT.

Nessuno di questi wallet conteneva codice. Ogni transazione era un semplice trasferimento firmato con la propria chiave privata, inserito tra prelievi ordinari.

Chi possiede le chiavi private non deve forzare i nonce alla cieca. Verificare eth_getTransactionCount richiede un secondo.

Chi necessita di generare 50 autorizzazioni per 50 nonce consecutivi in un’unica operazione è una figura diversa: qualcuno che può ottenere firme ma non accedere allo stato in tempo reale del wallet; oppure chi può inviare solo un lotto di autorizzazioni precostituite tutte insieme, lasciando al sistema il compito di tentarne l’esecuzione.

Ancora più significativo: queste 50 autorizzazioni sono state approvate tutte insieme in una singola transazione.

Blockaid, società di sicurezza, ritiene che «la chiave sia stata usata impropriamente», non che la chiave privata sia stata estratta direttamente. Anche Quit, VP Blockchain di Yuga Labs, concorda: l’attaccante ha ottenuto «firme autorizzate», non la chiave privata; l’uso di un relayer per l’invio potrebbe essere stato proprio finalizzato a oscurare l’origine delle firme.

Shenyu ha menzionato un dettaglio nel suo riassunto mattutino: fino alle 06:55, Binance continuava a firmare con la stessa chiave privata, trasferendo token frammentati non ancora prelevati nuovamente nel proprio wallet.

Ciò indica che la chiave era ancora sotto il controllo di Binance quella mattina.

Proprio ora, alle 10:26, Binance ha fornito una prima comunicazione: il laptop di un ingegnere DevOps potrebbe essere stato compromesso, consentendo all’attaccante di accedere ai container dei servizi ed eseguire prelievi non autorizzati; al momento non vi è alcuna evidenza di perdita della chiave privata del wallet.

La perdita non è avvenuta sulla blockchain

Il problema centrale non è quindi l’EIP-7702, ma la fase precedente alla firma.

Un wallet caldo firma migliaia di transazioni al giorno, quindi deve essere automatizzato; deve essere sicuro, quindi richiede HSM, MPC, multi-firma e flussi di approvazione. L’intero modello di sicurezza si riduce così a una sola domanda: questo processo riesce a determinare, prima della firma, che «questa transazione non deve essere firmata»?

Il problema è che la maggior parte dei criteri decisionali valuta solo due parametri: importo e indirizzo.

L’autorizzazione 7702 non ne ha né uno né l’altro. Non specifica alcun importo. Ciò che modifica non è «quanto trasferire», ma «chi è questo indirizzo».

Non è che Binance non si fosse difesa.

Tre giorni prima dell’incidente, il 27 ottobre, ha proattivamente segnalato un dettaglio importante: nella settimana precedente il team di sicurezza aveva intercettato numerosi attacchi collegati alla Corea del Nord. Il metodo, chiamato Contagious Interview, prevede che l’attaccante si finga un reclutatore, utilizzando colloqui, test di programmazione e frasi come «installa prima uno strumento per sviluppatori» per indurre le vittime a eseguire programmi dannosi; una volta avviato, il programma apre una porta d’accesso per chiavi, reti interne e movimentazione successiva di fondi.

Ma non è riuscita a impedire la domanda «questa transazione deve essere firmata?»