Wprowadzenie do problemu / definicja
W ekosystemie blockchain opartym na Cosmos wykryto krytyczną podatność w komponencie Cosmos EVM, który odpowiada za połączenie środowiska Ethereum Virtual Machine z mechanizmami Cosmos SDK. Błąd dotyczył obsługi sald kont i mógł prowadzić do nieautoryzowanego wygenerowania skrajnie wysokich wartości bilansowych, co otwierało drogę do kradzieży środków, manipulacji stanem oraz zakłócenia działania sieci.
Znaczenie incydentu zwiększa fakt, że podatność została wykorzystana już po opublikowaniu poprawek. To pokazuje, jak niebezpieczne może być okno czasowe pomiędzy ujawnieniem zmian w kodzie a pełnym wdrożeniem aktualizacji przez operatorów podatnych łańcuchów.
W skrócie
- Krytyczna luka została oznaczona jako GHSA-7g4w-cg88-2cq2.
- Problem dotyczył wersji Cosmos EVM wcześniejszych niż 0.6.2 oraz wersji od 0.7.0 do 0.7.1.
- Poprawki opublikowano 19 sierpnia 2026 roku w wydaniach 0.6.2 i 0.7.2.
- Między 20 a 25 sierpnia 2026 roku luka została wykorzystana przeciwko sześciu blockchainom.
- Mechanizm ataku opierał się na underflow podczas odejmowania wartości od salda w modelu EVM StateDB.
- Producent zalecił natychmiastową aktualizację, a w części scenariuszy nawet zatrzymanie łańcucha do czasu wdrożenia poprawki.
Kontekst / historia
Podatność została zgłoszona w programie bug bounty już 25 kwietnia 2026 roku. Początkowo uznano ją za problem o ograniczonym znaczeniu dla sieci produkcyjnych, ponieważ testy nie potwierdziły skutecznego scenariusza ataku we wszystkich analizowanych wdrożeniach. Z czasem ustalenia uległy zmianie i do 13 sierpnia 2026 roku stwierdzono, że zagrożenie obejmuje wszystkie łańcuchy korzystające z Cosmos EVM.
Poprawka była wdrażana w modelu ograniczonego ujawnienia technicznych szczegółów. W praktyce nie zapobiegło to analizie zmian w kodzie i odtworzeniu wektora ataku przez osoby trzecie. Pierwsze znane wykorzystanie luki nastąpiło już 20 sierpnia 2026 roku, czyli mniej niż dobę po publikacji nowych wersji.
Analiza techniczna
Sedno problemu wynikało z rozbieżności między dwoma modelami przechowywania stanu konta. Cosmos EVM utrzymuje widok salda w EVM StateDB, który obejmuje jedynie część wydawalną, podczas gdy Cosmos SDK może uwzględniać również środki zablokowane, na przykład na kontach vestingowych. Dodatkowo mechanizmy stakingu mogły dopuszczać delegowanie także tej części środków, która nie była dostępna do zwykłego wydania.
Jeżeli konto vestingowe delegowało więcej niż wynosiło saldo widoczne jako wydawalne w StateDB, proces synchronizacji próbował odjąć większą wartość od mniejszej. Brak skutecznej ochrony przed underflow powodował zawinięcie liczby całkowitej do ogromnej wartości zbliżonej do 2^256. W efekcie atakujący mógł uzyskać sztucznie zawyżony bilans i wykorzystać go do dalszych operacji finansowych lub destabilizacji stanu sieci.
Opublikowane poprawki nie ograniczały się wyłącznie do jednego zabezpieczenia. Obejmowały także zmiany związane z poprawnym odtwarzaniem zablokowanych sald oraz ochroną kont modułowych. To istotne, ponieważ częściowe przeniesienie patcha do forka mogło pozostawić aktywną podatną ścieżkę wykonania mimo pozornie poprawnych wyników testów.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem podatności była możliwość bezpośredniej utraty środków przez użytkowników i protokoły działające na podatnych blockchainach. W zależności od konkretnej linii wersji exploit mógł prowadzić zarówno do trwałego zaakceptowania zmanipulowanych zmian stanu, jak i do problemów z podażą aktywów czy nawet zatrzymania łańcucha.
Ryzyko miało również wymiar operacyjny i systemowy. W środowisku blockchain incydent tego typu wpływa nie tylko na bezpieczeństwo aplikacyjne, ale także na ciągłość działania, reputację sieci, zaufanie użytkowników oraz konieczność przeprowadzenia awaryjnych, skoordynowanych aktualizacji przez walidatorów.
Przypadek Cosmos EVM pokazuje też słabości bezpieczeństwa łańcucha dostaw w projektach open source. Gdy jeden podatny komponent jest używany przez wiele niezależnych sieci i forków, każda zwłoka w komunikacji, inwentaryzacji wdrożeń i aktualizacji zwiększa prawdopodobieństwo szerokiego wykorzystania exploita.
Rekomendacje
Operatorzy sieci korzystających z Cosmos EVM powinni w pierwszej kolejności potwierdzić wykorzystywaną wersję komponentu i zweryfikować, czy środowisko zostało zaktualizowane przynajmniej do 0.6.2 albo 0.7.2. Tę zmianę należy traktować jako aktualizację krytyczną, mogącą wpływać na stan łańcucha, a więc wymagającą ścisłej koordynacji wdrożenia.
Jeżeli szybkie wdrożenie nie jest możliwe, rozsądniejszym rozwiązaniem może być czasowe zatrzymanie produkcji bloków niż poleganie wyłącznie na procedurach governance. W niektórych architekturach warto także ograniczyć warunki niezbędne do eksploatacji, na przykład przez zablokowanie tworzenia określonych typów kont vestingowych.
- przeprowadzić przegląd forków i lokalnych modyfikacji pod kątem niespójnych helperów oraz zdublowanych ścieżek kodu,
- testować poprawki na forku stanu produkcyjnego, a nie wyłącznie w środowisku testów jednostkowych,
- utrzymywać prywatne kanały komunikacji bezpieczeństwa z dostawcami upstream,
- budować pełną inwentaryzację komponentów krytycznych w łańcuchu dostaw,
- wdrożyć monitoring anomalii dotyczących sald, stakingu i podaży tokenów.
Podsumowanie
Luka w Cosmos EVM to przykład błędu, który na poziomie kodu wygląda jak klasyczny problem underflow, ale w praktyce może przełożyć się na realne straty finansowe i poważne zakłócenia działania całych blockchainów. Incydent podkreśla, że w rozproszonych ekosystemach opartych na współdzielonych komponentach samo opublikowanie poprawki nie kończy problemu.
Najważniejsze wnioski dla operatorów i zespołów bezpieczeństwa są jednoznaczne: szybka identyfikacja podatnych wersji, pełne wdrożenie aktualizacji, testy na rzeczywistych ścieżkach wykonania oraz gotowość do awaryjnego reagowania muszą być standardem wszędzie tam, gdzie błąd może wpływać na środki użytkowników i integralność stanu sieci.
Źródła
- https://thehackernews.com/2026/08/cosmos-evm-flaw-exploited-after-cosmos.html
- https://github.com/cosmos/evm/security/advisories/GHSA-7g4w-cg88-2cq2
- https://github.com/cosmos/evm/pull/1187
- https://github.com/cosmos/evm/releases/tag/v0.7.2
- https://github.com/cosmos/evm/releases/tag/v0.6.2