Аудированные протоколы DeFi потеряли 885 миллионов долларов из-за атак, произошедших полностью вне их аудиторских рамок

В децентрализованных финансах "аудированный" часто представляется как вердикт по всему проекту. На практике аудит обычно охватывает названный код, компоненты и версии на определенный момент времени. Все, что добавляется, исключается или функционирует вокруг этой границы, может нести другой уровень уверенности.

Новая предвариантная работа ставит цифры на этот разрыв. Исследователи, связанные с компанией безопасности ack3 и Чешским техническим университетом в Праге, изучили 135 зарегистрированных инцидентов за первую половину 2026 года с общими потерями в 939,86 миллиона долларов. Они нашли идентифицируемые публичные прединцидентные аудиты для 68 инцидентов.

Внутри этого подмножества из 68 инцидентов авторы классифицировали 46 путей атак как находящиеся вне всех аудиторских рамок, которые они могли идентифицировать, 20 как находящиеся внутри хотя бы одной рамки и два как неразрешенные. Группа инцидентов вне рамок составила 67,6% инцидентов, но 94,4% их зарегистрированных потерь.

Этот поразительный процент не является оценкой эффективности аудита или доказательством того, что границы аудита вызвали убытки. Он описывает распределение потерь в выбранном наборе зарегистрированных инцидентов. Два крупных случая также доминируют в этом: после исключения 292 миллионов долларов на Kelp DAO и 285 миллионов долларов на Drift Protocol доля вне рамок падает до 72,1% потерь в том же подмножестве инцидентов с аудитом.

Даже с этими ограничениями исследование выявляет основную проблему уверенности. Проект может правдиво заявить, что он был аудирован, оставляя пользователей не в состоянии определить, была ли проверена живая система, путь, удерживающий их средства, и контроль вокруг него.

Что на самом деле показывает данные

Набор данных ack3 охватывает инциденты с 1 января по 29 июня. Его авторы оценили 122 как подтвержденные и 13 как вероятные. В полном наборе 35 не имели идентифицированного аудита, а 32 имели неизвестную историю аудита, поэтому ни одна из групп не появляется в расчете по 68 инцидентам.

Для группы из 68 инцидентов инциденты вне рамок составили 680,97 миллиона долларов из 721,24 миллиона долларов зарегистрированных потерь, что дало 94,4%. Исключив Kelp DAO и Drift Protocol, осталось 103,97 миллиона долларов из 144,24 миллиона долларов вне рамок, или 72,1%. Машиночитаемый реестр воспроизводит подсчеты ведер и суммы потерь.

Метки внутри или вне остаются суждениями исследователей о публичных доказательствах. Они искали архивы проектов и аудиторов, находили прединцидентные отчеты и сравнивали конечные пути атак с проверенным кодом, версиями и исключениями. Работа представляет собой шесть страниц предвариантного документа, созданного с издателем набора данных, и два автора связаны с ack3, которая продает обзоры безопасности.

Исследование также не имеет неэксплуатируемой группы сравнения и меры того, как долго каждая система была подвержена риску. Оно не может установить, безопаснее ли в целом аудированные протоколы, оценить вероятность инцидента или показать, что выход за рамки вызвал каждую потерю. Необъявленные аудиты и частные инциденты могут отсутствовать, в то время как зарегистрированные цифры потерь не идеально сопоставимы.

Таким образом, исследование поддерживает ограниченный вывод: история аудита и рамки аудита — это разные переменные. Проверенный смарт-контракт не автоматически предоставляет ту же уверенность для обновления, привилегированного ключа, фронтенда, релеера, оракула, облачной службы или процесса реагирования на инциденты.

Два инцидента из августа иллюстрируют это различие разными способами. Сеть ICON предоставляет прямой пример проверенного кода, который не сработал на границе между двумя проверками. Инцидент aelf в августе предоставляет контрастный случай, поскольку доступные доказательства аудита еще не могут быть связаны с его зарегистрированным путем выполнения.

Согласно постмортему ICON Foundation от 30 августа, миграционный контракт использовал высокие биты серийного номера сообщения о выводе, чтобы определить, является ли оно уникальным. Криптографическая подпись охватывала только низкие 256 бит. Изменив не подписанные высокие биты, злоумышленник повторно отправил два законно подписанных сообщения о выводе 1492 раза за примерно 20 минут. ICON сообщила, что 1490 вызовов увенчались успехом.

Пропущенная проверка ICON

Повторные запросы выпустили 119,866 миллиона ICX и 531,600 bnUSD. На момент постмортема ICON оценила подтвержденные чистые убытки примерно в 150,2 ETH плюс 31,204 USDC. Она сообщила, что 531,600 bnUSD и 1,366 миллиона SODA были восстановлены, и что пользовательские депозиты, балансы и позиции не пострадали.

