Deweloperzy XRP Ledger ujawnili krytyczną lukę, która mogła pozwolić atakującemu na wykreowanie z niczego XRP nadających się do wydania, z pominięciem zabezpieczeń zaprojektowanych tak, aby zapobiegać zwiększaniu podaży kryptowaluty.

Błąd znajdował się w silniku płatności księgi i został zgłoszony 22 września za pośrednictwem programu XRPL Bug Bounty przez Caydena Liao i Veria AI. Inżynierowie RippleX odtworzyli exploit na samodzielnym serwerze, potwierdzili, że nowo utworzone XRP można było wydać w kolejnej płatności, i podnieśli jego wagę z poważnej do krytycznej. Sposób obsługi zgłoszenia odpowiada standardowej praktyce skoordynowanego ujawniania: zgłoszenia z programu bug bounty trafiają do opiekunów prywatnie, a pełne szczegóły techniczne publikuje się dopiero po udostępnieniu poprawki.

Zgodnie z raportem ujawnienia opublikowanym na oficjalnym blogu XRPL nie ma dowodów na to, że luka została wykorzystana w jakiejkolwiek publicznej sieci XRP Ledger. Deweloperzy prywatnie przygotowali poprawkę i udostępnili wersję 3.4.1 programu xrpld 25 września, dwa dni po tym, jak łatka została scalona z gałęzi wydania awaryjnego.

Przepełnienie liczby całkowitej mogło ominąć kontrole podaży XRP

Błąd istniał w silniku płatności XRP Ledger od około 2015 roku i dotyczył niekontrolowanej arytmetyki 64-bitowych liczb całkowitych w sytuacji, gdy płatność konsumowała wiele ofert z arkusza zleceń sieci.

Liczba 64-bitowa osiąga maksimum bliskie 18,4 trylionów, a przepełnienia w tego rodzaju arytmetyce o stałej szerokości to znana klasa błędów w oprogramowaniu ksiąg — w 2010 roku przepełnienie liczby całkowitej w kontrolach wartości Bitcoina przez krótki czas utworzyło około 184 miliardów BTC, zanim deweloperzy załatali błąd w ciągu kilku godzin.

Atakujący mógł utworzyć setki kont i złożyć specjalnie skonstruowane oferty sprzeda małych ilości innego tokena za ekstremalnie duże kwoty XRP. Pojedyncza płatność konsumująca te oferty mogła przekroczyć maksymalną wartość obsługiwaną przez liczbę całkowitą. Zamiast odrzucić transakcję, suma zapętlała się do małej liczby. Każdy właściciel oferty mógł nadal otrzymać pełną kwotę XRP określoną w jego ofercie, podczas gdy kupujący był obciążany jedynie znacznie mniejszą, zapętloną wartością.

Atak wymagał jedynie kilkuset XRP na rezerwy kont i ofert, z których duża część mogła później zostać odzyskana, plus zwykłych opłat transakcyjnych.

Wbudowana w XRPL kontrola, której celem było zapewnienie, że transakcje nie mogą tworzyć XRP, nie zatrzymałaby exploitu. Niezmiennik używał tego samego typu arytmetyki i mógł przepełnić się w ten sam sposób, natomiast oddzielny limit salda na konto można było ominąć, rozdzielając nowo utworzone XRP na setki kont. Kruchość ta miała znaczenie ze względu na działanie podaży XRP: wszystkie 100 miliardów tokenów zostało utworzonych przy uruchomieniu księgi, opłaty transakcyjne spalają XRP, a nie emitują je, a kontrole niezmienników są gwarancją, że żadna ścieżka płatności nie może zwiększyć całkowitej podaży. Luga była ograniczona do celowo skonstruowanych transakcji i nie mogła zostać wyzwolona przez normalne płatności ani działalność handlową.

Walidatorzy przeszli na 3.4.1 w ciągu kilku godzin

Deweloperzy zdecydowali się wdrożyć poprawkę przepełnienia natychmiast, zamiast kierować ją przez zwykły proces poprawek XRPL, który zwykle wymaga ponad 80% wsparcia walidatorów przez dwa tygodnie, zanim zmiana protokołu zostanie aktywowana. Pozostawienie luki odkrytej przez ten cały okres stworzyłoby okno, w którym metoda ataku byłaby publicznie znana, ale wciąż użyteczna.

Ponad 80% walidatorów na domyślnej liście Unique Node List zaktualizowało do 3.4.1 25 września, tego samego dnia, w którym wydano wersję awaryjną. Trzydniowy okres od prywatnego zgłoszenia do adopcji przez większość walidatorów pokazał awaryjną ścieżkę wydawniczą księgi działającą od początku do końca.

Wersja 3.4.1 odrzuca teraz płatności, gdy suma ofert uległaby przepełnieniu, i używa szerszego licznika dla niezmiennika tworzenia XRP. Dodatkowe obliczenia sald zostały również wzmocnione wobec podobnych awarii arytmetycznych.

Incydent nastąpił po niezwiązanym z tym naruszeniu łańcucha dostaw xrpl.js odkrytym w 2025 roku, które dotyczyło złośliwych wydań pakietów JavaScript, a nie samego protokołu XRP Ledger. System poprawek XRPL jest również wykorzystywany dla nowszych funkcji, takich jak proponowany XRPL Lending Protocol, w którym zgoda walidatorów decyduje o aktywacji nowych zachowań transakcyjnych.

Luga przepełnienia nie zmieniła istniejącej podaży XRP. Nie zidentyfikowano żadnych nieautoryzowanych XRP, a operatorzy serwerów muszą teraz uruchamiać xrpld w wersji 3.4.1 lub nowszej, aby pozostać zsynchronizowanymi z siecią. Obserwowalne pozostają aspekty operacyjne: podmioty pozostające na starszych wydaniach przechodzą na 3.4.1 lub nowsze oraz propozycje takie jak XRPL Lending Protocol kontynuowane przez standardową ścieżkę poprawek, którą ta poprawka pominęła.

Źródło: XRP Ledger Patches Decade-Old Flaw That Could Create Spendable XRP — Crypto Adventure