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