Безопасность XRPL усилена после блокировки уязвимости в пакете исправлений xrpl перед запуском основной сети

Фонд XRPL остановил серьезную проблему, связанную с предложением о пакетных изменениях xrpl, до того как она могла повлиять на основную сеть, подчеркнув эволюцию уровня безопасности реестра.

Критическая уязвимость обнаружена во время голосования

Фонд XRPL сообщил, что критическая уязвимость в предлагаемом обновлении Batch была выявлена и устранена до активации на основной сети. Уязвимость возникла во время голосования валидаторов, что позволило разработчикам реагировать до возникновения какого-либо воздействия на производство.

Проблема была обнаружена 19 февраля 2026 года инженером по безопасности Pranamya Keshkamat совместно с автономным инструментом Apex от Cantina AI. Согласно заявлению фонда, средства пользователей никогда не находились под угрозой, поскольку изменение еще не было активировано на основной сети XRPL.

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

Как работала ошибка в проверке подписи

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

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

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

Фонд XRPL подчеркнул, что предложение не было активировано, и повторил: «Обновление находилось в стадии голосования и не было активировано на основной сети; средства не находились под угрозой». Эта гарантия была важна для ограничения рыночных опасений и подчеркивания преимущества тщательного тестирования перед активацией.

Потенциальное влияние ошибки пакетного обновления

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

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

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

В результате платеж жертвы мог быть выполнен без действительной подписи, что могло привести к изменениям в реестре без согласия жертвы. Фонд XRPL предупредил, что успешное использование этой техники могло бы позволить произвольные переводы средств и разрушительные изменения в реестре при масштабном использовании.

Кроме того, организация подчеркнула риск для доверия всей экосистемы, если бы такой эксплойт достиг основной сети. Генеральный директор Cantina и Spearbit Hari Mulackal отметил: «Наш автономный охотник за ошибками Apex обнаружил эту критическую уязвимость». Команды Ripple воспроизвели поведение с помощью демонстрационной версии и провели полный модульный тест, прежде чем устранить проблему.

Аварийное реагирование и обновление rippled

После раскрытия информации валидаторы UNL XRPL были быстро проинформированы о необходимости голосовать «Против» по предложению о пакетных изменениях. Это обеспечило, что обновление не могло случайно перейти порог активации во время устранения уязвимости.

Было выпущено аварийное программное обновление rippled 3.1.1 23 февраля 2026 года. Этот релиз явно помечает как неподдерживаемые как исходное обновление Batch, так и связанный с ним fixBatchInnerSigs. В результате они блокируются от получения голосов валидаторов и не могут быть активированы в любой производственной сети.

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

Исправленное обновление под названием BatchV1_1 уже реализовано как преемник оригинального проекта. Это обновление устраняет ошибку раннего выхода в проверке подписанта и усиливает проверки всех путей авторизации. Фонд подтвердил, что данная ревизия находится на стадии рассмотрения, и дата внедрения пока не назначена.

Усиление практик безопасности XRPL

После инцидента фонд XRPL обозначил дополнительные меры безопасности для укрепления процессов разработки. Кроме того, планируется расширить роль ИИ в проверке протокольных изменений, чтобы раньше выявлять тонкие логические ошибки.

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

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

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