Cosmos EVM: bug noto da aprile, exploit da 5,7 milioni in sei…

Cosmos Labs aveva identificato la vulnerabilità critica nell'EVM module a aprile 2026. La scelta di una patch silenziosa pubblica ha lasciato venti ore agli

Cosmos Labs sapeva dal 13 agosto 2026 che ogni blockchain basata sul modulo Cosmos EVM era vulnerabile a un difetto di gestione dei saldi. Ha comunque proceduto con una patch silenziosa pubblica, ritenendo sicuro il processo perché la correzione era già sul branch principale senza exploit noti. Venti ore dopo, il primo attacco ha svuotato il burn address di MANTRA. Entro il 25 agosto, sei chain avevano subito perdite per circa 5,72 milioni di dollari.

Punti chiave

Il difetto GHSA-7g4w-cg88-2cq2, classificato Critico da Cosmos Labs, è stato segnalato il 25 aprile 2026 ma inizialmente valutato non pericoloso per reti a 18 decimali
La patch è stata rilasciata pubblicamente il 19 agosto in v0.6.2 e v0.7.2, senza distribuzione privata d'emergenza prevista dalla policy interna della stessa Cosmos Labs
Prima descrizione pubblica del percorso exploit in un fork di Push Chain alle 07:16 UTC del 20 agosto; primo attacco contro MANTRA alle 19:06 UTC dello stesso giorno
Cosmos Labs ha inviato la prima notifica privata alle 03:36 UTC del 21 agosto, circa due ore dopo che MANTRA aveva già segnalato l'exploit in corso

Il meccanismo: underflow non controllato tra StateDB e x/bank

La vulnerabilità risiede nella riconciliazione dei saldi tra l'EVM StateDB, che traccia solo il saldo spendibile, e il modulo Cosmos SDK x/bank, che gestisce saldi spendibili più saldi bloccati. Quando un account vesting delega un importo superiore al saldo spendibile, la sottrazione non controllata genera un underflow che avvolge verso ~2^256, manipolando infinitamente le funzioni di mint e burn.

L'exploitazione richiede tre condizioni cumulative: la creazione permissionless di account vesting, un percorso di delegation attraverso staking precompile o path equivalente, e la presenza della versione difettosa della funzione SubBalance. Le versioni interessate sono quelle precedenti alla 0.6.2 e dalla 0.7.0 alla 0.7.2 esclusa, secondo quanto documentato da The Hacker News.

La correzione richiede un upgrade coordinato che rompe lo stato, non una semplice sostituzione di codice. Disabilitare lo staking precompile o bloccare la creazione di account vesting sono mitigazioni parziali, non risolutive: il contributore del Warden Protocol jlehtimaki ha osservato che rimuovere il percorso di creazione degli account vesting chiude il prerequisito piuttosto che affidarsi alla correttezza della ricostruzione del saldo.

Timeline: da segnalazione bounty a exploit in 117 giorni

Il difetto è stato segnalato attraverso il programma bug bounty di Cosmos Labs il 25 aprile 2026. Il team inizialmente non è riuscito a riprodurre la vulnerabilità su reti a 18 decimali e ha concluso erroneamente che interessasse solo configurazioni con decimali diversi, come ammesso nel post-mortem di Cosmos Labs: "We were unable to reproduce the vulnerability on 18-decimal networks and incorrectly concluded that it affected only non-18-decimal networks".

Entro il 13 agosto, Cosmos Labs ha confermato che tutte le chain Cosmos EVM erano interessate indipendentemente dalla configurazione decimale. Nonostante la propria policy di bug bounty — aggiornata l'ultima volta il 27 luglio — preveda "emergency mitigations, private fix distribution, or coordinated upgrades before any public disclosure occurs" per questioni che presentano "immediate or network-wide risk", il team ha optato per il processo di patch silenziosa pubblico.

La motivazione, riportata nel post-mortem: "Because the patch had already been publicly available on the main branch without known exploitation, the team concluded that it would be safe to proceed with the silent patch process". La release v0.6.2 e v0.7.2 è uscita il 19 agosto alle 19:01 ET. Alle 03:16 ET del 20 agosto — 07:16 UTC — uno sviluppatore di Push Chain ha depositato una modifica al codice che descriveva pubblicamente la vulnerabilità e il percorso di exploit. Alle 15:06 ET — 19:06 UTC — è iniziato il primo attacco contro MANTRA.

