Разработчики XRP Ledger раскрыли информацию о критической уязвимости, которая могла позволить злоумышленнику создать расходуемый XRP из ничего, обходя механизмы защиты, призванные не допустить увеличения предложения криптовалюты.

Уязвимость находилась в платёжном движке ledger и была сообщена 22 сентября через программу XRPL Bug Bounty Кейденом Ляо (Cayden Liao) и Veria AI. Инженеры RippleX воспроизвели эксплойт на отдельном сервере, подтвердили, что созданный XRP можно было потратить в последующем платеже, и повысили уровень серьёзности с «major» до «critical». Обработка инцидента соответствовала стандартной практике согласованного раскрытия: отчёты по программе bug bounty поступают к сопровождающим приватно, а полные технические детали публикуются только после выпуска исправления.

Согласно отчёту о раскрытии, опубликованному в официальном блоге XRPL, нет никаких признаков того, что уязвимость эксплуатировалась в какой-либо публичной сети XRP Ledger. Разработчики приватно подготовили исправление и выпустили xrpld версии 3.4.1 25 сентября, через два дня после того, как патч был объединён с веткой экстренного релиза.

Целочисленное переполнение могло обойти проверки предложения XRP

Уязвимость существовала в платёжном движке XRP Ledger примерно с 2015 года и была связана с непроверенной 64-битной целочисленной арифметикой, когда платёж использовал несколько ордеров из книги заявок сети.

Максимум 64-битного числа составляет около 18,4 квинтиллиона, а переполнения в арифметике с фиксированной разрядностью — известный класс ошибок в программном обеспечении ledger: в 2010 году целочисленное переполнение в проверках стоимости Bitcoin кратковременно создало около 184 млрд BTC, прежде чем разработчики устранили проблему в течение нескольких часов.

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

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

Встроенная проверка XRPL, предназначенная для того, чтобы транзакции не могли создавать XRP, не остановила бы эксплойт. Инвариант использовал тот же тип арифметики и мог переполниться тем же образом, а отдельный лимит баланса на аккаунт можно было обойти, распределив созданный XRP по сотням аккаунтов. Опасность была обусловлена особенностями предложения XRP: все 100 млрд токенов были созданы при запуске ledger, комиссии за транзакции сжигают XRP, а не созд его, и проверки инвариантов являются гарантией того, что ни один платёжный путь не может увеличить общее предложение. Уязвимость была ограничена специально сконструированными транзакциями и не могла быть вызвана обычными платежами или торговой активностью.

Валидаторы перешли на 3.4.1 в течение нескольких часов

Разработчики решили развернуть исправление переполнения XRP немедленно, а не проводить его через обычный процесс внесения поправок XRPL, который обычно требует более 80% поддержки валидаторов в течение двух недель до активации изменения протокола. Оставление уязвимости открытой в течение этого периода создало бы окно, в котором метод атаки был бы общеизвестен, но всё ещё применим.

Более 80% валидаторов в стандартном списке Unique Node List обновились до 3.4.1 25 сентября, в тот же день, когда вышла экстренная версия. Трёхдневный промежуток от приватного отчёта до принятия большинством валидаторов показал работу механизма экстренных релизов ledger от начала до конца.

Версия 3.4.1 теперь отклоняет платежи, при которых сумма ордеров могла бы переполниться, и использует более широкий счётчик для инварианта создания XRP. Дополнительные вычисления балансов также были усилены против подобных арифметических сбоев.

Этот инцидент последовал за не связанной с ним компрометацией цепочки поставок xrpl.js, обнаруженной в 2025 году, которая затронула вредоносные релизы JavaScript-пакетов, а не сам протокол XRP Ledger. Система поправок XRPL также используется для новой функциональности, такой как предлагаемый XRPL Lending Protocol, где одобрение валидаторами определяет, станет ли новое поведение транзакций активным.

Уязвимость переполнения не изменила существующее предложение XRP. Несанкционированный XRP не выявлен, и операторам серверов теперь необходимо использовать xrpld 3.4.1 или новее, чтобы оставаться синхронизированными с сетью. Наблюдаемыми остаются лишь операционные аспекты: переход оставшихся на более ранних версиях на 3.4.1 или новее, а также продвижение предложений, таких как XRPL Lending Protocol, по стандартному процессу поправок, который это исправление обошло.

Источник: XRP Ledger Patches Decade-Old Flaw That Could Create Spendable XRP — Crypto Adventure