Deweloperzy XRP Ledger ujawnili krytyczny błąd przepełnienia, który mógł pozwolić atakującemu na stworzenie XRP z niczego, przekraczając twardy limit sieci wynoszący 100 miliardów tokenów. Błąd dotyczył xrpld, podstawowego oprogramowania serwerowego księgi, w wersjach 3.4.0 i wcześniejszych. Został po cichu załatany we wrześniu, a publicznie ujawniony 9 października 2026 roku. Śledczy nie znaleźli dowodów na to, że był kiedykolwiek wykorzystany w sieci publicznej.

Jak działał błąd

Podatność tkwiła w sposobie, w jaki xrpld sumował kwoty płatności. Gdy pojedyncza płatność korzystała z płynności z wielu ofert na zdecentralizowanej tablicy zleceń, oprogramowanie używało 64-bitowej liczby całkowitej do prowadzenia sumy bieżącej XRP. Jeśli suma przekraczała największą wartość, jaką mogła pomieścić zmienna, zawijała się do wartości znacznie mniejszej niż rzeczywista. Błędy przepełnienia tego typu to klasyczna kategoria wad oprogramowania — arytmetyka przekraczająca stały rozmiar zmiennej przechowującej wynik — i należą do pierwszych zagrożeń, których szukają recenzenci w kodzie obsługującym pieniądze.

Atakujący mógł wykorzystać tę lukę, aby wydać XRP, które nie istniały. Ponieważ zawyżone salda były rozproszone na wielu kontach, istniejące zabezpieczenia księgi nie wykryły rozbieżności — dzięki czemu księgi wyglądały na zrównoważone, podczas gdy faktyczna podaż po cichu rosła.

Koszt przeprowadzenia takiego ataku był zaskakująco niski. Zgodnie z ujawnieniem exploit wymagał specjalnie przygotowanych ofert z setek kont, kosztując jedynie kilkaset XRP w rezerwach i opłatach, z których większość można było odzyskać. Kwota XRP, którą można było wybić w pojedynczej transakcji, mogła przekroczyć całą całkowitą podaż tokena.

Cicha poprawka, potem publiczne ujawnienie

Podatność została zgłoszona 22 września 2026 roku przez badacza Caydena Liao w ramach programu XRPL Bug Bounty. RippleX, deweloperskie ramię Ripple, potwierdził problem i odtworzył atak na odizolowanym serwerze, weryfikując, że nadmiarowe XRP można byłoć w kolejnych transakcjach.

Trzy dni po zgłoszeniu, 25 września 2026 roku, ukazało się awaryjne wydanie: xrpld 3.4.1. Poprawka pominęła również zwykły proces amendment księgi, w ramach którego zmiany zasad sieci normalnie wchodzą w życie dopiero po procedurze głosowania walidatorów. Ta łatka została wdrożona natychmiast.

Publiczne ujawnienie nastąpiło 9 października, około dwa tygodnie po wydaniu załatanego oprogramowania. Zespół poinformował o braku utraty środków, braku skompromitowanych kluczy i braku problemów z konsensusem związanych z błędem. Taka sekwencja odpowiada skoordynowanemu ujawnianiu podatności — standardowej praktyce w bezpieczeństwie oprogramowania polegającej na wydaniu poprawek przed opublikowaniem szczegółów, co daje operatorom czas na aktualizację, zanim informacje mogące poprowadzić atak staną się publiczne. Program XRPL Bug Bounty, z którego pochodziło zgłoszenie, jest częścią tego samego mechanizmu — płaci niezależnym badaczom za prywatne zgłaszanie wad zamiast ich wykorzystywania lub samodzielnego ujawniania.

Dekada w ukryciu

Uważa się, że błąd istniał od czasu pierwszego zbudowania silnika płatności, około 2015 roku — co oznacza, że kod przetwarzał płatności przez lata z utajonym przepełnieniem w środku. Błędy zdolne do zawyżenia natywnego aktywa łańcucha są rzadkie, ale nie bezprecedensowe: w 2018 roku deweloperzy Bitcoin Core wydali awaryjną poprawkę dla wady, która również mogła pozwolić atakującemu na stworzenie bitcoina poza zasadami emisji sieci.

Co to oznacza dla posiadaczy XRP i księgi

Dla posiadaczy XRP bezpośredni wniosek jest uspokajający: nie ma dowodów na to, że błąd został kiedykolwiek wykorzystany, a integralność podaży tokena wydaje się nienaruszona. To wydarzenie jest też przypomnieniem, że twardy limit podaży jest ostatecznie egzekwowany przez kod — i jest tak niezawodny, jak ten kod.

Decyzja o pominięciu procesu amendment zasługuje jednak na uwagę. Znana ścieżka do nieograniczonego tworzenia XRP nie jest czymś, co może czekać na głosowanie nad zarządzaniem, ale awaryjne poprawki pomijające normalne procedury nakładają duże zaufanie na główny zespół deweloperski. W tym przypadku bezpieczeństwo sieci zależało od szybkiej aktualizacji przez walidatorów i operatorów węzłów.

Operatorzy węzłów nadal uruchamiający xrpld w wersji 3.4.0 lub wcześniejszej są najbardziej bezpośrednią grupą docelową tej wiadomości. Załatana wersja 3.4.1 jest dostępna od 25 września, a każdy, kto nie dokonał aktualizacji, korzysta z oprogramowania z obecnie publicznie udokumentowaną wadą naruszającą podaż.

Źródło: CryptoBriefing