XRPL исправила критическую ошибку в пакете обновлений, которая могла привести к утечке средств, обнаруженную инструментом AI Security

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

Обнаруженный инженером по безопасности Пранамой Кешкамат и автономным инструментом безопасности Cantina Apex 19 февраля, уязвимость была устранена через экстренный выпуск rippled версии 3.1.1 23 февраля, при этом средства не были под угрозой, так как поправка оставалась на стадии голосования и так и не была активирована в основной сети.

Хронология раскрытия и раскрытия информации

19 февраля 2026 года была выявлена критическая логическая ошибка в коде проверки подписей в предлагаемой поправке Batch для реестра XRP. Уязвимость была обнаружена в ходе статического анализа волнненной кодовой базы Пранамьей Кешкамат, инженером по безопасности из компании Cantina, сотрудничающей с автономным инструментом безопасности Cantina — Apex.

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

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

Техническая природа уязвимости

Уязвимость заключалась в логике проверки подписи в поправке Batch — предлагаемой функции, позволяющей атомарно выполнять до восьми транзакций в одной пакетной операции. При включении внутренние транзакции в партии намеренно не подписаны, а авторизация полностью делегируется внешнему списку подписчиков партии.

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

Этот недостаток создал чёткий путь для эксплойта: злоумышленник мог создать пакетную транзакцию, содержащую три внутренние транзакции — одну создающую новый аккаунт, который он контролирует, одну простую транзакцию с этого нового аккаунта (делая его обязательным подписателем) и один платеж с аккаунта жертвы злоумышленнику. Предоставив две партийные записи подписчика — легитимную для нового аккаунта и поддельную, утверждающую, что авторизирует аккаунт жертвы, но подписанную собственным ключом злоумышленника — валидация успешно выходит после первой записи и никогда не валидирует вторую, позволяя оплате жертвы выполняться без участия ключей.

Возможное воздействие и устранение

Если бы поправка Batch была активирована до обнаружения ошибки, злоумышленник мог украсть средства, выполняя внутренние платежные транзакции, опустошая счета жертв до резерва, изменить состояние реестра через несанкционированные транзакции AccountSet, TrustSet или AccountDelete, а также потенциально дестабилизировать более широкую экосистему из-за потери доверия к XRPL.

После подтверждения уязвимости немедленно связались с валидаторами UNL и рекомендовали проголосовать против поправки Batch. Экстренный релиз с версией rippled 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 будут продолжать нормальную работу без изменений.

Часто задаваемые вопросы: Понимание уязвимости поправки к XRPL Batch

В: Что должна была сделать поправка Batch для XRP Ledger?

Ответ: Поправка Batch была предложенной функцией, позволяющей атомарно выполнять до восьми транзакций в одной партийной операции. Это позволило бы разработчикам создавать приложения с платными функциями, автоматизированными рабочими процессами и моделями прямого дохода в цепочке, обеспечивая одновременное выполнение нескольких транзакций — либо все успешные, либо все неудачные.

Вопрос: Как злоумышленники могли воспользоваться этой уязвимостью?

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

Вопрос: Почему в этом инциденте не было потеряно деньги?

Ответ: Поправка Batch всё ещё находилась на стадии голосования и не была активирована в основной сети, когда уязвимость была обнаружена. Фонд XRPL немедленно рекомендовал валидаторам проголосовать против поправки и выпустил экстренный выпуск программного обеспечения (rippled 3.1.1), полностью отключив его и исключая возможность активации.

В: Какую роль сыграл ИИ в обнаружении этой уязвимости?

Ответ: Автономный инструмент безопасности ИИ от Cantina Apex выявил уязвимость с помощью статического анализа волнной кодовой базы. Открытие ИИ, в сочетании с анализом инженеров по безопасности человека, позволило ответственно раскрывать информацию и исправлять их до активации поправки, демонстрируя растущее значение инструментов кибербезопасности на базе ИИ.