Post-mortem MANTRA przypisuje exploit wart 3,6 mln USD błędowi całkowitoliczbowemu w module cosmos/evm
Najważniejsze informacje
- •Napastnik pobrał około 720,9 mln tokenów MANTRA o wartości około 3,6 mln USD podczas incydentu z 20–21 sierpnia.
- •Exploit wynikał z wady niedopełnienia liczby całkowitej we współdzielonym module cosmos/evm, który nie weryfikował sald kont przed odejmowaniem środków.
- •Napastnik użył kontraktu wdrożonego bez pozwolenia i sfinansowanego przez siebie portfela, nie potrzebując uprzywilejowanego dostępu; żadne klucze walidatorów ani mechanizmy zarządzania nie zostały naruszone.
- •Zespół MANTRA nie zauważył nieprawidłowych transakcji przez pierwsze cztery godziny z powodu braku całodobowego monitorowania adresu spalania.
- •Zaangażowano organy ścigania, sieć była zatrzymana przez 30 godzin i 13 minut przed restartem na załatanej wersji v8.4.0, a portfel napastnika zawierał w chwili zatrzymania wciąż 37,96 mln tokenów.

MANTRA Chain w opublikowanym 28 sierpnia pełnym raporcie post-mortem nie zdecydowała się na zobowiązanie do planu odzyskania środków. Publikacja stanowiła natomiast formalne podsumowanie incydentu z 20–21 sierpnia, podczas którego napastnik wybrał z projektu około 720,9 mln MANTRA o wartości około 3,6 mln USD.
Ujawnienie formalnie przypisało wartość dolarową tygodniowemu atakowi, który – jak twierdzi projekt – został spowodowany przez wadę w kodzie niezwiązaną bezpośrednio z własnym kodem MANTRA. MANTRA potwierdziła, że zaangażowano już organy ścigania i że dalsze informacje o działaniach na rzecz odzyskania środków są oczekiwane. Projekt dodał również, że zaktualizuje dane o podaży w obiegu, gdy uzyska jasniejszy obraz tokenów uwięzionych w portfelach hakerów oraz możliwości ich odzyskania.
Co spowodowało exploit MANTRA?
Zgodnie z post-mortem MANTRA Chain exploit rozpoczął się we współdzielonym module cosmos/evm, którego sieć używa do uruchamiania kontraktów w stylu Ethereum na bazie Cosmos SDK.
Dotknięta wersja nie weryfikowała, czy konto pokryje wywołanie, zanim zezwoliła na odejmowanie środków z salda konta. Odejmowania nadal przechodziły, ponieważ kod używał liczb całkowitych bez znaku, które nie mogą spaść poniżej zera. Wartość po prostu „przekręciła się” do ogromnej liczby.
Ten tryb awarii, znany jako niedopełnienie liczby całkowitej (integer underflow) lub wraparound, to od dawna rozpoznana klasa błędów w kodzie blockchainowym. W ekosystemie Ethereum podobne przepełnienie arytmetyczne w kontrakcie ERC-20 stojącym za tokenem Beauty Chain (BEC) w 2018 roku pozwoliło napastnikowi wygenerować ogromne salda tokenów, a takie incydenty były jedną z kluczowych przyczyn wprowadzenia domyślnej arytmetyki sprawdzanej w Solidity 0.8+. Przypadek MANTRA pokazuje, że ta sama klasa wady może ujawnić się w modułach o charakterze mostowym, których sieci oparte na Cosmos SDK używają do współpracy z kontraktami w stylu Ethereum.
MANTRA wyjaśniła, że żaden z kluczy walidatorów, mechanizmów zarządzania ani podpisujących multisig nie został naruszony, i podkreślała, że wada wykorzystana przez napastnika nie pochodziła z jej strony. MANTRA napisała, że „napastnik nie potrzebował żadnego uprzywilejowanego dostępu”, zauważając, że do przeprowadzenia ataku wystarczyły kontrakt wdrożony bez pozwolenia oraz sfinansowany przez siebie portfel.
Ile straciła MANTRA?
Według MANTRA napastnik pobrał około 600 mln MANTRA z adresu spalania oraz kolejne 120,9 mln tokenów z uśpionego multisigu z ery genesis, związanego ze starą kampanią motywacyjną.
MANTRA podkreśliła techniczny charakter wpływu ataku, twierdząc, że nie wyemitowano żadnych nowych tokenów. Zamiast tego exploit uwolnił do obiegu około 720,9 mln tokenów, które znajdowały się poza podażą w obiegu i były uważane za ekonomicznie nieaktywne.
Raport odnotował również programowy rytm ruchów tokenów – transakcje wydawały się wykonywać w ustalonych rozmiarach w krótkich odstępach, a nie być przetwarzane ręcznie.
MANTRA nie zauważyła transakcji w czasie rzeczywistym
Z własnego przyznania, zespół MANTRA nie wykrył żadnych nieprawidłowych transakcji przez pierwsze cztery godziny naruszenia. Projekt przypisał to zaniedbanie brakowi całodobowego monitorowania adresu spalania, który miał przechowywać nieruchome tokeny. Ta luka jest dobrze znana z post-mortemów w całej branży – adresy spalania i portfele skarbowe są często traktowane jako nieaktywne i monitorowane mniej uważnie niż aktywne portfele hot, mimo że często zawierają jedne z największych sald w protokole.
W godzinach, zanim zespół zauważył sygnały ostrzegawcze, napastnik wykonał dwie transakcje i przeniósł większość łupu poza łańcuch, zanim walidatorzy zatrzymali sieć o 23:13 UTC, 14 minut po drugim osuszeniu. Portfel napastnika zawierał wciąż 37,96 mln tokenów w momencie zatrzymania sieci.
Sieć pozostawała offline przez 30 godzin i 13 minut, aż do 05:26 UTC 22 sierpnia, kiedy walidatorzy skoordynowali restart na załatanej wersji v8.4.0.
Ten epizod wieńczy dramatyczne 18 miesięcy dla projektu, który wciąż próbuje odbudować zaufanie. Dawny token OM MANTRA stracił ponad 90% wartości w jednej sesji w kwietniu 2025 roku, wymazując ponad 5 mld USD wartości, co Cryptopolitan opisywało wówczas na bieżąco. Nawet Inveniam Capital Partners, które zainwestowało w MANTRA 20 mln USD w 2025 roku, przyznało się do przeszłych problemów, gdy w czerwcu zgodziło się przejąć projekt.
Gdy doszło do pierwszego zatrzymania, token spadł o 18,5% do rekordowo niskiego poziomu blisko 0,004126 USD, zanim się odbił, według danych CoinGecko. Przy zaangażowanych organach ścigania i nierozstrzygniętych perspektywach odzyskania środków, kluczowe pytania obserwatorów MANTRA dotyczą losu 37,96 mln tokenów wciąż znajdujących się w portfelu napastnika w momencie zatrzymania sieci, tego, czy zarząd wspierany przez Inveniam dostosuje ujawnianie danych o podaży, oraz tego, jak szybko zostaną wydane kolejne zaplanowane aktualizacje modułów projektu.