17 июня 2026 года произошёл уже второй за месяц инцидент со старым продуктом Aztec. На этот раз злоумышленник воспользовался функцией, которая изначально была создана для защиты пользователей в экстренной ситуации, — и именно её отсутствие должной проверки позволило вывести чужие активы.
Введение
Три дня ранее, 14 июня 2026 года, был атакован контракт Aztec Connect — другой старый продукт компании Aztec. На этот раз пострадал иной контракт: Aztec Private Rollup Bridge, а точнее его механизм аварийного вывода, который называется Escape Hatch («аварийный люк»).
Escape Hatch — это функция, заложенная в систему на случай форс-мажора: если основная инфраструктура перестанет работать или возникнут проблемы, пользователи должны иметь возможность вывести свои средства напрямую, без посредников. Идея правильная и важная для безопасности пользователей. Но в реализации этой конкретной функции была допущена ошибка.
Ход инцидента
1️⃣ Подготовка доказательства. Злоумышленник подготовил специальное доказательство (proof) для вызова функции Escape Hatch. Внутри этого доказательства указываются данные о том, какой актив нужно вывести, в каком количестве и на какой адрес отправить.
2️⃣ Три вызова функции. Адрес атакующего 0x6952d9246e9aFE8B887B2877225163436F78E97F три раза вызвал функцию Escape Hatch у контракта 0x737901bea3eeb88459df9ef1BE8fF3Ae1B42A2ba.
3️⃣ Получение активов. В переданных данных получателем был указан адрес самого злоумышленника. Контракт принял доказательство, не проверив, действительно ли указанный получатель имеет право на этот вывод — и просто выпустил активы согласно переданным данным. В результате на адрес атакующего поступили 1,158 ETH, 150 000 DAI и 0,46963295 renBTC (renBTC — токенизированная версия биткоина, выпущенная для использования в сети Ethereum).
Почему это стало возможным
Механизм Escape Hatch был устроен так: контракт принимал доказательство, а затем выпускал активы строго по данным, зашитым внутри этого доказательства — какой актив, сколько и куда. Но в этой логике не хватало одной важной проверки: контракт не убеждался, что адрес-получатель действительно имеет право претендовать на указанные активы.
Иными словами, система верила данным внутри доказательства на слово, вместо того чтобы дополнительно сверить, принадлежат ли эти активы именно тому, кто их запрашивает. Злоумышленнику оставалось просто указать свой собственный адрес как получателя — и контракт это пропустил.
Ситуацию усугубляло то, что контракт был старым и уже не использовался как актуальный продукт. У команды Aztec не было административных инструментов, чтобы быстро остановить контракт или заблокировать вывод после обнаружения проблемы — как и в случае с предыдущим инцидентом 14 июня.
Детали расследования: движение средств
После получения активов на адрес 0x6952d9246e9aFE8B887B2877225163436F78E97F злоумышленник разделил небольшую часть средств на два адреса:
— 0x33d6A0D9BC210E823e043D604179cd844eb467df — 56 ETH
— 0x15930A0fEF3421F48c6553b5691682CC1b22EDb3 — 300 ETH
Основная часть похищенного — около 802 ETH, 150 000 DAI и около 0,469 renBTC — осталась на исходном адресе злоумышленника. Средства на всех трёх адресах на момент расследования остаются без движения.
Транзакции атаки:
0xab306cd2184d23b6ba3e151b10b3b9a0b81f211cc16f4f3b0c79f0b17a59c2b5
0x5c196c37a109d74c9797254287a0331f30e0daa637af241bd28fdc43774705c3
0x9e1d6ab7c20ae235409d7dd3a9cd47c04f07293585b3498b8beed82d6f6b03ca
Заключение
Это уже второй случай за месяц, когда старый, неиспользуемый продукт Aztec становится источником многомиллионного ущерба. И снова причина не во взломе серверов или краже паролей, а в логической ошибке: система не проверила, что получатель средств действительно имеет на них право.
Отсутствие административного контроля над устаревшими контрактами в обоих случаях лишило команду возможности оперативно вмешаться. Большая часть похищенных $2,18 млн до сих пор остаётся на адресах злоумышленника без движения.
Команда КоинКит продолжает отслеживать движение средств.
