Уязвимость переполнения в XRP Ledger могла позволить одной транзакции создать больше XRP, чем составляет весь существующий объем предложения. RippleX, подразделение Ripple по разработке, и XRPL Foundation раскрыли и устранили эту уязвимость, вероятно присутствовавшую с 2015 года, в конце сентября 2026 года. Признаков того, что она когда-либо эксплуатировалась, нет.

Лимит предложения, который мог быть нарушен

XRP Ledger — это децентрализованный блокчейн, лежащий в основе XRP. Он обрабатывает платежи и торговлю через встроенный ордербук, а платежный движок — это компонент, который сопоставляет платежи с размещенными в нем ордерами. Общий объем предложения на момент запуска составлял 100 миллиардов XRP. Майнинга и инфляции нет; предложение лишь незначительно сокращается за счет сжигания комиссий за транзакции. Этот фиксированный лимит опирается на инвариант уровня леджера — правило, согласно которому ни одна транзакция не может создавать XRP, — и именно эту гарантию подрывала уязвимость переполнения.

Версия 3.4.1 серверного ПО xrpld вышла 25 сентября, а отчет о раскрытии уязвимости был опубликован спустя 14 дней. К этому моменту более 80% валидаторов Default Unique Node List (UNL) уже обновились. Уязвимость затрагивала xrpld 3.4.0 и все более ранние версии. Veria Labs, сообщившая об уязвимости, подсчитала, что одна транзакция эксплойта могла бы создать около 18 триллионов XRP.

Как можно было создать XRP из воздуха

Платежный движок суммировал суммы всех ордеров, которые платеж потреблял в ордербуке, используя 64-битное целочисленное сложение без проверки на переполнение. Если сумма становилась достаточно большой, значение «заворачивалось» в небольшое число. Каждый владелец ордера получил бы полную сумму платежа, тогда как с покупателя леджер списал бы только «завернутую» сумму. Разница возникла бы в виде новых XRP.

Две защитные меры должны были это предотвратить. Однако инвариант, гласящий, что ни одна транзакция не может создавать XRP, использовал ту же арифметику с переполнением. Кроме того, проверка баланса на уровне аккаунта срабатывает только при превышении общего объема предложения, тогда как созданные XRP распределились бы по множеству аккаунтов.

Для атаки злоумышленник создал бы сотни аккаунтов, каждый из которых предлагал бы крошечную долю токена за огромное количество XRP. Один платеж затем потребил бы все ордера, и каждый задействованный аккаунт мог бы принадлежать злоумышленнику. Затраты составили бы несколько сотен XRP в возвратных резервах плюс комиссии, поэтому злоумышленнику не требовался крупный стартовый баланс.

Тем не менее переполнение невозможно было вызвать случайно. Обычные платежи никогда не достиг необходимой суммы, поскольку ни один реальный трейдер не стал бы указывать такие цены. В отчете также говорится, что признаков эксплуатации в любой публичной сети нет. Кейден Ляо из Veria Labs поясняет, что эксплойт объединяет две уязвимости, каждая из которых в отдельности оценивалась бы как низкая степень тяжести, и предполагает, что именно поэтому этот недостаток раньше никто не обнаружил.

Сообщение через программу bug bounty

Кейден Ляо и Veria AI сообщили об уязвимости 22 сентября через программу bug bounty сети, первоначально оценив ее как "Major". RippleX воспроизвела атаку и повысила оценку до "critical", после чего команда втайне разработала исправление. Через день исправление попало в релизную ветку версии 3.4.1 и вышло в релиз-кандидате 3.4.1-rc1. С тех пор платежный движок проверяет переполнение при суммировании сумм ордеров; если сумма переполняется, эта часть платежа завершается ошибкой.

Подробности о самом обнаружении предоставила только Veria Labs. Компания сообщает, что уязвимость нашел ИИ-агент и построил работающий эксплойт. В отличие от этого, в отчете о раскрытии указаны только Ляо и Veria AI как сообщившие. Цифра около 18 триллионов XRP также взята из расчетов Ляо и эквивалентна 184-кратному объему общего предложения. Veria также заявляет, что получила максимальное вознаграждение в размере 250 000 долларов США, хотя в отчете сумма не называется. Подобные программы являются стандартным механизмом вознаграждения ответственного раскрытия уязвимостей на крупнейших блокчейн-сетях.

