BTC80 226▼ 1,51%ETH2 326▼ 1,70%SOL100,53▼ 2,17%XRP1,29▼ 2,51%BNB741,41▼ 2,31%
🇬🇧 cryptoslate Добавлено: 28.02.2026 12:38 Oluwapelumi Adejumo

XRP Ledger nearly shipped a feature that could drain accounts without owners signing

Тональность: Негативная
Фактичность: Подтверждено
Полезность: 80%
Фокус: Настоящее
Эмоции: Страх 40% Неопределённость 60%

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

Уязвимость в предлагаемом обновлении XRP Ledger (XRPL) могла бы позволить совершать несанкционированные транзакции, но исследователи обнаружили эту проблему до того, как она попала бы в основную сеть блокчейна.

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

Исследователь безопасности Пранамя Кешкамат и инструмент статического анализа Cantina AI под названием Apex сообщили об этой проблеме 19 февраля, согласно заявлению фонда.

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

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

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

Понимание критической уязвимости безопасности дополнения "Batch" для XRPL

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

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

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

Если эти проверки не проходят, реестр может рассматривать несанкционированные действия как действительные.

В заявлении говорится, что ошибка возникла из-за ошибки цикла в функции, которая проверяет подписантов "Batch".

Когда код сталкивался с подписантом, у которого учетная запись еще не существовала в реестре, но чей ключ подписи соответствовал этой же учетной записи (что является нормальным состоянием для только что созданной учетной записи), он немедленно возвращал успешный результат и прекращал проверку остальной части списка подписантов.

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

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

Если бы функция Batch была активирована до обнаружения уязвимости, последствия могли быть серьезными.

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

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

Уязвимость могла разрушить имидж безопасности XRPL

Уязвимость могла повредить имиджу безопасности сети XRPL в критический момент для ее развития, которая активно расширяется в области токенизации реальных активов (RWA) и институциональных DeFi.

Данные DeFiLlama показывают, что на платформе XRPL заблокировано около 50 миллионов долларов США в различных DeFi-активах, при этом почти 2 миллиарда долларов США представлены в виде активов RWA.

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

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

Это особенно важно, учитывая, что XRPL недавно представила новый набор функций, ориентированных на институты, включая Permissioned Domains и DEX.

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

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

CryptoSlate Daily Brief

Ежедневные сигналы, без лишнего шума.

Важные новости и контекст, представленные каждое утро в кратком обзоре.

Обзор за 5 минут. Более 100 000 читателей.

Адрес электронной почты

Получить обзор

Бесплатно. Без спама. Отписаться в любое время.

Ой, похоже, возникла проблема. Пожалуйста, попробуйте еще раз.

Вы подписаны. Добро пожаловать на борт.

Как XRPL предотвратила инцидент безопасности

Реакция XRPL была оперативной и прошла через каналы управления и программного обеспечения.

Список уникальных узлов (UNL) доверенных валидаторов был проинформирован и получил указание голосовать "против" поправки Batch.

23 февраля XRPL выпустила версию 3.1.1, экстренное обновление, которое признает как Batch, так и fixBatchInnerSigs не поддерживаемыми. Это предотвратило получение поправками голосов валидаторов и их активацию в сети.

Это обновление было разработано как немедленное решение, а не полное исправление. В объявлении было четко указано, что в версии 3.1.1 отсутствует основное исправление логики.

XRPL также запланировала сброс devnet на 3 марта 2026 года, чтобы это совпало с изменениями в версии 3.1.1. Этот сброс применяется только к devnet, а не к основной сети, но он показывает, насколько операторы сети стремятся предотвратить влияние проблемы на активные пути поправок.

Исправленная замена, BatchV1_1, уже была реализована и находится на рассмотрении, дата выпуска пока не определена.

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

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

Следующий этап - безопасная реализация замены

Для XRPL результат февраля можно считать успехом в области управления. Ошибка была обнаружена до активации. Валидаторы скоординировали свои действия. Экстренное обновление заблокировало путь для поправки. Никакие средства не были потеряны.

Но история на этом не заканчивается.

BatchV1_1 теперь будет оцениваться по двум уровням. Первый - технический: обеспечивает ли он преимущества для разработчиков, связанные с атомарной группировкой транзакций, при этом не создавая новых рисков, связанных с авторизацией.

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

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

Чем более амбициозным становится этот план, тем важнее становятся такие "скучные" вещи, как проверка подписи и поведение циклов.

В данном случае тормоза сработали. Следующая задача - доказать, что система может снова ускоряться, не теряя при этом этого запаса безопасности.

Опубликовано в

Рекомендованные новости Технологии Торговля Токенизация XRP TradFi Искусственный интеллект Рынок

Контекст

Связанные материалы

Перейдите в другие категории, чтобы узнать больше или получить более широкий контекст.

XRPПоследние новости о XRP, Технологии, Главная категория, Пресс-релизы, Новостные сводки.

Отказ от ответственности

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

Упоминания

Организации