Krytyczna luka w Cosmos EVM wykorzystana po publikacji poprawki. Sześć łańcuchów dotkniętych incydentem

Wprowadzenie do problemu / definicja

Cosmos EVM to komponent pozwalający uruchamiać logikę zgodną z Ethereum w sieciach budowanych w ekosystemie Cosmos. Najnowszy incydent bezpieczeństwa dotyczy krytycznej podatności w mechanizmie obsługi sald, która umożliwiała błędową rekonstrukcję stanu kont i mogła prowadzić do powstawania nienaturalnie wysokich wartości bilansu. Problem miał charakter systemowy, ponieważ obejmował współdzielony moduł wykorzystywany przez wiele łańcuchów.

Podatność była szczególnie niebezpieczna, ponieważ uderzała bezpośrednio w integralność księgi, zgodność sald między warstwami systemu oraz bezpieczeństwo aktywów użytkowników. W środowiskach blockchainowych tego typu błędy należą do najpoważniejszych kategorii zagrożeń, ponieważ ich skutki mogą wykraczać poza pojedynczy kontrakt lub aplikację i wpływać na działanie całej sieci.

W skrócie

Podatność oznaczona jako GHSA-7g4w-cg88-2cq2 dotyczyła wersji Cosmos EVM wcześniejszych niż 0.6.2 oraz zakresu od 0.7.0 do 0.7.1 włącznie. Poprawki opublikowano 19 sierpnia 2026 roku w wydaniach 0.6.2 i 0.7.2, jednak luka została następnie aktywnie wykorzystana między 20 a 25 sierpnia 2026 roku.

zagrożone były liczne wdrożenia korzystające ze współdzielonego modułu Cosmos EVM;
ataki objęły sześć łańcuchów;
możliwe skutki obejmowały drenaż aktywów, zakłócenie działania sieci oraz trwałą niespójność stanu;
eksploatacja nastąpiła po publicznym ujawnieniu informacji ułatwiających analizę poprawki.

Kontekst / historia

Z dostępnych informacji wynika, że zgłoszenie podatności trafiło do programu bug bounty 25 kwietnia 2026 roku. Początkowo uznano, że problem nie wpływa bezpośrednio na środki w działających sieciach, między innymi dlatego, że nie udało się odtworzyć błędu w określonej konfiguracji związanej z precyzją tokenów.

Sytuacja zmieniła się do 13 sierpnia 2026 roku, kiedy potwierdzono, że podatność dotyczy wszystkich łańcuchów korzystających z Cosmos EVM, niezależnie od konfiguracji liczby miejsc dziesiętnych. Mimo to poprawka trafiła do procesu cichej publikacji, zamiast zostać objęta w pełni prywatną koordynacją z operatorami wszystkich zagrożonych sieci.

Dodatkowym problemem był brak pełnego rejestru wdrożeń downstream, co utrudniło szybkie poinformowanie wszystkich podmiotów korzystających z podatnego modułu. W praktyce oznaczało to, że szczegóły umożliwiające odtworzenie ścieżki ataku stały się publicznie dostępne bardzo szybko po publikacji wydań z poprawką, a pierwsze przypadki wykorzystania luki odnotowano jeszcze przed zakończeniem szerokiej akcji prywatnych ostrzeżeń.

Analiza techniczna

Źródłem błędu była niespójność pomiędzy sposobem śledzenia salda konta w warstwie EVM a modelem stanu finansowego utrzymywanym przez moduł bankowy Cosmos SDK. Warstwa EVM operowała wyłącznie na saldzie wydawalnym, podczas gdy konta vestingowe przechowują równocześnie środki wydawalne i zablokowane. Kluczowe znaczenie miał również fakt, że mechanizmy stakingu mogły delegować także część środków zablokowanych.

Jeżeli konto vestingowe delegowało więcej niż wynosiło jego saldo wydawalne, logika zapisu po operacji odejmowała pełną wartość delegacji od mniejszego salda widocznego w StateDB. Ponieważ odejmowanie nie było właściwie zabezpieczone przed underflow, dochodziło do zawinięcia wartości i ustawienia salda na liczbę zbliżoną do 2^256. Taki stan mógł następnie zostać użyty podczas procesu uzgadniania pomiędzy warstwą EVM a modułem bankowym.

Skutki różniły się w zależności od gałęzi wersji. W linii 0.6.x anomalie w saldzie mogły prowadzić do przepełnienia podaży i zatrzymania łańcucha. W linii 0.7.x zmiany były zapisywane bezpośrednio w module bankowym, co pozwalało na utrwalenie nieprawidłowych modyfikacji po konwersji typów liczbowych. W praktyce atakujący mógł uzyskać możliwość wyprowadzenia ograniczonej ilości środków z konta z zawiniętym bilansem albo doprowadzić do spalenia realnych aktywów ofiary przez wymuszenie błędnej rekonsyliacji stanu.