ICON заявила, что миграционный контракт прошел внешнюю проверку, и что рекомендации были реализованы, включая изменения в той же области. Также было сказано, что соответствующая логика реле получила специальный обзор. Архив аудита SODAX содержит восемь отчетов по различным компонентам, включая аудит реле в ноябре 2025 года.

Тем не менее, постмортем указал, что точное несоответствие между проверкой уникальности и подписанным значением вышло за рамки этих выводов. Значок на уровне проекта не мог сообщить пользователю, согласованы ли обе стороны пути вывода по тому, что делает сообщение уникальным.

Хронология реакции добавляет второй вид границы. Первый автоматический сигнал ICON сработал в 02:08 UTC, примерно через семь минут после начала эксплуатации. Сотрудники открыли расследование около 03:40, приостановили затронутый контракт в 03:53 и остановили сеть в 06:18:54.

ICON объяснила примерно 90-минутный разрыв между первым сигналом и полной реакцией на инцидент настройкой сигналов. Класс сигналов вызывал ложные срабатывания во время несвязанных инцидентов с подключением и не уведомлял дежурную команду с необходимой серьезностью. Фонд заявил, что планирует автоматический триггер отключения, более низкие пороговые значения для автоматического отключения и последующий обзор, сосредоточенный на уникальности сообщений и защитах от повторных запросов.

Эти меры не заменяют аудит. Они предоставляют доказательства для другого вопроса: когда профилактика терпит неудачу, как быстро обнаружение может стать сдерживанием?

aelf показывает, почему обеспечение должно оставаться актуальным

aelf's инцидент в августе проверяет аргумент с другой стороны. Его публичный отчет описывает компрометацию во время выполнения и контролируемое восстановление, но не предоставляет достаточно доказательств, чтобы поместить путь внутрь или снаружи конкретного прединцидентного аудита.

Компания объявила о приостановке сети 18 августа. В своем обновлении от 26 августа aelf сообщила, что несанкционированный смарт-контракт мог использовать параметры транзакции для доставки закодированных .NET сборок и инструкций в путь выполнения узла.

Временный отчет связал инцидент с пробелами в проверках для отражения времени выполнения и динамической загрузки, вместе с слабой изоляцией между выполнением контракта и чувствительными ресурсами узла или инфраструктуры. aelf идентифицировала 155 связанных транзакций и пять уникальных сборок полезной нагрузки с возможностями, включая выполнение команд хоста, попытки исходящей связи, доступ к ключу узла и разведку инфраструктуры.

Способности не равны подтвержденному выполнению. aelf заявила, что полезные нагрузки не доказали, что каждый сборка была выполнена, что каждая целевая учетная запись была получена или что конфиденциальные данные покинули ее системы. Компания сообщила, что она меняет ключи подписи и учетные данные инфраструктуры в соответствии со стандартом потенциального воздействия.

Общественный статус оставался предварительным 11 сентября: индекс блога aelf не содержал никаких конкретных инцидентов, опубликованных после 26 августа. Заявление от 26 августа обязывало к следующему обновлению и окончательному обзору.

Документация по безопасности aelf утверждает, что ее блокчейн и контракты токенов ELF прошли несколько аудитов, в ходе которых не было выявлено проблем с безопасностью. Однако доступные страницы не связывают конкретный отчет до инцидента с описанным в августе путем выполнения. Таким образом, назвать инцидент либо упущением аудита, либо не относящимся к области действия сбоем было бы недостаточно обоснованным.

Эта неопределенность сама по себе полезна. Датированная история аудита может быть отделена от текущего кода системы, зависимостей и операционного состояния. Пользователям нужна запись о гарантии, которая была бы версионирована и достаточно конкретной, чтобы выявить это отклонение.

Такая запись должна называть проверяемый репозиторий и коммит, развернутые адреса, исключенные компоненты, привилегированные роли и зависимости. Она также должна фиксировать обновления с момента проверки, хранение ключей и их ротацию, изоляцию во время выполнения, поведение сигнализации и автоматического отключения, а также датированный статус восстановления, который отделяет подтвержденные потери от замороженного или нерешенного воздействия.

Это не уменьшает ценность аудита. Это делает заявление пропорциональным выполненной работе и связывает эту работу с системой, работающей сейчас.

Значок аудита не может ответить на вопрос, разделяют ли проверяемый артефакт, развернутая система и механизмы, реагирующие на сбой, все еще одну и ту же границу безопасности.