Cosmos EVM, falla critica senza CVE: sei blockchain colpite, la patch silenziosa non ha fermato l’exploit

Il 28 agosto 2026 Cosmos Labs ha pubblicato un advisory GitHub e un post-mortem per una vulnerabilità critica nel modulo condiviso Cosmos EVM, l’ambiente per l’esecuzione di smart contract compatibili con Ethereum nell’ecosistema Cosmos SDK. La falla, identificata come GHSA-7g4w-cg88-2cq2, è stata classificata Critical dal vendor ma non ha ricevuto un identificativo CVE, una classificazione CWE né un punteggio CVSS. Le versioni affette sono tutte quelle inferiori a 0.6.2 e quelle comprese tra 0.7.0 e 0.7.1. Le correzioni sono state rilasciate il 19 agosto nelle versioni v0.6.2 e v0.7.2, ma l’aggiornamento è state-breaking e richiede un upgrade di rete coordinato. Tra il 20 e il 25 agosto la falla è stata sfruttata attivamente contro sei blockchain, con perdite economiche stimate in milioni di dollari.

Come funziona l’attacco: underflow, vesting account e saldi “gonfiati”

La vulnerabilità nasce nel codice che riconcilia lo stato dell’EVM con il modulo x/bank di Cosmos SDK. Lo StateDB dell’EVM tiene traccia soltanto del saldo spendibile di un conto. Nei conti di vesting, invece, lo stato SDK contiene sia un saldo spendibile sia un saldo bloccato, che può essere delegato tramite il modulo x/staking e la precompilata di staking.

Quando un conto di vesting delega più del proprio saldo spendibile, la scrittura successiva sottrae l’intero importo delegato da un saldo inferiore: la sottrazione non viene controllata e il valore va in underflow, avvolgendosi a circa 2^256. La riconciliazione successiva conia su un delta positivo e brucia su un delta negativo. Un attaccante può quindi spostare un importo finito da un conto con saldo “avvolto” e inviare a una vittima una quantità pari a 2^256 meno il suo saldo, così da far bruciare alla riconciliazione le disponibilità reali della vittima.

Sulle catene che eseguono la linea 0.6.x, la coniazione o combustione avviene sul ledger SDK sottostante: una coniazione elevata causa un overflow dell’offerta che arresta la catena. Sulle linee 0.7.x, i saldi vengono impostati direttamente in x/bank e accettano modifiche che sopravvivono alla conversione da uint256 a int256. In entrambi i casi, l’intera operazione viene eseguita in un’unica transazione con variazione netta dell’offerta pari a zero, a partire da un contratto distribuito su un indirizzo precalcolato che era stato trasformato in precedenza in conto di vesting. Lo sfruttamento richiede che la catena consenta la creazione permissionless di conti di vesting.

La cronologia: segnalazione ad aprile, conferma ad agosto, patch silenziosa

La falla è stata segnalata il 25 aprile tramite il programma bug bounty di Cosmos Labs. Inizialmente il team la valutò come priva di rischi per i fondi sulle reti live: non riusciva a riprodurla su reti a 18 decimali e concluse erroneamente che riguardasse solo reti con decimali diversi. Solo il 13 agosto è arrivata la conferma che tutte le catene Cosmos EVM erano affette, indipendentemente dalla configurazione dei decimali.

La correzione primaria – un underflow guard nel write-back SubBalance dello StateDB – era già stata introdotta sul ramo main con la PR #1176, fusa il 15 maggio. I backport sono avvenuti molto più tardi: PR #1253 per la linea v0.6.x e PR #1254 per v0.7.x, che hanno portato ai rilasci v0.6.2 e v0.7.2 del 19 agosto.

Il fix è passato attraverso il processo di silent patch, riservato da Cosmos Labs ai problemi che non causano perdita di fondi in produzione. La policy prevede mitigazioni d’emergenza o distribuzione privata per i rischi immediati, ma in questo caso il team ritenne sicuro procedere in silenzio perché la patch era già pubblica sul ramo main e non risultava sfruttamento noto.

La valutazione si è rivelata sbagliata. Il 20 agosto alle 07:16 UTC, otto ore e quindici minuti dopo la pubblicazione dei rilasci, una PR pubblica nel fork di Push Chain ha descritto in dettaglio la vulnerabilità e il percorso di sfruttamento. Undici ore e cinquanta minuti più tardi, alle 19:06 UTC, è iniziato il primo attacco contro MANTRA. La prima notifica privata di Cosmos Labs via email sicura è partita solo il 21 agosto alle 03:36 UTC, circa due ore dopo che MANTRA aveva segnalato lo sfruttamento.

