Топ-3 инцидента в DeFi за апрель
KelpDAO: ~$290M
18 апреля 2026 года мост rsETH LayerZero OFT проекта KelpDAO был взломан на сумму около $290M.
Первопричиной стала небезопасная конфигурация DVN 1-из-1 в KelpDAO, из-за которой верификация кроссчейн-сообщений свелась к единой точке отказа. Скомпрометировав RPC-инфраструктуру, которой доверял LayerZero Labs DVN, злоумышленник заставил единственного верификатора подтвердить сфабрикованное кроссчейн-сообщение. В результате 116 500 rsETH были выпущены в сети Ethereum без соответствующего исходного события в сети Unichain.
Причиной этого инцидента стала не уязвимость в самом протоколе LayerZero, а более масштабный сбой в операционной безопасности, затронувший конфигурацию моста и предположения о доверии к инфраструктуре. Поскольку KelpDAO полагался только на один DVN, не было независимого верификатора, способного оспорить подделанное сообщение. При этом злоумышленник отравил RPC-узлы, используемые этим DVN, и провёл DDoS-атаку на оставшиеся исправные узлы, вынудив верификатора перейти в аварийный режим, в котором он полностью зависел от данных, контролируемых злоумышленником. После того как поддельное сообщение было подтверждено, адаптер rsETH на стороне Ethereum отработал согласно своей логике и выпустил средства, которые затем были быстро распределены и отмыты через несколько кошельков и сетей.
Этот инцидент показывает, что безопасность моста не может полагаться исключительно на корректность протокола. Проектам следует внедрять конфигурации с несколькими независимыми DVN-верификаторами, рассматривать внезапные отключения RPC-узлов во время верификации как сигнал атаки, а не как рядовую проблему доступности, и усиливать защиту инфраструктуры, поставляющей данные исходной сети сетям верификаторов.
Подробный разбор читайте в нашем аналитическом посте:
Drift Protocol: ~$285M
1 апреля 2026 года протокол Drift Protocol в сети Solana был взломан на сумму около $285M.
Первопричиной стала не уязвимость смарт-контракта, а сбой в процессе управления протоколом и авторизации. На тот момент Drift использовал мультиподпись 2-из-5 для действий с высокими привилегиями, то есть любые два из пяти уполномоченных подписантов могли утвердить критические административные изменения. Эти действия также не были защищены таймлоком. Как только собиралось достаточное количество подтверждений, их можно было исполнить немедленно. Дополнительный риск создавал механизм долговечных nonce в Solana, позволяющий заранее подписанным транзакциям оставаться действительными в течение длительного времени, вместо того чтобы быстро истекать, как обычные транзакции. Это дало злоумышленнику время заранее собрать вредоносные подписи и дождаться подходящего момента для их использования. Склонив двух из пяти подписантов утвердить вредоносные транзакции управления, злоумышленник впоследствии отправил эти транзакции, чтобы получить контроль над административными функциями протокола. Получив такой доступ, злоумышленник добавил поддельный залоговый актив под названием CarbonVote Token (CVT), манипулировал его ценой через оракул, ослабил ограничения на вывод средств и использовал поддельный залог для вывода крупных сумм реальных активов через Drift Vault.
Этот инцидент выявил три серьёзные слабости в системе управления Drift. Во-первых, злоумышленник смог разделить процесс сбора подписей и исполнения транзакций, поскольку украденные подтверждения не истекали быстро. Во-вторых, отсутствие таймлока привело к тому, что захват административных прав вступил в силу немедленно, практически не оставив времени на обнаружение или вмешательство. В-третьих, роль администратора обладала слишком большими полномочиями: после компрометации она позволила злоумышленнику создать новый залоговый рынок, изменить настройки оракула и ослабить контроль вывода средств — всё это напрямую способствовало краже.
Этот инцидент показывает, что безопасность управления — это не только защита приватных ключей. Протоколам также необходимо обеспечивать безопасность всего процесса подписания и утверждения, добавлять задержки для действий с высокими привилегиями, ограничивать использование долгоживущих заранее подписанных транзакций и сокращать масштаб возможностей, которые открывает захват единого административного доступа.
Подробный разбор читайте в нашем аналитическом посте:
Rhea Finance: ~$18.4M
16 апреля 2026 года протокол Burrowland от Rhea Finance в сети NEAR был взломан на сумму около $18.4M из-за ошибки в бизнес-логике его модуля маржинальной торговли. Примечательно, что по состоянию на 23 апреля 2026 года все украденные средства были возвращены.
Первопричина заключалась в том, что протокол воспринимал заявленный пользователем результат свопа как точно отражающий сумму, которая фактически будет возвращена биржей DEX. Однако злоумышленник мог построить циклический путь свопа, повторно использующий промежуточные результаты в рамках маршрута, искусственно завышая заявленный итоговый результат и манипулируя учётом в протоколе. В результате проверки платёжеспособности и кредитного плеча протокола опирались на сфабрикованное значение, а не на реально полученную сумму. Причиной этой уязвимости стала функция verify_token_out(), которая неправильно засчитывала определённые промежуточные результаты как часть итогового результата, хотя впоследствии они повторно использовались в рамках пути свопа.
Обойдя эти проверки, злоумышленник вывел заимствованные активы из протокола через контролируемые им поддельные пулы, при этом протокол получал взамен лишь незначительное количество ценности. Затем злоумышленник вывел ликвидность из этих пулов, чтобы извлечь средства. Повторяя этот процесс, злоумышленник в итоге вывел из Burrowland около $18,4 млн.
Этот инцидент показывает, что протоколы маржинальной торговли не должны воспринимать заявленные пользователем результаты свопа как доверенные входные данные. Протоколам необходимо обеспечивать, чтобы проверки платёжеспособности основывались на фактически полученной стоимости, отклонять пути свопа, допускающие повторное использование промежуточных активов, и предотвращать возможность манипуляции логикой учёта посредством циклической маршрутизации.
Лучший аудитор безопасности для Web3
Проверяйте архитектуру, код и бизнес-логику перед запуском
Приведённая выше информация актуальна по состоянию на 00:00 UTC, 29 апреля 2026 года.
На этом завершается обзор инцидентов безопасности за апрель.
Подробнее вы можете узнать в нашей Библиотеке инцидентов безопасности.
Будьте в курсе и оставайтесь в безопасности!