Согласно отчету, уязвимость, вероятно, находилась в коде с момента разработки платежного движка в 2015 году и оставалась незамеченной около десятилетия. Этот случай вписывается в более широкую тенденцию поиска уязвимостей с помощью ИИ, который выявляет недостатки быстрее — эту точку зрения разделяют и разработчики RippleX.

Исправление без amendment

Изменения правил в XRP Ledger обычно проходят через так называемые amendment, для которых требуется поддержка более 80% доверенных валидаторов в течение двухнедельного периода. Это исправление, однако, вступило в силу немедленно, по мере обновления каждого отдельного сервера. В отчете оно названо первым намеренным изменением такого рода в обработке транзакций с момента появления amendment. В день релиза более 80% валидаторов Default UNL уже работали на версии 3.4.1 или новее.

RippleX обосновала этот шаг временным окном: обычный открытый релиз показал бы злоумышленникам, где находится уязвимость, за недели до вступления исправления в силу. Поэтому члены XRPL Foundation, RippleX и валидаторы XRPL заранее согласились, что риск оправдывает быстрый подход. По их мнению, только самые серьезные уязвимости оправдывают такой шаг, в то время как все остальные изменения по-прежнему проходят через amendment.

"AI has changed things. You can't sneak a critical bug patch into a routine public release process, it'll get spotted and reverse-engineered immediately." — Mayukha Vadari, RippleX

При этом команда опубликовала исходный код 3.4.1 на GitHub лишь примерно через две недели после бинарных файлов. Джастин Бонс, основатель Cyber Capital, раскритиковал в X то, что XRP две недели работал на коде с закрытым исходным кодом. Тихое исправление с отложенным раскрытием — обычная практика в области безопасности ПО, но в децентрализованной сети с амбициями в области управления оно остается спорным.

Вторая уязвимость в функции batch

Версия 3.4.1 также устранила вторую уязвимость — в функции batch (XLS-56), которая затрагивала xrpld 3.3.0 и 3.4.0. Batch вмещает до восьми внутренних транзакций, и согласнофикации каждая из них должна находиться в поле RawTransaction. Сервер это не проверял. В результате могла возникнуть безвозвратно некорректная запись в леджере, которая могла нарушить работу индексаторов, эксплореров и SDK.

Более серьезным был консенсусный вариант. При смешанных версиях ПО специально созданная транзакция могла остановить валидацию ценой одной комиссии за транзакцию, хотя злоумышленник не получил бы никакой выгоды на блокчейне. Mainnet не пострадал, поскольку BatchV1_1 там не была активна.

Находка впервые была обнаружена на Sherlock Attackathon, где первоначально получила оценку "low". 18 сентября Денис Энджелл из XRPL Foundation подтвердил, что предыдущее исправление было неполным. Четыре дня спустя Майукха Вадари выявила консенсусный риск. Ripple и оператор валидатора Vet затем отозвали свои голоса за BatchV1_1 — amendment, который изначально должен был активироваться 29 сентября. Релиз запустил двухнедельную активацию fixBatchV1_2, и с 9 октября оба amendment активны на mainnet.

Ужесточение процесса проверки

Поэтому RippleX меняет свой процесс проверки. Отныне каждая уязвимость, помеченная как исправленная, проходит новую проверку против релиз-кандидата, и команда закрывает ее только после того, как тест воспроизводит исходную уязвимость и кандидат проходит проверку. Среди дополнительных мер в отчете названы публичные attackathon и редтиминг с использованием ИИ.

Более старые версии считаются "amendment-blocked" и больше не синхронизируются. Таким образом, операторам необходимо обновить свои серверы до xrpld 3.4.1 или новее.

Источник: отчет XRPL о раскрытии уязвимости через Crypto Valley Journal