Огляд
Критична вразливість XRP Ledger, яка залишалася в платіжному рушії близько десяти років, теоретично могла дозволити зловмиснику створити витратні XRP поза межами передбачених правил емісії реєстру. XRPL розкрила цю проблему 9 жовтня 2026 року після того, як про неї приватно повідомили через Програму винагород за помилки XRPL 22 вересня. Вразливість впливала на xrpld 3.4.0 і попередні версії та була виправлена в xrpld 3.4.1, випущеній 25 вересня.
Вразливість XRP Ledger включала цілочисельне переповнення, коли платіж споживав сотні спеціально сконструйованих пропозицій книги ордерів. Окремі власники пропозицій могли отримати свої повні суми XRP, тоді як з покупця стягувалася лише невелика сума після циклічного переповнення. Серйозніше те, що існуючий інваріант реєстру «жодних XRP не створено» використовував подібний арифметичний шлях і міг переповнитися так само, що заважало цій перевірці безпеки виявити розбіжність.
XRPL заявляє, що не знайшла жодних доказів того, що вразливість була використана в будь-якій публічній мережі, і звичайні платежі не могли випадково її спровокувати. Атака вимагала навмисно сконструйованих пропозицій з економічно нереалістичними цінами. Тим не менш, інцидент порушує глибше питання безпеки: фіксована монетарна політика блокчейну є настільки сильною, наскільки програмне забезпечення, яке забезпечує кожен перехід балансу.
Ключові висновки
- Помилка, схоже, існувала з моменту написання поточного платіжного рушія XRPL у 2015 році.
- Навмисно сконструйована транзакція теоретично могла створити витратні XRP.
- XRPL не знайшла жодних доказів використання в публічній мережі.
- Існуючий інваріант емісії міг не спрацювати, оскільки він відтворював ту саму поведінку переповнення.
xrpld 3.4.1додав перевірену арифметику та сильнішу незалежну перевірку емісії.
Що являла собою вразливість XRP Ledger?
Вразливість полягала в обробці ліквідності книги ордерів платіжним рушієм XRP Ledger. Коли платіж проходить через кілька пропозицій, рушій повинен обчислити, скільки XRP загалом заборгував платник. Кожна окрема сума могла бути дійсною, але агреговане обчислення використовувало 64-бітне ціле число без достатнього захисту від переповнення.
За звичайних умов це було практично недосяжно. Нормальна емісія XRP та реальні ринкові ціни навіть близько не наближаються до числової межі, необхідної для переповнення лічильника. Проблема виникала лише тоді, коли зловмисник навмисно конструював сотні пропозицій, у яких кожен обліковий запис вимагав надзвичайно велику суму XRP за крихітну кількість іншого токена.
Шкідливий потік міг виглядати приблизно так:
- Створити кілька сотень контрольованих облікових записів.
- Розмістити навмисно нереалістичні пропозиції з цих облікових записів.
- Сконструювати один платіж, призначений для споживання цих пропозицій разом.
- Вивести агреговане обчислення XRP за межу цілого числа.
- Спричинити циклічне переповнення загальної суми до набагато меншого числа.
Потім рушій міг зарахувати власникам пропозицій окремо, стягуючи з покупця лише переповнену загальну суму. Оскільки зловмисник також міг контролювати облікові записи власників пропозицій, різниця фактично ставала новими XRP.
Інженери XRPL відтворили атаку локально та підтвердили, що отримані XRP згодом можна було передати. Відповідно, проблему було підвищено з рівня «серйозна» до критичного рівня.
Чи могла вразливість XRP Ledger справді створити XRP?
Так, теоретично. Це була не просто помилка відображення бухгалтерського обліку. Технічне розкриття XRPL говорить, що експлойт міг створити XRP, які поводилися як звичайні XRP після валідації шкідливої транзакції. Ці баланси можна було переміщати, торгувати ними або надсилати на біржі.
Це не означає, що XRP історично були надмірно випущені. XRPL повідомляє, що не знайшла жодних доказів того, що експлойт стався в будь-якій публічній мережі. Різниця між цими двома твердженнями є суттєвою: вразливість могла порушити передбачене обмеження емісії, але наразі немає підтвердженої історичної події емісії, пов'язаної з нею.
Атака також не могла статися випадково під час звичайної торгівлі на DEX. Пропозиції книги ордерів мали бути оцінені настільки нереалістично, що звичайна ринкова ліквідність виконалася б раніше, ніж досягла їх. Платіж також мав бути навмисно сконструйований, щоб спожити достатньо цих пропозицій разом, щоб спричинити переповнення.
Тому це найкраще розуміти як шлях виконання з низькою ймовірністю та надзвичайно високим теоретичним впливом, а не як помилку, яку звичайні користувачі XRP могли несвідомо спровокувати.
Чому перевірка безпеки емісії XRPL не спрацювала?
Найважливіша з технічної точки зору частина інциденту полягає не просто в тому, що існувало цілочисельне переповнення. Зріле фінансове програмне забезпечення часто містить кілька захисних шарів, призначених саме для виявлення такого роду несподіваного результату.
XRPL мав один: інваріант транзакції, призначений гарантувати, що транзакція не може створити XRP. В принципі, навіть якби платіжний рушій припустився бухгалтерської помилки, інваріант мав би помітити, що загальні баланси XRP зросли, і відхилити транзакцію.
Він цього не зробив.
Причина — класичний збій так званих незалежних систем безпеки. Інваріант обчислював чисту зміну XRP, використовуючи подібний тип неперевіреної арифметики. Коли платіжний рушій зазнавав переповнення, обчислення інваріанта могло зазнати переповнення в тому самому напрямку, через що результуюча транзакція виглядала так, ніби зміна пропозиції XRP дорівнювала лише звичайній комісії за транзакцію.
Перевірка безпеки не є справді незалежною, якщо вона може відтворити той самий режим збою, що й система, яку вона перевіряє.
Другий захист перевіряв, чи не перевищує баланс окремого рахунку загальну пропозицію XRP. Це також не зупинило атаку, оскільки новостворені XRP можна було розподілити між сотнями рахунків, утримуючи баланс кожного окремого рахунку нижче ліміту.
Тому виправлення стосувалося як безпосередньої помилки, так і захисної архітектури. xrpld 3.4.1 додав явні перевірки переповнення, коли суми агрегуються за пропозиціями та платіжними шляхами. XRPL також змінив інваріант «жодних створених XRP», щоб використовувати ширший лічильник, який не може зациклитися за тих самих умов.
Чому помилка 2015 року залишалася прихованою так довго?
Відповідь частково полягає в різниці між реалістичними економічними значеннями та теоретичними комп'ютерними межами. Окремі платежі XRP здійснюються на багато порядків нижче діапазону, необхідного для переповнення 64-бітної суми. Звичайний трейдер міг користуватися XRPL роками, не створюючи нічого схожого на шкідливі числові умови.
Це робило ваду важкою для виявлення через рутинне використання. Уразлива логіка могла поводитися правильно протягом мільярдів нормальних операцій, але все одно катастрофічно збоювати на штучній межі.
Уразливість також демонструє, чому довгоживучий код блокчейну не слід автоматично вважати безпечним лише тому, що він працював багато років. Історія використання в продакшені є корисною ознакою, але вона переважно перевіряє звичайні стани. Зловмисники навмисно шукають стани, які звичайні користувачі ніколи не створюють.
XRPL зарахував виявлення цієї проблеми своїй програмі Bug Bounty і окреслив ширший підхід до багаторівневого захисту, який включає незалежні аудити, публічні атакатони, фаззинг, red teaming з підтримкою ШІ та формальну верифікацію. Він також додає повторну перевірку виправлень безпеки на кандидатах у релізи, перш ніж знахідки офіційно закриваються.
Цей підхід важливий, тому що урок з цього інциденту не в тому, що зрілому коду не можна довіряти. Він у тому, що зрілий код все ще потребує змагального тестування проти припущень, які розробники перестали ставити під сумнів роками раніше.
Що означає ця помилка для фіксованої пропозиції XRP?
XRP починався з визначеної початкової пропозиції у 100 мільярдів токенів, без протокольного механізму, аналогічного майнінгу proof-of-work, який безперервно створює додаткові XRP. Комісії за транзакції знищуються, а не сплачуються валідаторам, тому передбачений шлях пропозиції є неінфляційним.
Уразливість XRP Ledger виявляє важливу відмінність між монетарною політикою як правилом і монетарною політикою як програмним забезпеченням примусу.
Специфікація блокчейну може стверджувати, що нові XRP не можуть бути створені, але вузли зрештою забезпечують цю властивість через код. Якщо логіку переходу балансу можна маніпулювати так, щоб порушити правило, тоді сама економічна політика може зазнати невдачі, навіть якщо задокументована політика не змінилася.
Цей інцидент не продемонстрував, що фактична пропозиція XRP в обігу була таємно збільшена. XRPL заявляє, що експлуатації публічної мережі не було виявлено. Але він продемонстрував, що до виправлення існував теоретичний шлях виконання, здатний обійти одне з найфундаментальніших монетарних обмежень реєстру.
Це робить цю уразливість більш значущою, ніж тимчасовий збій RPC або проблема з підключенням вузлів. Мережа може витримати певні інфраструктурні збої без шкоди для цілісності активу. Помилка, здатна генерувати одиниці, які можна витратити, зачіпає саму основу обліку реєстру.
Чому виправлення важливіше за відсутність експлуатації
Спокусливо відкинути уразливість, коли слідчі кажуть, що її ніколи не експлуатували. Це означало б пропустити корисніший урок безпеки.
Хронологія відповіді XRPL була відносно стислою: проблему було повідомлено та відтворено 22 вересня, виправлення розроблено й перевірено протягом 22–23 вересня, об'єднано у гілку релізу 3.4.1 та випущено 25 вересня. XRPL повідомив, що понад 80% валідаторів зі списку унікальних вузлів за замовчуванням запускали захищену версію того ж дня.
Виправлення платіжного рушія також набуло чинності безпосередньо з оновленням програмного забезпечення, а не чекало на звичайний процес активації поправки. Це було можливо, оскільки відхилення арифметичного переповнення розглядалося як виправлення невизначеної або небезпечної поведінки, а не як запровадження нового передбаченого правила транзакцій.
Для безпеки блокчейну час розкриття інформації є частиною захисту. Публікація експлойту до того, як валідатори були захищені, перетворила б теоретичну вразливість на операційні інструкції для атакуючих. Тому XRPL розкрив технічні деталі після того, як виправлена версія вже поширилася.
Ризики та обмеження
Інцидент є серйозним, але кілька меж мають залишатися чіткими.
- Жодного підтвердженого випадку інфляції: XRPL заявляє, що не знайшов доказів експлуатації в публічній мережі.
- Жодного випадкового спрацювання: звичайні платежі та реалістичні книги замовлень не досягають необхідних значень.
- Впровадження патча має значення: оператори серверів повинні запускати
xrpld 3.4.1або новішу версію. - Одне виправлення не доводить повної безпеки: інші старі арифметичні припущення все ще потребують змагального тестування.
- Історична відсутність зловживань не може замінити формальну верифікацію: деякі класи помилок є надто незвичайними, щоб проявитися через звичайну мережеву активність.
Ще одним обмеженням є ретроспективна впевненість. Дослідники можуть аналізувати історію реєстру та відомі шаблони експлойтів, але доведення того, що вразливість ніколи не використовувалася, за своєю суттю відрізняється від математичного доведення того, що її не можна було використати. Тому офіційний висновок належним чином сформульовано як доказів не знайдено, а не як абсолютне твердження про кожен історичний стан.
Погляд MEXC: фіксована пропозиція є властивістю безпеки програмного забезпечення
Грошово-кредитна політика блокчейну не забезпечується лише числом пропозиції, записаним у документації. Вона забезпечується програмним забезпеченням, яке перевіряє кожну зміну балансу, шлях транзакції та стан реєстру.
Інцидент з XRPL ілюструє, чому ця відмінність має значення. Передбачене правило протоколу забороняло створення нових XRP, проте дефект в арифметиці теоретично міг порушити це правило. Що важливіше, захисний інваріант, призначений для виявлення створення пропозиції, спочатку мав той самий режим відмови.
Для зрілих блокчейн-мереж безпека тому має виходити за межі тестування того, чи правильно поводяться звичайні транзакції. Незалежні інваріанти, фаззинг, змагальне тестування граничних умов і формальні методи стають дедалі важливішими саме тому, що найбільш руйнівні вразливості можуть існувати в шляхах коду, яких звичайні користувачі ніколи не торкаються.
Показник, за яким варто стежити після цього розкриття, — це не реакція ціни XRP. Це те, чи розширені процеси верифікації XRPL послідовно виявляють і ізолюють подібні класи латентного ризику протоколу до того, як це зроблять атакуючі.
Помилка десятирічної давності була критичною, а не доведеним випадком інфляції XRP
Вразливість XRP Ledger заслуговує на опис «критична», оскільки вона теоретично могла підірвати одну з найфундаментальніших гарантій XRPL. Ретельно спроєктований платіж міг спричинити 64-бітне арифметичне переповнення, зарахувати сотням власників пропозицій XRP і стягнути з покупця лише частину сукупної суми. Новостворені баланси були витратними у власному відтворенні атаки XRPL.
Але друга половина історії є не менш важливою. XRPL не знайшов жодних доказів експлуатації в публічній мережі, транзакція вимагала навмисно аномальних умов книги замовлень, а вразливість була виправлена в xrpld 3.4.1 до публічного розкриття технічних деталей.
Тому інцидент не слід переписувати як доказ того, що пропозиція XRP історично була завищена. Його значення є більш структурним. Він показує, що навіть блокчейн із фіксованою пропозицією зрештою залежить від програмного забезпечення, яке правильно забезпечує дотримання грошових обмежень у граничних випадках, які можуть залишатися невидимими роками.
Найсильніший висновок із цієї вразливості XRP Ledger, отже, стосується протокольної інженерії, а не заголовків про пропозицію токенів. Грошові інваріанти потребують незалежної реалізації, старий код усе ще потребує змагального перегляду, а успішна робота мережі протягом десятиліття не усуває можливості прихованих відмов на граничних умовах. Помилка не довела, що XRP було надмірно випущено; вона довела, чому цілісність пропозиції потрібно постійно перевіряти.
Джерела
Офіційне розкриття вразливості XRPL:
https://xrpl.org/es-es/blog/2026/vulnerabilitydisclosurereport-bug-20261009
Інформація про випуск XRPL 3.4.1:
https://xrpl.org/blog
Хочете найшвидше отримувати найновіші новини MEXC? Приєднуйтесь до нашої офіційної групи в Telegram!
Платформа MEXC: Завантажити застосунок | Торгівля без комісій | Купити USDT зараз Приєднуйтесь до спільноти MEXC: X (Twitter) | Telegram | Discord
Отримати інформацію: Академія для початківців | Умови обслуговування | MEXC Blog | MEXC News
Верифікація акаунта: Дізнатися про KYC | Як пройти KYC
Попередження про ризики: цей вміст надано лише для довідкових цілей і не є інвестиційною порадою. Ринок цифрових валют є досить волатильним, тому приймайте рішення обережно, виходячи з власних обставин.
