Una vulnerabilità nel software condiviso Cosmos EVM ha permesso agli aggressori di sottrarre fondi da sei blockchain tra il 20 e il 25 agosto 2026. Cosmos Labs ha ricostruito l’incidente in un post-mortem pubblicato il 28 agosto, indicando un danno complessivo stimato in circa 5,7 milioni di dollari. Il caso riporta al centro della discussione uno dei rischi più delicati della finanza decentralizzata: quando lo stesso componente software viene utilizzato da molte reti, una singola falla può trasformarsi rapidamente in un problema sistemico.
Secondo la ricostruzione ufficiale, gli attaccanti hanno convertito circa 2,87 milioni di dollari in token attraverso exchange decentralizzati, utilizzando come riferimento i prezzi del 19 agosto. Altri 2,85 milioni di dollari sarebbero stati venduti su piattaforme centralizzate. Cosmos Labs ha aggiunto che gli account utilizzati dagli aggressori presso alcuni exchange centralizzati risultano congelati in attesa delle indagini delle autorità competenti.
La falla nel collegamento tra EVM e Cosmos SDK
Il problema non riguardava una singola applicazione DeFi, ma il codice di base utilizzato dalle blockchain che integrano Cosmos EVM. La vulnerabilità nasceva da un’incoerenza nel modo in cui il sistema gestiva i saldi tra l’ambiente compatibile con Ethereum e il modulo x/bank del Cosmos SDK.
In particolare, l’attacco sfruttava il comportamento degli account vesting, cioè indirizzi che detengono token soggetti a vincoli temporali o di disponibilità. Combinando due vulnerabilità in una sola transazione, l’aggressore poteva alterare il modo in cui venivano contabilizzati i saldi spendibili e quelli bloccati. Il risultato era la possibilità di estrarre token legittimi dagli account vesting senza generare un aumento corrispondente dell’offerta totale.
Il meccanismo è rilevante per l’ecosistema DeFi perché molte applicazioni, dai mercati di prestito agli exchange decentralizzati, dipendono dalla correttezza dello stato della blockchain sottostante. Se la contabilità dei saldi viene compromessa a livello di infrastruttura, anche protocolli che non presentano direttamente una falla nei propri smart contract possono essere esposti a conseguenze indirette.
Il problema della valutazione iniziale
Uno degli aspetti più significativi del caso riguarda la gestione della segnalazione iniziale. La vulnerabilità era stata comunicata attraverso il programma bug bounty il 25 aprile 2026. Il report comprendeva una prova di concetto relativa a una rete Cosmos EVM con configurazione a sei decimali.
Cosmos Labs ha spiegato di aver tentato di riprodurre il problema su altre configurazioni e di non essere riuscita inizialmente a replicarlo sulle reti a 18 decimali. Poiché le blockchain Cosmos EVM allora conosciute utilizzavano configurazioni a 18 decimali, il rischio era stato classificato come non in grado di provocare perdite di fondi sulle reti in produzione.
Il codice era stato quindi corretto con una procedura di patch pubblica e silenziosa, normalmente utilizzata per problemi ritenuti non pericolosi per i fondi degli utenti. La correzione era stata inserita nel ramo principale a maggio, ma non era stata immediatamente distribuita nelle versioni operative, anche perché avrebbe richiesto aggiornamenti coordinati e potenzialmente interruzioni delle reti.
Tra maggio e agosto, ulteriori segnalazioni di ricercatori indipendenti hanno fornito elementi sufficienti per verificare che il problema riguardava tutte le configurazioni, comprese quelle a 18 decimali. Le versioni corrette v0.6.2 e v0.7.2 sono state pubblicate il 19 agosto, ma il post-mortem evidenzia che il percorso di sfruttamento era stato descritto pubblicamente il giorno successivo in una pull request di un progetto derivato da Cosmos EVM.
L’attacco parte da MANTRA e si allarga
Il primo attacco noto è stato registrato il 20 agosto sulla rete MANTRA. Dopo due transazioni malevole, MANTRA ha fermato la blockchain e ha rilasciato un hotfix. Secondo la timeline pubblicata da Cosmos Labs, la prima comunicazione riservata alle reti conosciute che utilizzavano Cosmos EVM è stata inviata circa due ore dopo la segnalazione dell’incidente.
La risposta si è poi estesa ad altre reti. TAC è stata colpita il 22 agosto, seguita da KiiChain poche ore più tardi. Cosmos Labs ha successivamente indicato che altre tre blockchain erano state attaccate utilizzando lo stesso schema, senza pubblicare nel documento una timeline completa per ciascuna di esse.
La società ha quindi raccomandato agli operatori di fermare immediatamente le proprie blockchain, invece di procedere con normali aggiornamenti di governance, e di installare le versioni corrette. In parallelo, il team ha ampliato i propri canali di contatto includendo operatori che non erano presenti nella lista di sicurezza originale.
Perché il caso conta per la DeFi
L’incidente mostra che audit e bug bounty, pur essendo strumenti essenziali, non eliminano il rischio operativo. Cosmos Labs ha dichiarato che il percorso di codice coinvolto era stato sottoposto a revisioni interne e a verifiche esterne, ma la vulnerabilità non era stata individuata durante quegli audit.
La questione riguarda soprattutto i software condivisi da più reti. In un ecosistema composto da blockchain indipendenti, la diversificazione può ridurre alcuni rischi, ma l’utilizzo dello stesso stack tecnico crea anche un punto comune di esposizione. Una falla nel livello infrastrutturale può quindi propagarsi a catena, coinvolgendo token, bridge, exchange decentralizzati e applicazioni di lending presenti su reti diverse.
Cosmos Labs ha annunciato una revisione delle proprie procedure di triage, una maggiore attenzione ai casi in cui l’impatto di una vulnerabilità può essere più ampio rispetto alla segnalazione originaria e controlli più strutturati sui canali di divulgazione coordinata. La società intende inoltre migliorare i meccanismi per verificare che gli operatori delle reti rispondano tempestivamente agli avvisi di sicurezza.
Per gli utenti DeFi, la conseguenza più immediata è la necessità di considerare anche la sicurezza della blockchain e dello stack sottostante, non soltanto quella dello smart contract con cui interagiscono. Per gli sviluppatori, il caso evidenzia invece il costo di una patch che viene classificata come ordinaria quando il software è già distribuito su numerose reti con configurazioni diverse.
