Безпека XRPL посилена після блокування вразливості пакету xrpl перед запуском у мережі mainnet

Фонд XRPL зупинив серйозну проблему, пов’язану з поправкою до пакетної операції xrpl, до того, як вона могла вплинути на основну мережу, підкреслюючи еволюцію безпекового стану реєстру.

Критична вразливість виявлена під час фази голосування

Фонд XRPL повідомив, що виявив і нейтралізував критичну вразливість у запропонованій поправці до пакетної операції ще до її активації на основній мережі. Вразливість з’явилася під час голосування валідаторів, що дозволило розробникам реагувати до будь-яких виробничих наслідків.

Проблему виявили 19 лютого 2026 року інженер з безпеки Pranamya Keshkamat у співпраці з автономним інструментом Apex від Cantina AI. За словами фонду, жодні кошти користувачів не були під загрозою, оскільки поправка ще не була активована на основній мережі XRPL.

Поправка, офіційно відома як XLS-56, мала на меті впровадити пакетні транзакції в XRP Ledger. Вона дозволила б групувати кілька внутрішніх транзакцій у один пакет, підвищуючи ефективність і координацію. Однак ці внутрішні транзакції залишалися підписаними навмисно, а авторизація делегувалася зовнішній пакетній транзакції з переліком підписантів.

Як працювала помилка у валідації підписів

Згідно з постмортем фонду, вразливість була пов’язана з логікою перевірки підписів у функції пакетної операції. Крім того, проблема полягала у помилці циклу у функції перевірки підписів, яка використовувалася для підтвердження авторизацій у пакетах.

Коли система стикалася з записом підписанта, пов’язаним із рахунком, якого ще не існувало в реєстрі, вона могла раптово вийти з циклу. Якщо ключ підпису збігався з новим рахунком, процес перевірки неправильно позначався як успішний. В результаті, система пропускала перевірки для всіх інших записів підписантів у пакеті.

Ця поведінка відкривала шлях до несанкціонованих транзакцій. Зловмисник міг виконувати операції з рахунків жертви без їхніх приватних ключів, оскільки перевірки ключів для цих рахунків могли бути пропущені. На момент виявлення поправка перебувала лише у фазі голосування валідаторів і залишалася вимкненою на основній мережі.

Фонд XRPL підкреслив, що пропозиція ще не була активована, і повторив: «Поправка перебувала у фазі голосування і не була активована на основній мережі; кошти не були під загрозою». Це запевнення було критичним для обмеження занепокоєння ринку і підкреслення переваг ретельного тестування перед активацією.

Можливий вплив помилки у пакетній поправці

Зазначений сценарій експлуатації вимагав ретельно спроектованої пакетної транзакції. Зловмисник міг створити пакет із трьома внутрішніми операціями, спрямованими на використання помилкової логіки у перевірці підписів.

По-перше, одна внутрішня транзакція створювала новий рахунок, цілком контрольований зловмисником. По-друге, ще одна внутрішня транзакція виконувала простий переказ або дію з цього нового рахунку. По-третє, у пакет включалася платіжна операція з рахунку жертви на рахунок зловмисника, намагаючись перемістити кошти без легітимної авторизації.

Щоб завершити налаштування, зловмисник надавав два записи підписантів у пакеті. Один запис був дійсним для нового рахунку, контрольованого зловмисником. Другий запис неправдиво стверджував, що авторизує транзакції для рахунка жертви. Однак через помилку раннього виходу з циклу система могла прийняти перший запис і неправильно перевірити другий.

Внаслідок цього платіж жертви міг бути виконаний без дійсного підпису, що змінило реєстр у спосіб, який не схвалював жертва. Фонд XRPL попередив, що успішне застосування цієї техніки могло б дозволити довільні перекази коштів і руйнівні зміни у реєстрі, якщо б її застосували масштабно.

Крім того, організація підкреслила ризик для довіри до екосистеми, якби цей злом потрапив у основну мережу. Генеральний директор Cantina і Spearbit Hari Mulackal зазначив: «Наш автономний пошук помилок Apex виявив цю критичну вразливість». Команди Ripple відтворили поведінку за допомогою прототипу та провели повне модульне тестування перед усуненням вразливості.

Надзвичайна реакція та оновлення rippled

Після розкриття інформації валідатори UNL XRPL були швидко поінформовані голосувати «Проти» щодо пропозиції пакетної операції. Це забезпечило, що поправка не могла випадково перейти поріг активації під час виправлення.

23 лютого 2026 року було випущено екстрене оновлення програмного забезпечення rippled 3.1.1. Це оновлення явно позначає як оригінальну поправку до пакетної операції, так і пов’язану з нею зміну fixBatchInnerSigs як непідтримувані. Відповідно, вони блокуються від отримання голосів валідаторів і не можуть бути активовані на будь-якій виробничій мережі.

Ця екстрена версія не містить остаточної виправленої логіки. Замість цього вона виконує функцію захисного бар’єра, забезпечуючи, що ні пакетна операція, ні fixBatchInnerSigs не зможуть активуватися у їхній помилковій формі. Однак цей швидкий захист дав розробникам цінний час для розробки та перевірки безпечнішої альтернативи.

Відповідно, було впроваджено виправлену поправку під назвою BatchV1_1, яка є наступником оригінального дизайну. Це оновлення усуває ранній вихід із циклу у перевірці підписів і посилює перевірки всіх шляхів авторизації. Фонд підтвердив, що ця редакція наразі перебуває на стадії розгляду, і дата розгортання ще не запланована.

Посилення безпеки XRPL

Після інциденту фонд XRPL окреслив додаткові заходи безпеки для зміцнення процесів розробки. Крім того, він планує розширити роль штучного інтелекту у перевірці протоколів, щоб раніше виявляти тонкі логічні помилки.

Організація має намір збільшити використання автоматизованих аудитів коду з підтримкою AI, базуючись на успіху інструментів Cantina AI та системи Apex у цьому випадку. Також планується розширити статичний аналіз для виявлення таких патернів, як передчасне повернення успіху всередині циклів, що сприяли виникненню вразливості у логіці перевірки пакетів.

Фонд підкреслив, що випадок з пакетною поправкою XRPL показує важливість багаторівневих захистів, включаючи людський контроль, автономний аналіз і поетапну активацію. Поєднуючи ці підходи, розробники прагнуть зменшити ризик виявлення невиявлених уразливостей у майбутніх оновленнях протоколу.

Загалом, фонд XRPL наголосив, що критична помилка була виправлена до активації на основній мережі і до того, як будь-які кошти були під загрозою. Раннє виявлення, скоординована реакція валідаторів і швидке екстрене оновлення rippled допомогли запобігти несанкціонованим транзакціям і зберегти цілісність мережі XRPL.