Топ-3 инцидентов в сфере DeFi за март
Resolv Protocol: ~$80 млн
22 марта 2026 года Resolv подвергся взлому, приведшему к убыткам в размере $80 млн*.
Первопричиной стала компрометация привилегированных ключей инфраструктуры. Используя украденный ключ, злоумышленник воспользовался привилегированным процессом завершения сделок (swap-finalization) и выпустил более 80 млн USR без обеспечения, совершив три эксплойт-транзакции. Несмотря на очевидность первопричины, этот инцидент выявил общую нехватку механизмов безопасности как on-chain, так и off-chain. Проект не обеспечил строгую проверку при одобрении выпуска токенов, а также не имел стратегий мониторинга для своевременного обнаружения и реагирования на взлом.
Примечательно, что последствия вышли далеко за пределы несанкционированного выпуска 80 млн USR. Поскольку активы Resolv широко использовались в качестве залога во многих протоколах кредитования, потеря привязки (depeg) вызвала более масштабное заражение. Как сообщила компания Chaos Labs, on-chain кураторы, использующие автоматизированное распределение ликвидности для получения доходности, не имели инструментов контроля рисков в реальном времени и продолжали направлять новый капитал на уже скомпрометированные рынки. То, что началось как локальный эксплойт, быстро переросло в кросс-протокольную эпидемию, оставив протоколы кредитования с миллионами безнадежных долгов.
*Убыток оценен на основе привязки стоимости USR к $1.
BitcoinReserveOffering: ~$2,7 млн
5 марта 2026 года контракт BitcoinReserveOffering в сети Ethereum был взломан, ущерб составил около $2,7 млн.
Первопричиной стала ошибка в бизнес-логике функции mint(), которая дважды выполняла логику выпуска токенов при обработке полного депозита ERC-3525 SFT. Поскольку ERC-3525 наследуется от ERC-721, безопасные переводы вызывают обратный вызов onERC721Received(). Внутри этого вызова рассчитывалось количество токенов BRO, которые затем выпускались на адрес отправителя. Однако после завершения обратного вызова внешняя функция mint() возобновляла работу и выполняла вторую операцию выпуска, что удваивало количество BRO, выданных за один депозит. Это позволило злоумышленнику раздуть свой баланс BRO с помощью повторяющихся циклов сжигания и выпуска монет в ходе данной транзакции.
Для предотвращения подобных проблем протоколы должны гарантировать, что учет активов происходит ровно один раз за операцию депозита, а обновление состояния фиксируется до любого внешнего вызова, способного инициировать обратный вызов. Кроме того, следует добавить проверки инвариантов, чтобы гарантировать, что объем выпущенных токенов никогда не превышает стоимость базового обеспечения.
Venus Protocol: ~$2,15 млн
15 марта 2026 года рынок THE (Thena) в протоколе Venus в сети BNB Chain подвергся атаке через донат (donation attack) в сочетании с манипуляцией рынком. Этот инцидент привел к возникновению около $2,15 млн безнадежных долгов протокола, при этом сам атакующий понес чистый убыток в размере ~$4,7 млн.
Venus — это протокол кредитования, основанный на форке Compound V2. Затронутый рынок использует THE в качестве базового актива, который обладает низкой ликвидностью в сети. Атака через донат стала возможной, так как контракт рынка рассчитывает totalCash на основе «сырого» баланса контракта. Это позволило злоумышленнику напрямую пожертвовать THE в рынок, что увеличило показатель totalCash и раздуло exchangeRate (курс обмена). Используя это завышенное обеспечение, атакующий брал в долг ликвидные активы, обменивал их на большее количество THE и повышал рыночную цену THE. Полученные токены THE затем снова жертвовались в рынок, постоянно усиливая масштаб атаки.
Этот инцидент служит предупреждением для протоколов кредитования по двум направлениям: логика учета и конфигурация рисков. Протоколы должны внедрять механизмы учета, устойчивые к манипуляциям, которые точно отражают стоимость активов и не подвержены влиянию атак через донат. Кроме того, критически важные параметры риска, такие как лимиты на внесение обеспечения (supply caps), лимиты на заимствования (borrow caps) и коэффициенты LTV (кредит-к-залогу), должны быть тщательно настроены, чтобы ограничить риски протокола.
Для подробного анализа прочтите наш углубленный материал:
https://blocksec.com/blog/venus-thena-donation-attack
Представленная выше информация основана на данных по состоянию на 00:00 UTC, 31 марта 2026 года.
На этом мы завершаем краткий обзор инцидентов безопасности за март. Для более глубокого анализа инцидентов безопасности блокчейна и трендов в Web3 вы можете изучить наши ресурсы.
Вы можете узнать больше в нашей Библиотеке инцидентов безопасности.
Будьте в курсе и в безопасности!
