Verus Ethereum Bridge Exploit: lo stesso bug da 11,58 milioni di dollari
Il 18 maggio 2026, qualcuno ha svuotato il bridge Verus-Ethereum per 11,58 milioni di dollari. Secondo quanto riportato da CoinDesk, si trattava dell'ottavo attacco a un bridge dell'anno. L'exploit del bridge Verus Ethereum non ha coinvolto nessuna nuova classe di attacco esotica. È stato lo stesso fallimento che abbiamo visto uccidere i bridge dal 2021: il contratto ha rilasciato fondi su una chain senza verificare correttamente cosa fosse realmente accaduto sull'altra.
La funzione vulnerabile aveva un nome, questa volta. checkCCEValues. È la routine che avrebbe dovuto confermare che i valori di esportazione cross-chain corrispondessero alla realtà prima di coniare o rilasciare sul lato Ethereum. Non ha svolto il suo compito, e l'attaccante se ne è andato con il bottino.
Ho trascorso quattro anni a costruire infrastrutture adiacenti ai bridge in un contesto regolamentato, e la parte deprimente è quanto tutto ciò sia diventato prevedibile. Continuiamo a rinominare la stessa ferita.
L'exploit del bridge Verus Ethereum è stato un fallimento della validazione della fonte
Tolto il branding, ogni bridge fa una sola cosa. Osserva un evento sulla chain A (un deposito, un blocco, un'esportazione) e produce un'azione corrispondente sulla chain B (una coniazione, uno sblocco, un rilascio). L'intero modello di sicurezza si riduce a una singola domanda: la chain B crede davvero a ciò che le ha detto la chain A, e ha verificato?
Quando la validazione che conferma gli importi lato sorgente è errata, la risposta diventa "no". L'attaccante falsifica o gonfia il valore di esportazione dichiarato, il contratto di destinazione si fida di esso, e vengono coniati o liberati token che non erano mai stati garantiti. The Block ha riportato la perdita a circa 11,58 milioni di dollari, prosciugati attraverso esattamente questo tipo di lacuna contabile nel controllo dell'esportazione cross-chain.
Questa è la validazione dell'importo sorgente in un bridge, ed è la funzione più critica dell'intero sistema. Sbagliare anche solo un confronto trasforma il bridge in una macchina per stampare denaro gratis.
checkCCEValues è solo il nome più recente di una vecchia vulnerabilità
La vulnerabilità checkCCEValues è strutturalmente identica ai bug che hanno già costato al settore miliardi di dollari. I nomi cambiano. Il meccanismo no.
- Wormhole, 2022: una lacuna nella verifica delle firme ha permesso a un attaccante di coniare 120.000 ETH wrapped che non erano mai stati depositati.
- Nomad, 2022: un'inizializzazione errata della merkle root faceva sì che qualsiasi messaggio venisse validato come vero, e il bridge è stato copiato e saccheggiato da un'intera folla.
- Multichain, 2023: chiavi e assunzioni di fiducia che nessuno poteva verificare concretamente dall'esterno.
Ognuno di questi casi era, nella sua essenza, una chain di destinazione che rilasciava valore senza una prova solida dell'evento sulla chain sorgente. checkCCEValues è l'ortografia 2026 della stessa parola.
Credo che il settore continui a trattare questi episodi come singoli errori di ingegneria, quando in realtà sono un fallimento di categoria. Una categoria non si corregge auditando una funzione con più attenzione.
Tornado Cash ha finanziato l'attaccante, e questo dice qualcosa sulle intenzioni
Il wallet dell'attaccante era stato finanziato tramite Tornado Cash prima dell'exploit. Questo dettaglio conta meno per l'attribuzione che per ciò che rivela sulla preparazione. Non si trattava di un ricercatore che stava sondando un contratto e si è ritrovato sorpreso dal risultato. Il pattern del wallet finanziato via Tornado Cash è la firma di qualcuno che ha costruito una copertura operativa giorni prima, aspettandosi che i fondi avrebbero avuto bisogno di essere riciclati in uscita.
Questo è l'aspetto che i difensori sottovalutano. Quando la transazione dell'exploit viene confermata, la via di fuga è già pronta. Il tracciamento a posteriori aiuta i pubblici ministeri, ma non fa quasi nulla per il protocollo che ha appena perso otto cifre.
I fallimenti di sicurezza dei bridge sono ormai una tassa mensile
Guardando il quadro generale, l'hack di Verus è una voce di bilancio, non un'anomalia. Secondo i dati PeckShield citati da Bitcoin.com, gli exploit ai bridge crypto hanno totalizzato circa 328 milioni di dollari nel solo maggio 2026. Otto incidenti a bridge in meno di cinque mesi dall'inizio dell'anno.
Il mercato ha silenziosamente incorporato tutto questo come costo del fare business cross-chain. È la lezione sbagliata. Una perdita mensile ricorrente a nove cifre non è volatilità, è un difetto strutturale che lo spazio di progettazione si rifiuta di affrontare.
Per chiunque muova valore reale, la conclusione è scomoda: la maggior parte dei bridge sono assunzioni di fiducia travestite da matematica. Ho già sostenuto, in How Stablecoin Bridges Actually Fail, che il bridge più sicuro è spesso quello che ammette quanto poco verifichi effettivamente.
Come appare un controllo bridge davvero difendibile
Se stai costruendo o verificando un bridge, la validazione dell'importo sorgente è il punto su cui dovresti concentrare una quota sproporzionata della tua paranoia. Alcune cose che considererei irrinunciabili:
- Il contratto di destinazione deve verificare una prova crittografica dell'evento sorgente, non la parola di un relayer. Prove basate su light-client o zk al posto di attestazioni multisig, ovunque il budget di latenza lo consenta.
- I controlli sugli importi devono essere esaustivi su ogni percorso. La classe di bug
checkCCEValuessi nasconde di solito in un ramo che certi input saltano. Fuzz-testa il confronto, non affidarti all'analisi visiva. - Rate limit e circuit breaker per asset, in modo che un valore falsificato non possa svuotare l'intera riserva in una singola transazione. Un limite che si mette automaticamente in pausa al, diciamo, 5% del TVL all'ora avrebbe attenuato la maggior parte degli incidenti del 2026.
- Monitoraggio indipendente degli invarianti che osserva in tempo reale il totale coniato rispetto al totale bloccato e si interrompe in caso di divergenza.
Nulla di tutto questo è originale. Lo stack di audit per intercettare questi problemi esiste, come ho approfondito nel pezzo sullo stack di audit. Il problema è che i bridge continuano a rilasciare la validazione come un ripensamento invece che come il prodotto vero e proprio.
Il prossimo hack di un bridge del 2026 è già in fase di scrittura. Avrà un nome di funzione diverso e la stessa causa radice, e faremo di nuovo finta di sorprenderci. Non dovremmo.