Уязвимость в Taiko ERC20 Vault привела к потере более $1 миллиона в Ethereum

Обзор инцидента (22 июня 2026 г.)

Предупреждение о безопасности, опубликованное 22 июня 2026 г., указывает на то, что ERC20 Vault Taiko в Ethereum был взломан, а потери оцениваются более чем в $1 миллион. Затронутый компонент связан с межсетевым потоком активов Taiko — где токены депонируются в эскроу в Ethereum и высвобождаются на основе проверенных межсетевых сообщений.

Хотя расследование еще продолжается, первоначальная техническая версия фокусируется на верификации межсетевых сообщений: злоумышленнику предположительно удалось добиться принятия поддельных доказательств сообщений в Ethereum, что привело к несанкционированному высвобождению активов из хранилища. Для читателей, желающих получить больше информации об архитектуре моста Taiko (включая ERC20 Vault и концепции верификации на основе сигналов), публичные материалы и аудиты Taiko предоставляют полезный контекст, например, аудит протокола Taiko от OpenZeppelin и обзор безопасности Taiko от Code4rena.

Что такое “ERC20 Vault” в межсетевом мосте?

В большинстве стандартных мостов ERC20 Vault действует как эскроу-контракт в исходной сети:

• Пользователи депонируют токены ERC-20 в контракт vault в Ethereum.
• Мост передает сообщение в сеть назначения (Taiko L2), где пользователь получает соответствующее представление актива.
• При возврате активов сообщение (плюс доказательство) используется для авторизации высвобождения в Ethereum.

Эта конструкция концентрирует риск: vault может накапливать значительную TVL (общую заблокированную стоимость), а его безопасность в значительной степени зависит от пути проверки сообщений (а не только от логики передачи токенов). Мост Taiko и его контракты общедоступны в обозревателях, таких как страница контракта Taiko Bridge в Etherscan.

Предварительная основная причина: проверка доказательств принимает несуществующие события из исходной сети

Первоначальный анализ указывает на недостаток в логике проверки доказательств сигналов из исходной сети моста.

Концептуально, безопасный мост должен обеспечивать:

1. Фактическое создание сообщения в исходной сети (например, легитимное событие “MessageSent” или эквивалентное подтверждение состояния).
2. Криптографическую привязку представленного в Ethereum доказательства к этому точному событию/состоянию исходной сети.
3. Отсутствие повторного использования сообщения (защита от повторного воспроизведения) и соответствие параметров ожидаемым значениям.

В данном инциденте заявленный сценарий сбоя особенно опасен: Ethereum принял сфабрикованное доказательство, хотя оно не соответствовало легитимному сообщению, сгенерированному в Taiko. Это позволило бы злоумышленнику «зарегистрировать» и выполнить сообщение, которое исходная сеть никогда не авторизовывала — фактически превратив мост в механизм самостоятельного вывода средств.

Для разработчиков стоит пересмотреть, как в целом должны работать доказательства сигналов/сообщений в стиле Taiko (доказательства хранения против синхронизированных корней и т. д.). Полезным общим справочным материалом является исследование Ethereum, использующее Taiko в качестве примера потоков доказательства сообщений: Ethereum Research: SCOPE (кейс Taiko).

Почему это важно в 2026 году: сбои проверки мостов становятся закономерностью

К 2025–2026 годам наиболее значительные сбои в межсетевых мостах все чаще смещаются с "очевидных ошибок" на нарушение предположений о проверке на периферии — компрометация валидаторов, неполные проверки или некорректная привязка доказательств.

Ярким примером 2026 года стал сбой межсетевых сообщений, лежащий в основе отчета CoinDesk об эксплойте Kelp DAO, где слабости в проверке сообщений привели к масштабным несанкционированным выводам средств. Инцидент с Taiko ERC20 Vault, по-видимому, относится к той же категории рисков: безопасность моста не сильнее, чем инварианты проверки сообщений.

Что пользователи должны делать сейчас (Практическое руководство)

Если вы недавно взаимодействовали с мостом Taiko или связанными с ним контрактами, рассмотрите следующие защитные меры:

1. Избегайте использования моста до получения разъяснений

   • Временно приостановите новые депозиты/выводы средств, затрагивающие соответствующие пути моста, особенно если официальные рекомендации это подтверждают.

2. Проверяйте контракты и транзакции через обозреватель блоков

   • Используйте Etherscan, чтобы убедиться, что вы взаимодействуете с правильными адресами моста/vault, и отслеживайте исходящие переводы.

3. Пересмотрите одобрения токенов

   • Даже если эксплойт затрагивает vault (а не одобрения), уменьшение лимитов — это хорошая практика, особенно во время активных инцидентов, когда мошенники запускают поддельные сайты.
   • Вы можете просмотреть и отозвать одобрения с помощью Revoke.cash.

4. Разделите риски между кошельками

   • Используйте "горячий" кошелек для повседневной деятельности в dApp и отдельный холодный кошелек для долгосрочных вложений. Это ограничивает радиус поражения, если будет скомпрометирован интерфейс моста, RPC-маршрут или поток подтверждения.

Уроки для команд протоколов: инварианты проверки должны быть "не подлежащими обсуждению"

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

• Привязка доказательств к событиям должна быть строгой: целевая сеть должна принимать только те доказательства, которые могут быть связаны с точными подтверждениями из исходной сети.
• При сбоях — закрываться при неоднозначных доказательствах: если система не может однозначно связать сообщение с подтвержденным состоянием исходной сети, она должна отклонять, а не "принимать по возможности".
• Независимый мониторинг и быстрые стоп-краны: оповещения в реальном времени и автоматическое реагирование (приостановка, квоты, карантин сообщений) сокращают время локализации при нарушении предположений.

Опубликованные аудиты и обзоры Taiko (например, аудит OpenZeppelin) напоминают, что аудиты помогают, но мостам по-прежнему необходимо постоянное противодействие угрозам, телеметрия и операционные меры предосторожности после развертывания.

Снижение риска подписания во время инцидентов: как помогает аппаратный кошелек

Даже когда основная причина — это эксплойт смарт-контракта, потери пользователей часто усугубляются фишингом, поддельными dApp для "восстановления" и вредоносными запросами на одобрение, которые появляются сразу после появления заголовков.

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

По мере продолжения расследования Taiko ERC20 Vault общий вывод остается неизменным: безопасность межсетевых мостов — это, по сути, проблема верификации, и как протоколы, так и пользователи должны рассматривать интерфейсы проверки сообщений как инфраструктуру с высоким риском.