Impatto: sei catene, milioni di dollari venduti su exchange

Cosmos Labs è a conoscenza di sei blockchain in cui l’exploit è stato utilizzato attivamente. MANTRA è l’unica nominata esplicitamente come prima vittima. Gli attaccanti hanno venduto circa 2,87 milioni di dollari in asset colpiti su exchange decentralizzati, cifra basata sui prezzi del 19 agosto e fornita dalle catene stesse, non verificata in modo indipendente. Ulteriori 2,85 milioni di dollari sono stati venduti su exchange centralizzati, stima basata su dati di volume pubblici.

L’ecosistema Cosmos comprende oltre 115 blockchain pubbliche note, ma Cosmos Labs non dispone di un registro completo delle reti che eseguono il suo software. Questa lacuna aveva già costretto a luglio i vendor downstream a patchare difetti dei filesystem inclusi. Durante l’incidente, il team ha scoperto undici implementazioni Cosmos EVM mai registrate ai propri canali di sicurezza.

Cosa devono fare gli operatori: patch, workaround e verifiche

L’advisory ufficiale raccomanda di aggiornare a v0.6.2 o v0.7.2 o successivi, applicando la modifica come upgrade coordinato di rete perché state-breaking. Se non è possibile aggiornare immediatamente, la raccomandazione è fermare la catena invece di tentare un upgrade di governance coordinato. Non esiste una mitigazione solo configurazionale: disabilitare la precompilata di staking rimuove il percorso di attivazione principale, ma non sostituisce la patch.

The Hacker News ha elencato ulteriori passi operativi per gli sviluppatori. Il primo è chiudere la precondizione: rifiutare nell’ante handler i messaggi MsgCreateVestingAccount, MsgCreatePermanentLockedAccount e MsgCreatePeriodicVestingAccount, senza toccare i conti di vesting definiti nella genesi. Il secondo è verificare il percorso di codice live su un fork: un cherry-pick che corregge solo l’helper esportato può lasciare una copia non esportata duplicata, mentre tutti i test continuano a passare. Il terzo è applicare le due correzioni che l’advisory omette: lo snapshot del saldo bloccato (PR #1187, fusa il 20 maggio) e il guard per gli account di modulo (commit 3524ebc). Il guard rifiuta incondizionatamente gli account di modulo, il che interrompe le chiamate EVM effettuate da un account di modulo. Infine, ogni team dovrebbe registrare un contatto di sicurezza presso Cosmos Labs.

ZetaChain ha portato le tre correzioni il 21 agosto, osservando che il cherry-pick lasciava il percorso live del fork non corretto perché il fork conteneva helper non esportati duplicati. Warden Protocol, due giorni dopo, ha bloccato del tutto la creazione di vesting account: su Warden le vesting account sono l’unica fonte di saldi bloccati e nessuna funzionalità dipende dalla loro creazione, quindi rimuovere quel percorso chiude la precondizione senza affidarsi alla correttezza della ricostruzione.

Silent patch e precedenti: 37 vulnerabilità senza descrizione pubblica

L’advisory documenta un solo cambiamento upstream: l’underflow guard della PR #1176. Ma nello stesso repository esistono altre due correzioni di saldo non menzionate: la PR #1187, che fotografa il saldo bloccato di un conto per ricostruire correttamente il saldo bancario dopo una modifica da precompilata, e il commit 3524ebc, intitolato “Merge commit from fork”, che rifiuta qualsiasi tentativo di impostare il saldo di un account di modulo. I backport della PR #1187 erano stati aperti e fusi entro ventiquattro ore su entrambe le linee di rilascio, mentre il backport della PR #1176 è seguito circa novanta giorni dopo.

Le note di rilascio di v0.6.2 e v0.7.2 affermano che contengono correzioni di sicurezza importanti, ma omettono il backport di sicurezza dai changelog. The Hacker News ha confermato il 29 agosto che nessuno dei due rilasci elenca i pull request che lo trasportano.

Cosmos Labs ha dichiarato di aver distribuito in silenzio patch per 37 vulnerabilità negli ultimi 13 mesi, senza che gli sviluppatori downstream descrivessero pubblicamente i percorsi di exploit. La decisione di non distribuire privatamente la patch dopo la conferma del 13 agosto che tutte le catene erano affette è ora al centro delle critiche. The Hacker News ha contattato Cosmos Labs per un commento ed è in attesa di risposta.