Warunkiem powodzenia ataku było także spełnienie określonych warunków po stronie łańcucha, w tym możliwość tworzenia kont vestingowych bez dodatkowych uprawnień. Producent wskazał ponadto, że samo wyłączenie prekompilacji stakingu ogranicza główną ścieżkę nadużycia, ale nie zapewnia pełnej ochrony. Oficjalna poprawka wprowadziła zabezpieczenie przed underflow w funkcji odpowiedzialnej za odejmowanie salda, a jej wdrożenie wymagało skoordynowanej aktualizacji łamiącej stan.

Konsekwencje / ryzyko

Incydent pokazuje, jak wysokie jest ryzyko operacyjne związane ze współdzielonymi komponentami blockchainowymi. Jedna wada logiczna w module używanym przez wiele sieci może jednocześnie prowadzić do utraty aktywów, zatrzymania produkcji bloków, chaosu w procesie aktualizacji oraz trudności z szybkim oszacowaniem realnej skali ekspozycji.

Z perspektywy bezpieczeństwa problemem nie była wyłącznie sama luka, ale również czas pomiędzy potwierdzeniem jej wpływu na środki a skutecznym wdrożeniem ochrony u operatorów. Gdy szczegóły poprawki lub ścieżka eksploatacji stają się publiczne przed zakończeniem prywatnej koordynacji, ryzyko błyskawicznego weaponization znacząco rośnie.

W zdecentralizowanych środowiskach dodatkową trudność stanowi fakt, że część aktualizacji ma charakter state-breaking. Oznacza to konieczność przeprowadzenia nie tylko wdrożenia technicznego, ale również działań governance, synchronizacji walidatorów i zaplanowania operacji sieciowych. Dla zespołów utrzymujących łańcuchy zgodne z EVM w ekosystemie Cosmos to wyraźny sygnał, że błędy rekonsyliacji stanu powinny być klasyfikowane jako podatności krytyczne.

Rekomendacje

Operatorzy łańcuchów korzystających z Cosmos EVM powinni w pierwszej kolejności potwierdzić, czy ich wdrożenia nie opierają się na wersjach wcześniejszych niż 0.6.2 lub na wydaniach 0.7.0–0.7.1. Jeżeli podatne wersje nadal działają produkcyjnie, priorytetem powinno być przejście na 0.6.2, 0.7.2 lub nowsze wydanie w ramach skoordynowanej aktualizacji sieci.

Jeżeli natychmiastowa aktualizacja nie jest możliwa, rozsądniejszym rozwiązaniem może być czasowe zatrzymanie łańcucha niż poleganie wyłącznie na środkach konfiguracyjnych. W środowiskach, w których jest to dopuszczalne, warto też zablokować możliwość tworzenia nowych kont vestingowych, aby usunąć istotny warunek wstępny ataku.

przeprowadzić audyt lokalnych forków i cherry-pickowanych poprawek;
zweryfikować logikę rekonsyliacji pomiędzy warstwą EVM a modułami bankowymi i stakingowymi;
uruchomić testy regresyjne obejmujące konta vestingowe, delegację środków zablokowanych oraz skrajne wartości liczbowe;
monitorować anomalie podaży, nagłe zmiany sald i nietypowe operacje stakingowe;
utrzymywać aktywny kanał kontaktowy do powiadomień bezpieczeństwa od dostawców upstream.

Dla producentów oprogramowania incydent stanowi przypomnienie, że polityka silent patching musi być ściśle dopasowana do realnej klasy ryzyka. Jeżeli wada zagraża środkom w sieciach produkcyjnych, prywatna dystrybucja poprawki i aktywna koordynacja z operatorami downstream powinny mieć pierwszeństwo przed standardowym cyklem publikacji.

Podsumowanie

Luka w Cosmos EVM była krytycznym błędem integralności stanu wynikającym z rozbieżności pomiędzy modelem salda w StateDB a logiką kont vestingowych i stakingu w Cosmos SDK. Eksploatacja umożliwiała wywołanie underflow, uzyskanie nienaturalnie wysokich wartości bilansu oraz, zależnie od wersji, drenaż aktywów lub destabilizację działania sieci.

Incydent potwierdza, że w systemach blockchainowych błędy w księdze i rekonsyliacji stanu powinny być traktowane jako zagrożenia najwyższego priorytetu. Równie ważny jak sama poprawka pozostaje sposób jej koordynacji i dystrybucji do wszystkich operatorów korzystających ze wspólnego komponentu.