Podatność obecna w XRP Ledger od około dekady pozwalałaby atakującym utworzyć możliwe do wydania XRP bez ponoszenia kosztów, zagrażając sztywnej podaży kryptowaluty wynoszącej 100 miliardów tokenów. Ten limit jest fundamentem aktywa: wszystkie 100 miliardów XRP istniało od uruchomienia ledgera, a zasady protokołu są zbudowane tak, aby przenosić tokeny między posiadaczami, a nie emitować nowe. Zespół deweloperski Ripple wydał awaryjną aktualizację oprogramowania, aby usunąć lukę, a badacze nie znaleźli dowodów na to, że została kiedykolwiek wykorzystana w sieciach publicznychn
Błąd ujawniono 9 października 2026 r., a według doniesień sięga on 2015 roku. Badacze Cayden Liao i Veria AI odkryli problem w ramach programu bug bounty XRP Ledger i zgłosili go 22 września. Takie programy są filarem bezpieczeństwa kryptowalut, dając zewnętrznym badaczom prywatny kanał do przekazywania luk deweloperom, zanim szczegóły staną się publiczne. RippleX, dział deweloperski Ripple, odtworzył atak i potwierdził, że nowo utworzone XRP można było wydać w kolejnych transakcjach.

Jak działał błąd podaży XRP

Istotą luki było przepełnienie liczby całkowitej (integer overflow) w silniku płatności XRP Ledger — klasyczna wada oprogramowania, w której wynik obliczeń przekracza stały rozmiar liczby, która go przechowuje. Ledger przetwarza transakcje poprzez wbudowaną giełdę, na której użytkownicy składają oferty wymiany jednego aktywa na inne.

Atakujący mógł wykorzystać ten mechanizm, tworząc setki kont i składając oferty dotyczące nietypowo dużych kwot XRP. Pojedyncza starannie skonstruowana płatność mogła następnie zużyć wszystkie te oferty jednocześnie.

Podczas sumowania łącznej kwoty XRP należnej z tytułu zużytych ofert liczbowy licznik silnika płatności mógł zostać wypchnięty poza maksymalną reprezentowalną wartość, coodowało zawinięcie sumy do znacznie mniejszej liczby. W efekcie konta sprzedające otrzymywały pełne płatności, a kupujący płacił jedynie błędnie obliczoną kwotę — rozbieżność ta skutecznie tworzyłaby nowe XRP.

Istniejący w ledgerze zabezpieczenia, mające wykrywać nieautoryzowane tworzenie XRP, również opierały się na obliczeniach podatnych na to samo przepełnienie i w związku z tym mogły nie wykryć nowo utworzonych tokenów. RippleX potwierdził, że przeprowadzenie ataku wymagałoby jedynie kilkuset XRP na założenie niezbędnych kont, wraz z opłatami transakcyjnymi.

Awaryjna poprawka ominęła zwykły proces głosowania

Ripple wydał 25 września oprogramowanie serwerowe XRP Ledger w wersji 3.4.1, aby usunąć podatność. W przeciwieństwie do konwencjonalnych zmian protokołu, poprawka silnika płatności weszła w życie w miarę aktualizowania serwerów przez poszczególnych operatorów. Oficjalne ujawnienie opublikowano na blogu XRP Ledger pod adresem około dwa tygodnie po wydaniu — odstęp zgodny z normami skoordynowanego ujawniania, zgodnie z którymi poprawki trafiają do użytku najpierw, aby operatorzy mog chronić swoje systemy, zanim szczegóły ataku staną się publiczne.

Ta decyzja stanowiła wyjątkowe odstępstwo od standardowego procesu zmian (amendment) w ledgerze, który zazwyczaj wymaga ponad 80% poparcia zaufanych walidatorów utrzymanego przez dwa tygodnie — mechanizmu zaprojektowanego tak, aby żadna pojedyncza strona nie mogła jednostronnie przepisać zasad ledgera. RippleX wyjaśnił, że przestrzeganie normalnego procesu mogłoby publicznie ujawnić podatność, podczas gdy sieć pozostawałaby zagrożona w okresie głosowania i aktywacji. Zgodnie z oficjalnym ujawnieniem ponad 80% domyślnych zaufanych walidatorów zaktualizowało się już w dniu wydania.

Raport o podatności, opublikowany 9 października, potwierdził, że śledczy nie znaleźli dowodów wykorzystania luki w sieciach publicznych. Incydent podkreśla wartość niezależnych badań bezpieczeństwa i szybkiej koordynacji w infrastrukturze kryptowalut. Wpisuje się też w znajomy wzorzec branżowy: w 2018 roku deweloperzy Bitcoin Core po cichu załatali błąd konsensusu, który mógł pozwolić górnikowi na zwiększenie podaży Bitcoina.

Choć Ripple opanował bezpośrednie zagrożenie, incydent rodzi szersze pytania o to, jak zdecentralizowane sieci powinny równoważyć awaryjne środki bezpieczeństwa z przejrzystym zarządzaniem. RippleX podkreślił, że wyjątkowa reakcja nie zmienia ustalonego podejścia ledgera do przyszłych zmian protokołu.