Beosin: В мае зафиксировано 36 основных инцидентов безопасности, общий ущерб превысил 76 млн долларов США

Автор: Beosin

Согласно данным мониторинговой платформы Beosin Alert, в мае 2026 года совокупные потери от инцидентов безопасности составили около 76,15 млн долларов США. Зафиксировано 36 крупных хакерских атак, основными причинами которых стали уязвимости смарт-контрактов и утечка приватных ключей. Из них 17 инцидентов связаны с уязвимостями контрактов или сетей, а 10 — с утечкой приватных ключей. Это ставит под серьёзное давление как кодовую, так и операционную безопасность экосистемы DeFi.

Топ-10 протоколов по объёму потерь за май

Наибольший ущерб нанесён мосту Verus-Ethereum Bridge, обеспечивающему взаимодействие между блокчейнами Verus L1 и Ethereum. Атака произошла из-за уязвимости в смарт-контракте и привела к потерям в размере 11,58 млн долларов США. В случае с протоколом Echo Protocol злоумышленники, получив доступ к приватному ключу, отчеканили 1000 токенов eBTC (номинальная стоимость — около 76,7 млн долларов США), однако из-за ограниченной ликвидности фактическая выгода составила лишь около 5,13 млн долларов США.

Типы атакуемых проектов и распределение потерь по блокчейнам

Атаки затронули широкий спектр объектов: кроссчейн-мосты, децентрализованные биржи (DEX), кредитные протоколы, прогнозные рынки, стейблкоины и обычных пользователей. Наибольшие потери понесли кроссчейн-мосты — 27,995 млн долларов США. При этом наибольшее количество атак (14 случаев) пришлось на проекты DeFi.

Больше всего средств было утрачено в блокчейне Ethereum — более 48,76 млн долларов США. Большинство инцидентов, связанных с кроссчейн-мостами и DeFi-протоколами, также происходило именно в этой сети. На втором месте — BNB Chain, Monad и TON. Кроме того, были зафиксированы инциденты безопасности в Monero и Bitcoin, что свидетельствует о многоцепочечной природе современных атак.

Анализ ключевых инцидентов безопасности

1. Verus: недостаток проверки межцепочечных сообщений

Мост Verus-Ethereum Bridge функционирует следующим образом: отправитель предоставляет доказательные данные, подтверждающие наличие на цепочке Verus действительного выхода, одобренного нотариусом; после верификации этих данных контрактом моста активы разблокируются в сети Ethereum. Уязвимость заключалась в том, что контракт моста в Ethereum действительно проверял доказательства, поступающие из Verus, но не проверял, является ли соответствующий выход действительно действительным. Это позволило злоумышленникам создавать фальшивые выходы, проходящие проверку, и выводить средства, значительно превышающие их депозиты.

Фрагмент уязвимого кода:

Уязвимость, использованная в данном инциденте, относится к тому же классу, что и инциденты Wormhole (потери в 320 млн долларов США в 2022 году) и Nomad (потери в 190 млн долларов США в 2022 году): в обоих случаях мост проверял корректность сообщения, но игнорировал проверку соответствия его содержания реальным денежным средствам.

2. Trusted Volumes: дефект параметров подписи

В ходе данной атаки злоумышленники воспользовались слабостью в механизме подписи процесса запроса цен (RFQ) протокола TrustedVolumes. При выполнении перевода они передали в качестве адреса отправителя контракт Resolver TrustedVolumes и успешно прошли проверку авторизации, тем самым переведя активы из этого контракта и получив прибыль.

Фрагмент уязвимого кода:

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

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

3. Инциденты утечки приватных ключей (на примере StablR)

В мае произошло несколько инцидентов утечки приватных ключей, общие потери от которых превысили 25 млн долларов США. StablR, как эмитент регулируемых стейблкоинов, стал типичным примером проблем с обеспечением безопасности и управления рисками в сегментах стейблкоинов и DeFi.

StablR выпустил два регулируемых стейблкоина: EURR и USDR. Мультиподписной кошелёк, контролирующий чеканку EURR, имеет адрес 0x8278D2881dBF8F6Fc01c98d196c4b16F1aade5Bc; мультиподписной кошелёк для USDR — 0xF45392bd2D6e6b8C5Dc26BA6c8a12889419B82F3.

Поскольку для инициирования транзакций из обоих мультиподписных кошельков требовалась всего одна подпись, злоумышленник, получив контроль над владельцем адреса 0xC73fD562de86d7860EE636C20813Bcb2cF4D550d, добавил адрес 0xD4677B5A8B1b97EA213Fdb876b0FcBAB3f9F6CD1 в оба указанных мультиподписных кошелька, тем самым получив полный контроль над возможностями чеканки токенов проекта:

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

Тренды угроз безопасности в Web3

Глубинной тенденцией в области безопасности Web3 в 2026 году стало системное расширение поверхности атак. Уязвимости возникают одновременно в коде, инфраструктуре, процессах взаимодействия и человеческих процедурах. Одних лишь периодических аудитов безопасности или автоматизированных инструментов недостаточно для покрытия таких областей, как операционная безопасность, безопасность на стороне сотрудников, облачная инфраструктура и программная цепочка поставок. Это предъявляет повышенные требования к обеспечению непрерывной операционной безопасности проектов Web3.

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