XRPL виправляє критичну помилку пакету поправок, яка могла призвести до витоку коштів, виявлену інструментом безпеки на основі ШІ

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

Виявлений інженером з безпеки Пранамією Кешкамат та автономним інструментом безпеки ШІ Apex від Cantina 19 лютого, цей недолік було усунено екстреним випуском rippled версії 3.1.1 23 лютого, без жодних коштів під загрозою, оскільки поправка залишалася на стадії голосування і так і не була активована в основній мережі.

Хронологія відкриття та розкриття інформації

19 лютого 2026 року було виявлено критичну логічну помилку в коді підтвердження підпису запропонованої поправки Batch для реєстру XRP. Вразливість була виявлена за допомогою статичного аналізу хвильованої кодової бази Пранам’єю Кешкамат, інженером з безпеки з кібербезпеки Cantina, яка працювала у співпраці з автономним інструментом безпеки ШІ Cantina — Apex.

Команда відкриття негайно подала відповідальний звіт про розкриття до Фонду XRPL, що дозволило інженерним командам Ripple підтвердити результати за допомогою незалежного доказу концепції та повного відтворення модульного тестування. Роботи з рекультивації розпочалися того ж вечора.

Харі Мулакал, генеральний директор Cantina та Spearbit, заявив, що «наш автономний мисливець за багами, Apex, виявив цю критичну помилку», додавши, що «якби її використали, це був би найбільший у світі злом безпеки за грошовою вартістю, з майже 80 мільярдами доларів під прямим ризиком», посилаючись на ринкову капіталізацію XRP.

Технічна природа вразливості

Вразливість полягала в логіці валідації підписів у пакетній зміні — запропонованій функції, яка дозволяла б атомарно виконувати до восьми транзакцій в одній пакетній операції. При увімкненні внутрішньої транзакції в пакеті навмисно не підписуються, а авторизація повністю делегується списку підписантів партії зовнішньої партії.

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

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

Потенційний вплив і рекультивація

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

Після підтвердження вразливості валідаторів UNL негайно звернулися і порадили проголосувати проти поправки Batch. Екстрений реліз 3.1.1 був опублікований 23 лютого 2026 року, позначивши як Batch, так і fixBatchInnerSigs як непідтримувані, що не дозволило їм отримати голоси валідаторів або бути активованими в мережі.

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

Зростаюча роль ШІ у кібербезпеці

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

Цей інцидент збігається з ширшими галузевими розробками у сфері безпеки на основі ШІ. 20 лютого Anthropic випустила Claude Code Security — сканер кібербезпеки на основі ШІ, який, за словами компанії, «може логічно мислити, як досвідчений дослідник безпеки». Поява цих інструментів свідчить про потенційний зсув у способах виявлення та усунення критичних інфраструктурних вразливостей.

Відповідь Фонду XRPL та майбутні заходи

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

Фонд також оголосив про заплановане скидання devnet на 3 березня 2026 року, щоб врахувати зміни та запобігти тому, щоб валідатори, які оновлюються, були заблоковані поправками. Скидання видаляє всі дані реєстру Devnet, включно з рахунками, транзакціями, балансами та іншими записами, при цьому всі баланси скидаються до нуля, а номер блоку перезапускається з одиниці. Mainnet, XRPL Testnet, Xahau та тестнет Hooks продовжать звичайну роботу без змін.

FAQ: Розуміння вразливості поправки до XRPL Batch

Питання: Що мала зробити поправка Batch щодо XRP Ledger?

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

Питання: Як зловмисники могли скористатися цією вразливістю?

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

Питання: Чому в цьому інциденті не було втрачено грошей?

Відповідь: Поправка Batch ще була на стадії голосування і не була активована в основній мережі, коли вразливість була виявлена. Фонд XRPL негайно порадив валідаторам проголосувати проти поправки та видав екстрений реліз програмного забезпечення (rippled 3.1.1), повністю вимкнувши його і унеможлививши будь-яку можливість активації.

Питання: Яку роль відіграв ШІ у виявленні цієї вразливості?

Відповідь: Автономний інструмент безпеки штучного інтелекту Cantina Apex виявив вразливість за допомогою статичного аналізу хвилеподібної кодової бази. Відкриття ШІ, у поєднанні з аналізом інженера з безпеки людини, дозволило відповідально розкривати інформацію та виправляти до активації поправки, демонструючи зростаюче значення інструментів кібербезпеки на базі ШІ.