Fundacja XRP Ledger wyjaśniła, w jaki sposób deweloperzy i walidatory zareagowali na podatność, która mogła pozwolić atakującemu na utworzenie wydawalnego XRP za pomocą specjalnie skonstruowanej płatności. Fundacja stwierdziła, że nie utworzono żadnego XRP poprzez ten błąd i nie ma dowodów na jego wykorzystanie w sieci publicznej.

Komunikat z 11 października koncentrował się na reakcji, a nie na powtarzaniu mechaniki podatności. Wcześniejsze wyjaśnienie błędu znajduje się w relacji Coindoo. Techniczny raport ujawniający Fundacji jest dostępny na stronie XRP Ledger.

Publiczne dane księgi potwierdzają twierdzenie o podaży

XRP wystartował ze stałą podażą 100 miliardów, a opłaty transakcyjne są z czasem niszczone. Fundacja podała, że obecnie istnieje około 99,986 miliarda XRP.

Techniczny raport ujawniający stwierdził, że zespół nie znalazł dowodów na wykorzystanie podatności w sieci publicznej. To twierdzenie można zweryfikować wobec zwalidowanej historii transakcji i sald kont w XRP Ledger, które są publicznie dostępne do niezależnego przeglądu za pośrednictwem eksploratorów i innych usług danych.

„Nie musisz nam w ufać” – napisała Fundacja. Nowe XRP pojawiłyby się na saldach kont, ponieważ w XRP Ledger nie ma ukrytego obszaru sald. Fundacja stwierdziła, że stale monitoruje księgę i zweryfikowała podaż w całej historii sieci, a inni członkowie społeczności przeprowadzili własne kontrole.

Publiczne rejestry nie mogą ujawnić każdej prywatnej rozmowy przed ujawnieniem błędu ani ustalić intencji stojącej za atakiem, który nigdy nie został przesłany do sieci. Mogą jednak pokazać zwalidowane transakcje, widoczne zmiany sald i zarejestrowaną podaż. Te informacje stanowią podstawę do podważania twierdzeń, że duże ilości XRP zostały potajemnie wyemitowane i ukryte w sieci.

Dlaczego poprawka została wydana przed technicznym ujawnieniem

Zgodnie ze standardowym procesem zarządzania XRP Ledger zmiany zasad transakcyjnych są wprowadzane poprzez poprawki (amendments). Walidatory muszą utrzymywać ponad 80% poparcia przez dwa tygodnie, zanim poprawka wejdzie w życie. Ten proces daje operatorom czas na aktualizację i pozwala sieci przyjąć zmianę w tym samym punkcie.

Poprawka przepełnienia poszła inną drogą, ponieważ podatność uznano za aktywne ryzyko. Zgodnie z raportem ujawniającym opublikowanie kodu ujawniającego dokładny błąd, zanim starsze serwery zostały zabezpieczone, mogło ułatwić identyfikację ścieżki ataku. Wersja 3.4.1 zastosowała więc ochronę w miarę aktualizacji poszczególnych serwerów, zamiast czekać na normalny publiczny proces poprawek.

Fundacja podsumowała swoje wyjaśnienie w poście na X:

The recent XRP Ledger security fix raised a lot of questions and some misconceptions. Let’s clear them up.

1. Was any XRP created?

No. XRP’s supply was fixed at 100 billion when the XRP Ledger launched, and no transaction is allowed to create more. This bug was a way around that rule, and 3.4.1 fixed it 2 weeks ago.

You don’t need to trust us on this. All ledger data is public, and explorers and data sites read it every day. New XRP would show up in account balances for everyone to see. There is no hidden place for XRP on the XRP Ledger, every balance is public.

We monitor the XRP Ledger 24/7 and have verified the supply throughout the history of the ledger. Others in the community verified this too, and anyone can do the same.

Transaction fees are destroyed, so the supply is deflationary. About 99.986 billion XRP exist today.

1. How did this go unnoticed, and what’s next?

No normal payment comes anywhere near triggering it. It took hundreds of deliberately constructed operations.

AI makes bugs like this faster to find, for the bad guys and the good guys.

Together with RippleX and the community, we will ensure the XRP Ledger is protected against such vulnerabilities. This means radically applying Formal Verification and AI adversarial testing, collaborating closely with security researchers, and strengthening the bug bounty program.

You’ll hear a lot more about this as we progress.

1. XRP Ledger decentralization at the core of this.

A public fix shows attackers where the bug is, and AI makes that fast. With a normal amendment vote, the fix would have been public for weeks before it effect, risking network security.

As a reaction to this, the XRPL community came together, and among them the XRP Ledger Foundation, RippleX, core devs and validators formed a social consensus and agreed on a path forward that involves shipping the fix directly. Patching a live network is never trivial, so the plan was also designed to minimize disruption for everyone running on it.

