Cosmos Labs heeft gewaarschuwd voor een Cosmos EVM kwetsbaarheid die tussen 20 en 25 augustus 2026 werd misbruikt om middelen af te tappen. Volgens de melding ging het om een kritieke fout in een gedeelde Cosmos EVM-module, met impact op meerdere netwerken binnen het ecosysteem.
De ontdekking is extra pijnlijk omdat de fix al bestond voordat grootschalige publicatie plaatsvond. Tegelijkertijd blijkt uit de post-mortem dat de teams lange tijd aannamen dat het probleem slechts onder specifieke decimal-configuraties zou gelden. Daarmee werd het risico voor productie-chains uiteindelijk onderschat—en konden aanvallen toch plaatsvinden.
Wat was er mis met de Cosmos EVM kwetsbaarheid?
Het gaat om een balance-handling fout in de code die de EVM-state afstemt met de Cosmos SDK x/bank-module. De EVM StateDB houdt daarbij alleen een besteedbaar saldo bij, terwijl vesting-accounts in de SDK zowel een besteedbaar als een locked (vergrendeld) saldo kunnen bevatten.
De kern van het probleem zit in hoe de overdracht na delegatie wordt weggeschreven. Wanneer een vesting-account meer delegeert dan het besteedbare saldo, wordt het gedelegeerde bedrag afgetrokken van het kleinere saldo zonder dat die aftrek wordt gecontroleerd. Door die ontbrekende check kan het saldo vervolgens rondlopen naar een waarde die dicht bij 2^256 ligt.
Daarna volgt een reconciliatiestap: positieve verschillen leiden tot het mint’en van tokens, negatieve verschillen tot het burn’en. In de praktijk kan een aanvaller zo een beperkte hoeveelheid uit een “wrapped” saldo halen, of—bij een specifieke aanpak—een slachtoffer sturen met een hoeveelheid waardoor de burn feitelijk over het echte holdingssaldo wordt getild.
Welke chains en versies waren getroffen?
Cosmos Labs noemt het probleem GHSA-7g4w-cg88-2cq2 en kwalificeert het als Critical. Er was geen CVE-identificatie en er werd ook geen CVSS-score bekendgemaakt.
De getroffen versies zijn: < 0.6.2 en >= 0.7.0 & < 0.7.2. De fix is volgens Cosmos Labs geleverd in v0.6.2 en v0.7.2 (en later). Daarmee ligt de verantwoordelijkheid primair bij chain operators om hun netwerkcomponenten tijdig te updaten.
Cosmos Labs zegt dat de exploit is benut op zes blockchains. De leverancier stelt ook dat er geen volledige registry bestaat van alle netwerken die hun software draaien, waardoor door downstream partijen soms patchwerk vertraagd of onvolledig kan worden opgepakt.
Waarom was de impact zo groot?
De kwetsbaarheid raakt een fundamentele reconciliatielogica die binnen dezelfde transactie draait. Er is sprake van een set van mechanismen waarbij een contract wordt ingezet op een vooraf berekend adres en vervolgens een vesting-account wordt. Daarna werken delegatie en reconciliatie samen met de manier waarop saldi worden gemodelleerd in zowel de EVM-laag als de Cosmos SDK-laag.
Cosmos Labs beschrijft bovendien een onderscheid tussen lijnen rond 0.6.x en 0.7.x:
- Bij 0.6.x kan het mint/burn-mechanisme leiden tot een overloop van de token supply, wat de chain kan stilzetten.
- Bij 0.7.x worden balances direct ingesteld in x/bank en “overleeft” de verandering vervolgens een conversiepad van uint256 naar int256, waardoor de exploitroute functioneel kan blijven.
Voor exploit is bovendien vereist dat de chain toestaat dat vesting-accounts permissionless kunnen worden aangemaakt. Dat maakt de precondition cruciaal in het verdedigingsplan.
Belangrijkste aanvalspad in mensentaal
Hoewel details technisch zijn, komt het neer op het volgende. Een vesting-account wordt gedelegeerd tot voorbij het besteedbare saldo. Daardoor ontstaat na de write-back een toestand waarin saldi kunnen rondlopen door de ontbrekende underflow-check. Vervolgens probeert de reconciliatie die toestand te “repareren” met mint/burn op basis van het gemeten verschil.
Daarmee kan de aanvaller ofwel:
- een bedrag uit het “wrapped” account verplaatsen, of
- een slachtoffer transactie laten uitvoeren die de reconciliatie triggert in een richting die echte holdings verbrandt.
Cosmos Labs geeft daarnaast aan dat er een scenario is waarin het uitzetten van een staking-precompile de primaire trigger kan wegnemen, maar dat dit geen volwaardige vervanging is voor de echte patch.
Timeline: patch, aannamefout en latere exploit
De bug werd via het bug bounty-programma gerapporteerd op 25 april 2026. Destijds beoordeelde het team dat er geen risico voor fondsen bestond op live netwerken. In de post-mortem erkent Cosmos Labs dat ze de kwetsbaarheid niet konden reproduceren op “18-decimal networks” en daarom ten onrechte concludeerden dat het alleen daarbuiten speelde.
Later—tegen 13 augustus—werd bevestigd dat alle Cosmos EVM chains betroffen waren, ongeacht de decimal-configuratie. Daarna is een fix uitgerold via het “silent patch” proces dat doorgaans wordt gebruikt voor problemen die geen fund loss veroorzaken op productie-chains.
Cosmos Labs noemt daarbij een policy-differentie: wanneer een probleem een directe of netwerkbrede dreiging vormt, zouden volgens hun bug bounty beleid doorgaans eerst noodmaatregelen, privéfixdistributie of gecoördineerde upgrades volgen, nog vóór public disclosure.
Wat moeten operators nu doen?
Cosmos Labs geeft een reeks adviezen die vooral gericht zijn op het stoppen van verdere exploit, niet op cosmetische workaround-strategieën. De basis is duidelijk: upgrade naar v0.6.2 of v0.7.2, of een latere versie.
Verder benadrukt de leverancier dat de update state-breaking is. Dat betekent dat het netwerk een gecoördineerde network upgrade nodig heeft.
Als je niet meteen kunt upgraden: halt, niet stemmen
Operators die de release niet direct kunnen implementeren, krijgen een sterke instructie: stop block production in plaats van een governance-upgrade proberen te orkestreren. Cosmos Labs stelt dat er geen configuration-only mitigatie is die het probleem volledig afvangt.
Het uitschakelen van de staking precompile wordt genoemd als optie die de belangrijkste triggerlijn kan wegnemen, maar het wordt expliciet niet gezien als vervanging voor de patch.
Sluit de precondition in de ante handler
Cosmos Labs adviseert om het aanmaken van vesting- en locked accounts te blokkeren via de ante handler. Concreet gaat het om het afwijzen van:
- MsgCreateVestingAccount
- MsgCreatePermanentLockedAccount
- MsgCreatePeriodicVestingAccount
Let op: vesting accounts die al in genesis zijn gedefinieerd worden volgens de advisory niet geraakt.
Test op een fork en let op cherry-pick valkuilen
Een extra waarschuwing gaat over patchselectie. Cosmos Labs stelt dat een cherry-pick die alleen een geëxporteerde helper repareert, in een fork alsnog een duplicaat van een niet-geëxporteerde variant kan laten bestaan—zodat de live code path ongewijzigd blijft terwijl tests wel slagen.
Extra maatregelen die in de advisory ontbreken
Naast de stappen die in de public advisory staan, noemt Cosmos Labs ook aanvullingen. Zo worden er “twee fixes” genoemd die niet volledig in de advisory zaten.
Het gaat om:
- een locked-balance snapshot wijziging zodat reconstructie correct is nadat een precompile het locked saldo wijzigt;
- een guard op module accounts die module accounts onvoorwaardelijk afwijst. Dat kan EVM-calls vanuit module accounts breken, maar het voorkomt wel ongewenste routes in de balanslogica.
Voor organisaties die afdelingen of integrators aansturen: dit punt is belangrijk. Het toont aan dat “een patch toepassen” niet altijd gelijkstaat aan “alle relevante codepaden raken”.
Beveiligingsproces: melding, stille patches en communicatie
In de post-mortem probeert Cosmos Labs het afstemmingsvraagstuk te verklaren tussen het moment waarop de bug bekend werd en het moment waarop de fix veilig verspreid werd.
De leverancier geeft aan dat er 37 kwetsbaarheden stil werden gepatcht in de afgelopen 13 maanden, maar dat downstream ontwikkelaars exploitpaden niet altijd exact beschreven zien in publieke bronnen. Tegelijkertijd is het voor operators juist waardevol om te weten welke trigger en welke transactievoorwaarden nodig zijn.
Een concreet praktisch punt: Cosmos Labs zegt dat het tijdens het incident elf Cosmos EVM deployments heeft gezien die nooit hun security contact hadden geregistreerd bij de beveiligingskanalen.
Als je dit soort “ketenbrede” communicatie al eerder wilt verbeteren binnen je organisatie, is het relevant om ook aandacht te geven aan bredere supply chain risico’s. Zie bijvoorbeeld: Supply chain aanvallen: TeamPCP in Australië aangeklaagd.
Financiële impact en wat we nog niet onafhankelijk weten
Cosmos Labs zegt dat er op decentalised exchanges ongeveer USD 2.87 miljoen is verkocht aan getroffen assets op basis van prijzen van 19 augustus. Het bedrijf stelt dat dit bedrag door de getroffen chains is aangeleverd en niet onafhankelijk is geaudit.
Daarnaast noemt Cosmos Labs een extra USD 2.85 miljoen aan verkopen op centralised exchanges, gebaseerd op volumegegevens uit publieke bronnen.
Wat hiermee vooral duidelijk wordt: incident-response in blockchainomgevingen vraagt niet alleen om techniek (patchen), maar ook om snelle ketencommunicatie en dataverzameling over waar en wanneer liquiditeit is weggehaald.
Lessen voor chain operators
De Cosmos EVM kwetsbaarheid laat een aantal terugkerende lessen zien voor teams die EVM-compatibele omgevingen met Cosmos SDK integreren.
- Upgrade is niet optioneel: omdat de fix state-breaking is, is coördinatie nodig om consistentie te behouden.
- Werk ook aan precondition blocking: als permissionless vesting-account creation een sleutelpad vormt, moet dat pad hard worden afgesloten tot alle nodes de correctie bevatten.
- Controleer fork-specifieke codepaden: cherry-picks kunnen misgaan als code dubbel bestaat of als wijzigingen in upstream slechts één variant raken.
- Versterk security contact routes: als deployments niet geregistreerd zijn, mist een organisatie mogelijk de snelste meldstroom.
Conclusie
Cosmos Labs meldt dat een Cosmos EVM kwetsbaarheid in de Cosmos EVM module is misbruikt om op meerdere chains fondsen af te tappen. De combinatie van een complexe reconciliatielogica, een vereiste precondition (permissionless vesting-account creation) en een update die state-breaking is, maakt de impact groot—en de response urgent.
Voor operators is het advies van Cosmos Labs helder: upgrade naar v0.6.2 of v0.7.2 of later via een gecoördineerde network upgrade. Kun je niet direct upgraden, dan is halt-procedure de aanbevolen route. Daarmee voorkom je dat een “tijdelijke” governance of een niet-volledige workaround de kwetsbaarheid alsnog openhoudt.
Bron: https://thehackernews.com/2026/08/cosmos-evm-flaw-exploited-after-cosmos.html
