Обзор
Критическая уязвимость XRP Ledger, которая оставалась в платежном движке около десяти лет, теоретически могла позволить злоумышленнику создать расходуемые XRP сверх предусмотренных правил предложения реестра. XRPL раскрыла проблему 9 октября 2026 года после того, как она была конфиденциально сообщена через программу вознаграждения за обнаружение ошибок XRPL 22 сентября. Уязвимость затрагивала xrpld 3.4.0 и более ранние версии и была исправлена в xrpld 3.4.1, выпущенной 25 сентября.
Уязвимость XRP Ledger включала целочисленное переполнение, когда платеж потреблял сотни специально созданных предложений книги ордеров. Отдельные владельцы предложений могли получить свои полные суммы XRP, в то время как с покупателя списывалась лишь небольшая сумма с учетом переполнения. Что более серьезно, существующий инвариант реестра «XRP не создается» использовал аналогичный арифметический путь и мог переполниться таким же образом, что мешало этой проверке безопасности обнаружить несоответствие.
XRPL заявляет, что не нашла доказательств эксплуатации уязвимости в какой-либо публичной сети, и обычные платежи не могли случайно ее вызвать. Атака требовала намеренно сконструированных предложений с экономически нереалистичными ценами. Тем не менее, инцидент поднимает более глубокий вопрос безопасности: фиксированная денежная политика блокчейна настолько сильна, насколько сильно программное обеспечение, обеспечивающее каждый переход баланса.
Ключевые выводы
- Ошибка, по-видимому, существовала с момента написания текущего платежного движка XRPL в 2015 году.
- Намеренно сконструированная транзакция теоретически могла создать расходуемые XRP.
- XRPL не нашла доказательств эксплуатации в публичной сети.
- Существующий инвариант предложения мог отказать, поскольку воспроизводил такое же поведение переполнения.
xrpld 3.4.1добавила проверенную арифметику и более строгую независимую проверку предложения.
Что представляла собой уязвимость XRP Ledger?
Уязвимость находилась внутри обработки ликвидности книги ордеров платежным движком XRP Ledger. Когда платеж проходит через несколько предложений, движок должен рассчитать, сколько XRP в общей сложности должен заплатить плательщик. Каждая отдельная сумма могла быть действительной, но агрегированный расчет использовал 64-битное целое число без достаточной защиты от переполнения.
В обычных условиях это было практически недостижимо. Нормальное предложение XRP и реальные рыночные цены даже близко не подходят к числовой границе, необходимой для переполнения счетчика. Проблема возникала только тогда, когда злоумышленник намеренно создавал сотни предложений, в которых каждый аккаунт запрашивал чрезвычайно большое количество XRP за крошечное количество другого токена.
Вредоносный поток мог выглядеть примерно так:
- Создать несколько сотен контролируемых аккаунтов.
- Разместить намеренно нереалистичные предложения с этих аккаунтов.
- Сконструировать один платеж, предназначенный для одновременного потребления этих предложений.
- Вывести агрегированный расчет XRP за пределы целочисленного лимита.
- Вызвать переполнение итоговой суммы до гораздо меньшего числа.
Затем движок мог зачислить владельцам предложений индивидуальные суммы, списав с покупателя только переполненную итоговую сумму. Поскольку злоумышленник мог также контролировать аккаунты владельцев предложений, разница фактически становилась новыми XRP.
Инженеры XRPL воспроизвели атаку локально и подтвердили, что полученные XRP впоследствии можно было перевести. В результате проблема была повышена с уровня «серьезная» до критической степени серьезности.
Могла ли уязвимость XRP Ledger действительно создать XRP?
Да, теоретически. Это была не просто ошибка отображения учета. Техническое раскрытие XRPL говорит, что эксплойт мог создать XRP, которые после валидации вредоносной транзакции вели себя как обычные XRP. Эти балансы можно было перемещать, торговать ими или отправлять на биржи.
Это не означает, что XRP исторически выпускались сверх нормы. XRPL сообщает, что не нашла никаких доказательств того, что эксплойт имел место в какой-либо публичной сети. Разница между этими двумя утверждениями существенна: уязвимость могла нарушить предусмотренное ограничение предложения, но в настоящее время нет подтвержденного исторического события предложения, связанного с ней.
Атака также не могла произойти случайно во время обычной торговли на DEX. Предложения книги ордеров должны были быть оценены настолько нереалистично, что нормальная рыночная ликвидность исполнилась бы до достижения их. Платеж также должен был быть намеренно сконструирован для потребления достаточного количества этих предложений вместе, чтобы вызвать переполнение.
Поэтому это лучше всего понимать как путь выполнения с низкой вероятностью и чрезвычайно высоким теоретическим воздействием, а не как ошибку, которую обычные пользователи XRP могли бы неосознанно вызвать.
Почему проверка безопасности предложения XRPL не сработала?
Самая технически важная часть инцидента не просто в том, что существовало целочисленное переполнение. Зрелое финансовое программное обеспечение часто содержит несколько защитных слоев, предназначенных для обнаружения именно такого рода неожиданных результатов.
У XRPL был один: инвариант транзакции, предназначенный для обеспечения того, чтобы транзакция не могла создать XRP. В принципе, даже если платежный движок допустил ошибку учета, инвариант должен был заметить, что общие балансы XRP увеличились, и отклонить транзакцию.
Этого не произошло.
Причина — классический отказ якобы независимых систем безопасности. Инвариант вычислял чистое изменение XRP, используя аналогичный тип непроверяемой арифметики. Когда платёжный движок переполнялся, вычисление инварианта могло переполниться в том же направлении, из-за чего результирующая транзакция выглядела так, будто изменение предложения XRP равно лишь обычной комиссии за транзакцию.
Проверка безопасности не является по-настоящему независимой, когда она может воспроизвести тот же режим отказа, что и проверяемая ею система.
Вторая защита проверяла, превышает ли баланс отдельного счёта общее предложение XRP. Она также не смогла остановить атаку, потому что вновь созданные XRP можно было распределить по сотням счетов, удерживая баланс каждого отдельного счёта ниже лимита.
Поэтому исправление затронуло как непосредственную ошибку, так и защитную архитектуру. xrpld 3.4.1 добавил явные проверки переполнения при агрегировании сумм по офферам и платёжным путям. XRPL также изменил инвариант «XRP не создано», чтобы использовать более широкий счётчик, который не может обернуться в тех же условиях.
Почему ошибка 2015 года оставалась скрытой так долго?
Ответ частично кроется в разнице между реалистичными экономическими значениями и теоретическими пределами компьютеров. Отдельные платежи в XRP работают на много порядков ниже диапазона, необходимого для переполнения 64-битной суммы. Обычный трейдер мог использовать XRPL годами, не создавая ничего похожего на вредоносные числовые условия.
Это делало уязвимость трудно выявляемой при обычном использовании. Уязвимая логика могла работать корректно на протяжении миллиардов нормальных операций и при этом катастрофически отказывать на искусственной границе.
Уязвимость также демонстрирует, почему долгоживущий код блокчейна не следует автоматически считать безопасным только потому, что он работал много лет. История эксплуатации — полезное свидетельство, но она в основном проверяет обычные состояния. Злоумышленники намеренно ищут состояния, которые обычные пользователи никогда не создают.
XRPL приписал обнаружение проблемы своей программе Bug Bounty и обрисовал более широкий подход к эшелонированной защите, включающий независимые аудиты, публичные attackathons, фаззинг, red teaming с поддержкой ИИ и формальную верификацию. Он также добавляет повторную проверку исправлений безопасности на релиз-кандидатах до формального закрытия находок.
Этот подход важен, потому что урок из этого инцидента не в том, что зрелому коду нельзя доверять. Он в том, что зрелый код всё ещё требует состязательного тестирования против допущений, которые разработчики перестали ставить под сомнение годы назад.
Что эта ошибка означает для фиксированного предложения XRP?
XRP начал с определённого начального предложения в 100 миллиардов токенов, без протокольного механизма, аналогичного майнингу proof-of-work, который непрерывно создаёт дополнительные XRP. Комиссии за транзакции уничтожаются, а не выплачиваются валидаторам, поэтому предполагаемый путь предложения является неинфляционным.
Уязвимость XRP Ledger выявляет важное различие между денежно-кредитной политикой как правилом и денежно-кредитной политикой как программным обеспечением, обеспечивающим соблюдение.
Спецификация блокчейна может утверждать, что новые XRP не могут быть созданы, но узлы в конечном итоге обеспечивают соблюдение этого свойства через код. Если логику перехода балансов можно манипулировать так, чтобы нарушить правило, то сама экономическая политика может потерпеть неудачу, даже если документированная политика не изменилась.
Этот инцидент не продемонстрировал, что фактическое обращающееся предложение XRP было тайно увеличено. XRPL заявляет, что эксплуатации в публичной сети обнаружено не было. Но он продемонстрировал, что до патча существовал теоретический путь выполнения, способный обойти одно из самых фундаментальных денежных ограничений реестра.
Это делает данную уязвимость более значимой, чем временный сбой RPC или проблема с подключением узлов. Сеть может выдерживать определённые нарушения инфраструктуры без компрометации целостности активов. Ошибка, способная генерировать расходуемые единицы, затрагивает саму учётную основу реестра.
Почему исправление важнее отсутствия эксплуатации
Возникает соблазн отмахнуться от уязвимости, как только следователи заявляют, что она никогда не эксплуатировалась. Это означало бы упустить более полезный урок безопасности.
График реагирования XRPL был относительно сжатым: о проблеме сообщили и воспроизвели 22 сентября, исправление было разработано и проверено 22–23 сентября, объединено в релизную ветку 3.4.1 и выпущено 25 сентября. XRPL сообщил, что более 80% валидаторов из стандартного Unique Node List запускали защищённую версию в тот же день.
Исправление платёжного движка также вступило в силу непосредственно при обновлении программного обеспечения, а не в ожидании обычного процесса активации поправки. Это стало возможным потому, что отклонение арифметического переполнения было сочтено исправлением неопределённого или небезопасного поведения, а не введением нового предполагаемого правила транзакций.
Для безопасности блокчейна время раскрытия информации является частью защиты. Публикация эксплойта до того, как валидаторы были защищены, превратила бы теоретическую уязвимость в операционные инструкции для атакующих. Поэтому XRPL раскрыл технические детали после того, как исправленная версия уже распространилась.
Риски и ограничения
Инцидент серьёзен, но несколько границ должны оставаться чёткими.
- Подтверждённого события инфляции нет: XRPL заявляет, что не нашёл доказательств эксплуатации в публичной сети.
- Случайного срабатывания нет: обычные платежи и реалистичные книги ордеров не достигают необходимых значений.
- Внедрение патча имеет значение: операторы серверов должны запускать
xrpld 3.4.1или новее. - Одно исправление не доказывает полную безопасность: другие старые арифметические допущения всё ещё требуют состязательного тестирования.
- Историческое отсутствие злоупотреблений не может заменить формальную верификацию: некоторые классы ошибок слишком необычны, чтобы проявиться через нормальную сетевую активность.
Ещё одно ограничение — ретроспективная уверенность. Исследователи могут анализировать историю реестра и известные шаблоны эксплойтов, но доказать, что уязвимость никогда не использовалась, по своей сути отличается от математического доказательства того, что она не могла быть использована. Поэтому официальный вывод уместно сформулирован как доказательств не найдено, а не как абсолютное утверждение о каждом историческом состоянии.
Взгляд MEXC: фиксированное предложение — это свойство безопасности программного обеспечения
Денежная политика блокчейна не обеспечивается одним лишь числом предложения, записанным в документации. Она обеспечивается программным обеспечением, которое проверяет каждое изменение баланса, путь транзакции и состояние реестра.
Инцидент с XRPL иллюстрирует, почему это различие важно. Предусмотренное протоколом правило запрещало создание новых XRP, однако ошибка в арифметике теоретически могла нарушить это правило. Что ещё важнее, защитный инвариант, предназначенный для обнаружения создания предложения, изначально имел тот же режим отказа.
Для зрелых блокчейн-сетей безопасность поэтому должна выходить за рамки проверки того, правильно ли ведут себя обычные транзакции. Независимые инварианты, фаззинг, состязательное тестирование граничных случаев и формальные методы становятся всё более важными именно потому, что наиболее разрушительные уязвимости могут существовать в путях кода, которых обычные пользователи никогда не касаются.
Показатель, за которым стоит следить после этого раскрытия, — не реакция цены XRP. Это то, будут ли расширенные процессы верификации XRPL последовательно находить и изолировать аналогичные классы скрытого риска протокола раньше, чем это сделают атакующие.
Ошибка десятилетней давности была критической, но не доказанным событием инфляции XRP
Уязвимость XRP Ledger заслуживает описания «критическая», потому что она теоретически могла подорвать одну из самых фундаментальных гарантий XRPL. Тщательно сконструированный платёж мог вызвать 64-битное арифметическое переполнение, зачислить сотни владельцев оферт XRP и списать с покупателя лишь часть совокупной суммы. Новосозданные балансы были доступны для расходования в собственном воспроизведении атаки в XRPL.
Но вторая половина истории столь же важна. XRPL не нашёл доказательств эксплуатации в публичной сети, транзакция требовала намеренно аномальных условий книги ордеров, а уязвимость была исправлена в xrpld 3.4.1 до публичного раскрытия технических деталей.
Поэтому инцидент не следует переписывать как доказательство того, что предложение XRP исторически было завышено. Его значение более структурное. Он показывает, что даже блокчейн с фиксированным предложением в конечном счёте зависит от того, правильно ли программное обеспечение обеспечивает соблюдение денежных ограничений в граничных случаях, которые могут оставаться невидимыми годами.
Самый сильный вывод из этой уязвимости XRP Ledger, следовательно, касается инженерии протокола, а не заголовков о предложении токенов. Денежные инварианты нуждаются в независимой реализации, старый код всё ещё требует состязательного анализа, а успешная работа сети на протяжении десятилетия не устраняет возможность скрытых отказов на граничных условиях. Ошибка не доказала, что XRP был выпущен сверх нормы; она доказала, почему целостность предложения должна постоянно проверяться.
Источники
Официальное раскрытие уязвимости XRPL:
https://xrpl.org/es-es/blog/2026/vulnerabilitydisclosurereport-bug-20261009
Информация о выпуске XRPL 3.4.1:
https://xrpl.org/blog
Хотите быстрее всего получать последние новости MEXC? Присоединяйтесь к нашему официальному Telegram-каналу прямо сейчас!
Платформа MEXC: Скачать приложение | Торговля без комиссии | Купить USDT сейчас Присоединяйтесь к сообществу MEXC: X (Twitter) | Telegram | Discord
Получить информацию: Академия для новичков | Условия обслуживания | MEXC Blog | MEXC News
Верификация аккаунта: Узнать о KYC | Как пройти KYC
Предупреждение о рисках: Содержание данной статьи предназначено только для справки и не является инвестиционной рекомендацией. Рынок цифровых валют отличается высокой волатильностью, пожалуйста, принимайте решения осмотрительно с учётом вашей личной ситуации.