We shared the build with the default UNL validators, using the contact details each one publishes in its xrp-ledger.toml file. Public binaries followed the same day, September 25.

No single party could make that call alone. Every validator and node operator chooses what software to run, and 3.4.1 only became required through a normal amendment vote with more than 80% validator support for two weeks. Protocol changes still go through amendments.

Big thanks to Cayden Liao and Veria AI for finding and reporting this responsibly, to the XRPL core developers for building and testing the fix, and to every node operator who upgraded so quickly, especially the validators.

Full report:

— XRP Ledger Foundation (@XRPLF) October 11, 2026

Fundacja określiła bezpośrednie wydanie oprogramowania jako wyjątkową reakcję, a nie zastępstwo zwykłego zarządzania. Jej raport stwierdził, że była to pierwsza świadoma bezpośrednia zmiana przetwarzania transakcji od wprowadzenia systemu poprawek ponad dekadę temu. Przyszłe zmiany protokołu, jak podano, nadal będą wymagać poprawek popieranych przez walidatory.

Walidatory zachowały kontrolę nad instalacją oprogramowania

Fundacja stwierdziła, że udostępniła poprawioną wersję operatorom walidatorów default-UNL przed wydaniem publicznych plików binarnych 25 września. Ci operatorzy sami zdecydowali, czy uruchomić nową wersję. Ani Fundacja, ani RippleX nie mogły wymusić aktualizacji na niezależnie zarządzanych serwerach.

Stworzyło to krótki okres, w którym zabezpieczone i niezabezpieczone serwery stosowały różne zasady dla wyspecjalizowanej ścieżki płatności. Zgodnie z raportem XRPL próba wykorzystania błędu w tym okresie mogła spowodować rozbieżności między wersjami i potencjalnie zakłócić walidację. Zespół ocenił to ryzyko jako preferowalne wobec pozostawienia otwartego, potencjalnie nieodwracalnego ataku inflacyjnego przez dłuższy publiczny okres aktywacji.

Reakcja była koordynowana przez XRP Ledger Foundation, RippleX, głównych deweloperów i walidatory, ale żadna pojedyncza organizacja nie mogła podjąć decyzji samodzielnie. Każdy walidator i operator węzła sam wybiera, jakie oprogramowanie uruchamia, a system poprawek pozostaje mechanizmem nadawania zmianom protokołu charakteru obowiązkowego.

Co ujawnienie oznacza dla użytkowników i operatorów

Raport nie nakazywał posiadaczom XRP przenoszenia środków ani wymiany portfeli. Dla operatorów węzłów XRPL podał, że serwery powinny uruchamiać xrpld w wersji 3.4.1 lub nowszej, aby pozostać zsynchronizowane z siecią. W praktyce wskazane środki zaradcze dotyczyły oprogramowania utrzymującego infrastrukturę księgi, a nie działania żądanego od posiadaczy XRP.

Fundacjała również, że zwykła płatność nie zbliżyłaby się do wyzwolenia podatności. Wykorzystanie błędu wymagało setek specjalnie skonstruowanych operacji. Podkreślono też, że sztuczna inteligencja może przyspieszać znajdowanie podatności zarówno dla atakujących, jak i obrońców.

Planowane środki bezpieczeństwa

Fundacja stwierdziła, że planuje rozszerzyć stosowanie formalnej weryfikacji i testów adwersaryjnych z użyciem AI, ściślej współpracować z zewnętrznymi badaczami bezpieczeństwa oraz wzmocnić swój program bug bounty. Środki te nie mogą zagwarantować, że żaden krytyczny problem się nie pojawi, ale mają zwiększyć szanse na wykrycie podatności przed wydaniem produkcyjnym.

Raport ujawniający opisuje również środek kontroli wydań. Ustalenia bezpieczeństwa oznaczone jako naprawione powinny być ponownie testowane wobec kandydata wydania zawierającego poprawkę, a pierwotnie zgłoszony problem powinien zostać odtworzony przed zamknięciem ustalenia. Ten proces daje zewnętrznym badaczom zdefiniowany standard, według którego można oceniać kolejne wydania.

Podatność ujawniła poważną słabość w regule mającej chronić stałą podaż XRP. Reakcja pozostawiła po sobie publiczny ślad: raport bug bounty, przyspieszoną aktualizację walidatorów, późniejsze techniczne ujawnienie oraz zobowiązania do wzmocnienia praktyk bezpieczeństwa. To, w jakim stopniu te zobowiązania staną się rutynową częścią przyszłych procedur wydawniczych, zdecyduje o długoterminowym znaczeniu tego incydentu.

Ten artykuł ma charakter wyłącznie informacyjny i nie stanowi porady inwestycyjnej. Szczegóły wydań oprogramowania i ujawnień dotyczących bezpieczeństwa mogą ulec zmianie w miarę udostępniania dalszych informacji technicznych.

Źródło: Coindoo.