"Twenty hours was not a realistic window in which to assess, build, test and coordinate a state-breaking upgrade across 38 independent validators, particularly without a vulnerability-specific advisory"

I danni: sei chain, 5,72 milioni di dollari realizzati

Cosmos Labs ha confermato sei blockchain exploitata tra il 20 e il 25 agosto 2026, con proventi realizzati stimati in circa 5,72 milioni di dollari al prezzo del 19 agosto: circa 2,87 milioni su exchange decentralizzati e circa 2,85 milioni su exchange centralizzati. La cifra non è stata sottoposta a verifica indipendente, come specificato dalla stessa fonte.

MANTRA ha perso 720,9 milioni di token MANTRA, per un valore di circa 3,6 milioni di dollari, prelevati dal burn address e da un multisig dormiente. TAC ha perso quasi 3 miliardi di token TAC dal staking pool, di cui circa 1,2 miliardi venduti su BNB Chain per circa 950.000 dollari. KiiChain ha perso circa 148 milioni di token KII, con 64,6 milioni venduti per circa 1,6 milioni di dollari.

Tre chain aggiuntive sono state attaccate ma non nominate da Cosmos Labs. Nesa è stata indicata come possibile obiettivo sulla base della sospensione dei depositi su exchange e di analisi Bubblemaps, senza conferma ufficiale. MANTRA, secondo dichiarazione del 28 agosto, non aveva recuperato fondi.

Il crollo della governance: quando il processo diventa vulnerabilità

L'incidente non è tecnicamente un'ignoranza del difetto, ma una scelta di processo. Cosmos Labs aveva classificato il bug come Critico, aveva confermato l'impatto universale, disponeva di policy che imponevano distribuzione privata per rischi di rete immediati — e ha comunque proceduto con una patch pubblica silenziosa.

Il post-mortem di KiiChain, citato da The Block, accusa: "Cosmos Labs gave no advance notice to downstream chains, did not flag the release as security critical, and did not tell affected chains that a public release had happened until Friday 21 August, two days later". KiiChain aggiunge che "a patch takes days to review, build, test and roll out across a validator set. A halt takes minutes. The only measure that would have contained the risk immediately was a clear instruction to stop producing blocks, and that instruction came after the damage was done".

Il sistema di disclosure ha rivelato una cecità strutturale: durante l'incidente, Cosmos Labs ha scoperto 11 deployment Cosmos EVM che non avevano mai registrato contatti di sicurezza. Su circa 115 blockchain pubbliche nell'ecosistema Cosmos, la visibilità a valle è insufficiente per processi di disclosure coordinata. Questo è aggravato da un problema tecnico di manutenzione: il contributore ZetaChain morde08 ha notato che patch cherry-pickate in fork hanno lasciato irrisolto il percorso live a causa di helper non esportati duplicati.

Cosa fare adesso

Verificare immediatamente la versione del modulo Cosmos EVM in esecuzione: aggiornare a v0.6.2 o v0.7.2 se si utilizza versione interessata
Controllare la presenza di helper duplicati non esportati in eventuali fork del codice, che potrebbero lasciare il percorso vulnerabile attivo nonostante la patch
Valutare se la creazione di account vesting sia permissionless sulla propria chain e considerare la disabilitazione come mitigazione parziale
Registrare contatti di sicurezza presso Cosmos Labs se il proprio deployment non li ha ancora comunicati, dato che 11 chain sono state scoperte senza registrazione durante l'incidente

Perché questo caso cambia le regole della sicurezza open-source distribuita

La lezione non è che le patch devono essere segrete, ma che la sicurezza di infrastrutture open-source ampiamente distribuite non può affidarsi all'assunzione che i destinatari a valle rilevino autonomamente il significato di una commit. Cosmos Labs ha trattato la disponibilità pubblica della patch come equivalente alla sua distribuzione consapevole, ignorando che 38 validatori indipendenti su una singola chain — per non parlare delle altre cinque — non costituiscono un unico operatore con un unico sistema di monitoraggio.

Per investitori e utenti, l'incidente rende visibile un rischio di dipendenza precedentemente opaco: le holding di token su chain apparentemente sovrane possono essere esposte a vulnerabilità in moduli condivisi il cui branding non rivela la relazione tecnica. Per i progetti blockchain, la domanda è se i processi di disclosure progettati per software con vendor unico siano adattabili a ecosistemi dove il "vendor" è un fornitore di componenti senza visibilità su chi li impiega.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti

Ricevi DeafLetter