Уязвимость в заброшенном контракте Aztec Connect обернулась потерей $2,1 млн: детальный разбор инцидента
Сегодня я получил сигнал о серьезном инциденте в экосистеме Aztec Network. Злоумышленник сумел вывести приблизительно $2,1 млн из устаревшего смарт-контракта платформы Aztec Connect — решения для приватных транзакций, которое было деактивировано еще в 2023 году. Атака затронула immutable-контракт, не подлежащий обновлению, что сделало защиту средств невозможной.
Как произошла атака?
Согласно моему анализу, корень проблемы кроется в несоответствии между логикой верификации транзакций и их финальным расчетом на уровне Ethereum (L1). Эксперты BlockSec уже указали на то, что из-за различий в интерпретации списка транзакций контракт мог зачислять средства без должной проверки в основной сети. Злоумышленник воспользовался этим, создав необеспеченные балансы и проведя вывод по семи различным активам.
Что было похищено?
Данные от Certik подтверждают масштаб: среди украденных активов — 909 ETH, 270 000 DAI, 167 wstETH и ряд других токенов. Важно подчеркнуть, что атака была направлена исключительно на старую инфраструктуру Aztec Connect, которая с марта 2023 года не принимала депозиты. Команда Aztec Labs заверила, что текущая сеть проекта и средства пользователей в ней не пострадали.
Почему это произошло именно сейчас?
Aztec Connect был запущен в 2022 году как DeFi-мост для приватных операций. После его деактивации команда полностью переключила ресурсы на разработку нового L2-протокола Ignition Chain, который был запущен в мейннете Ethereum в ноябре 2025 года. Ключевой момент: разработчики не имеют административных ключей к старым контрактам и не могут их остановить или обновить. Это классический пример риска «мертвого кода», когда заброшенные, но все еще активные контракты становятся мишенью для хакеров.
Мой экспертный вывод
Этот инцидент служит суровым напоминанием для всей индустрии. Даже если протокол прекратил работу, средства, оставшиеся в immutable-контрактах, остаются уязвимыми. Командам необходимо предусматривать механизмы безопасного вывода ликвидности при деактивации, а пользователям — своевременно выводить активы из устаревших версий. В данном случае злоумышленник просто воспользовался «спящей» уязвимостью, которую никто не мог исправить. Это еще один аргумент в пользу более тщательного аудита lifecycle-процессов в DeFi.