Уязвимость в предлагаемом обновлении XRP Ledger (XRPL) могла позволить проводить несанкционированные транзакции, но исследователи обнаружили проблему до того, как она попала в основную сеть. Фонд XRPL сообщил 26 февраля, что уязвимость найдена в изменении «Batch» [...]. XRP Ledger едва не выпустил функцию, которая могла бы опустошить счета без подписи владельцев. — cryptoslate.com
Уязвимость в предлагаемом обновлении XRP Ledger (XRPL) могла позволить проводить несанкционированные транзакции, однако исследователи обнаружили проблему до того, как она могла попасть в основную сеть блокчейна.
Фонд XRPL сообщил 26 февраля, что уязвимость была найдена в предлагаемом изменении «Batch» (Пакет) — функции, предназначенной для того, чтобы пользователи могли объединять несколько действий в одну атомарную транзакцию.
По данным фонда, исследователь безопасности Пранамья Кешкамат и автономный инструмент статического анализа Apex от Cantina AI сообщили о проблеме 19 февраля.
Если бы это изменение было активировано с ошибкой, злоумышленник мог бы выполнить внутренние транзакции так, как если бы они были авторизованы другим счетом, без доступа к закрытым ключам этого пользователя.
Это могло бы привести к несанкционированным переводам средств и изменениям настроек реестра в аккаунте жертвы, даже если жертва не подписывала транзакцию.
Это раскрытие информации произошло на фоне того, что XRPL позиционирует себя для вариантов использования, таких как токенизация и другие чувствительные к соблюдению нормативных требований действия, где воспринимаемая безопасность и надежность имеют решающее значение для институционального принятия.
Понимание критической уязвимости безопасности в изменении Batch в XRPL
Предлагаемое изменение Batch изменило бы принцип работы авторизации в XRP Ledger, позволяя объединять несколько «внутренних» транзакций в одну «внешнюю» транзакцию Batch, чтобы все шаги либо выполнялись успешно, либо отменялись вместе.
Такая атомарная структура может снизить риск выполнения для разработчиков, выполняющих многоэтапные операции. Она также создает новую границу авторизации.
В дизайне Batch внутренние транзакции намеренно не подписываются. Вместо этого полномочия делегируются списку подписантов пакета, прикрепленному к внешней транзакции, что делает код проверки подписей критической точкой контроля.
Если эти проверки не пройдут, реестр может счесть несанкционированные действия действительными.
В сообщении говорилось, что ошибка возникла из-за ошибки цикла в функции, которая проверяет подписантов пакета.
Когда код сталкивался с подписантом, чей счет еще не существовал в реестре, а его ключ подписи совпадал с этим же счетом (нормальное состояние для вновь созданного счета), он немедленно возвращал успех и прекращал проверку оставшейся части списка подписантов.
Это условие было более опасным в пакетной системе, чем кажется. Пакет может включать шаги по созданию счетов в рамках одной и той же атомарной последовательности, что означает, что существование счета на момент проверки становится частью границы авторизации.
В отчете говорилось, что злоумышленник мог бы вставить действительную запись подписанта для еще не созданного счета, которым он управлял, вызвать условие преждевременного успеха и обойти проверку поддельной записи подписанта, утверждающей, что она авторизует счет жертвы.
Если бы Batch был активирован до того, как ошибка была обнаружена, последствия могли бы быть серьезными.
Фонд заявил, что злоумышленник мог бы выполнить внутренние транзакции Payment, которые истощили бы счета жертв до резерва. Та же ошибка могла бы также позволить проводить несанкционированные операции на уровне счета, включая AccountSet, TrustSet и потенциально AccountDelete.
Это свелось бы к сценарию «траты без ключей» — виду сбоя безопасности, который может нанести репутационный ущерб, даже если убытки ограничены и быстро устранены.
Ошибка могла разрушить ореол безопасности XRPL
Ошибка могла нанести ущерб повествованию о безопасности XRPL в чувствительное для сети время, поскольку она активно расширяется в области токенизации реальных активов (RWA) и институционального DeFi.
Данные DeFiLlama показывают, что на платформе XRPL заблокировано около 50 миллионов долларов в общем объеме DeFi, при этом почти 2 миллиарда долларов приходится на активы RWA.
На крипторынках сбои авторизации часто формируют восприятие долго после того, как основная техническая проблема решена.
Для реестра, позиционирующего себя как инфраструктура для регулируемых финансов, такой инцидент имел бы более широкие последствия.
Это особенно актуально, учитывая, что XRPL недавно представила новый набор функций, ориентированных на институциональных участников, включая Permissioned Domains и DEXs.
Эти функции предназначены для создания закрытых торговых площадок, где только одобренные участники могут размещать и принимать ордера. Эта модель нацелена на учреждения, которые хотят проводить расчеты на основе блокчейна без открытого доступа ко всем контрагентам.
Таким образом, проблема безопасности подорвала бы это сообщение. Сеть не может быть легко управляемой рынком или ориентированной на соблюдение нормативных требований в ончейн-средах, в то время как предлагаемое обновление транзакций несет риск несанкционированных действий с участием произвольных счетов.
Как XRPL предотвратил инцидент с безопасностью
Реакция XRPL быстро прошла через каналы управления и программного обеспечения.
С уникальным списком доверенных валидаторов (UNL) связались и посоветовали голосовать «Нет» за изменение Batch.
23 февраля XRPL выпустила rippled 3.1.1 — экстренное обновление, которое помечает как Batch, так и fixBatchInnerSigs как неподдерживаемые. Это помешало изменениям получить голоса валидаторов или быть активированными в сети.
Выпуск был разработан как немедленное сдерживание, а не как полное исправление. В сообщении прямо говорилось, что выпуск 3.1.1 не включает исправление базовой логики.
XRPL также запланировала сброс Devnet на 3 марта 2026 года, чтобы он совпал с изменением 3.1.1. Этот сброс применяется только к Devnet, а не к основной сети, но он показывает, в какой степени операторы сети приняли меры, чтобы проблема не затронула активные пути изменений.
Исправленная замена, BatchV1_1, уже реализована и находится на рассмотрении, дата выпуска пока не назначена.
Согласно сообщению, полное исправление устраняет ранний выход, добавляет дополнительные защитные механизмы авторизации и сужает область проверки подписи.
В отчете также изложен более широкий план обеспечения безопасности, включая более стандартизированные аудиты с помощью ИИ, расширенные проверки статического анализа на предмет опасных выходов из циклов и обзор аналогичных шаблонов в других частях кодовой базы.
Следующее испытание — безопасная доставка замены
Для XRPL исход февральских событий будет засчитан как успех управления. Ошибка была найдена до активации. Валидаторы скоординировали свои действия. Экстренный выпуск заблокировал путь активации изменений. Средства не были потеряны.
Но на этом история не заканчивается.
BatchV1_1 теперь будет оцениваться по двум уровням. Первый — технический: сможет ли он предоставить разработчикам преимущества атомарного объединения транзакций, не открывая вновь риск авторизации.
Второй — процедурный: смогут ли системы управления и инженерии XRPL поспевать за расширяющимся набором функций, нацеленных на институциональное принятие.
Это реальный фон этого «почти случившегося». XRPL пытается вырасти в более широкую финансовую платформу, способную размещать закрытые торговые площадки, разрешенные среды и более сложную логику транзакций, одновременно привлекая разработчиков капиталом экосистемы и широтой продукта.
Чем амбициознее становится этот план, тем важнее становятся скучные вещи, такие как проверка подписантов и поведение циклов.
В данном случае тормоза сработали. Следующая задача — доказать, что система может снова ускориться, не теряя этого запаса безопасности.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Oluwapelumi Adejumo