Топ-3 инцидентов безопасности в июне
Три крупнейших инцидента июня возникли не из-за какой-либо отдельной ошибки. Они обнажили общий провал. На поверхности гарантия безопасности выглядела нетронутой, но под ней она никогда не была реально обеспечена. MEV-бот доверял сделкам, которые казались прибыльными, не подтверждая, что разрешения были действительно израсходованы. Два выведенных из эксплуатации роллапа принимали доказательства, корректные по форме, но никогда не привязанные к состоянию расчётов, которое они якобы представляли. Код подписи кошелька молча отбрасывал единственный секретный входной параметр, от которого зависела его безопасность, превращая значение, которое должно было быть непредсказуемым, в нечто, что любой мог пересчитать из публичных данных. Ни одна из этих систем не была взломана методом криптоанализа грубой силой. Их взломало допущение, которое никто никогда не проверял.
JaredFromSubway: ~$15M
20 июня 2026 года оператор Ethereum MEV-бота JaredFromSubway был опустошён примерно на $15M в результате атаки-приманки.
Злоумышленник построил поддельную торговую среду с поддельными токенами-обёртками и поддельными пулами в стиле Uniswap V2, генерирующими реалистичные события Swap / Sync. В легитимном сценарии функция wrapTo() контракта-обёртки должна внутренне вызывать transferFrom() на базовом реальном токене, расходуя разрешение, ранее выданное ботом. Однако поддельный контракт токена-обёртки полностью пропускал этот шаг, при этом всё равно возвращая небольшую искусственно созданную злоумышленником прибыль через unwrap(). Поскольку бот не проверял, были ли разрешения фактически израсходованы, и не отзывал остаточные апрувы, неиспользованные разрешения накапливались и впоследствии были выведены через withdraw(). Один пострадавший кошелёк потерял около 1 474,58 WETH, 2 870 573 USDC и 2 035 760 USDT. JaredFromSubway впоследствии сообщил об общих потерях приблизительно в $15M по всем пострадавшим кошелькам.
Урок состоит в том, что MEV-боты должны относиться к неизвестному коду токенов и пулов как к враждебному — даже когда симуляции выглядят прибыльными. Автоматизированные стратегии требуют строгих белых списков разрешённых адресов, проверок хешей кода, верификации разрешений после сделки и очистки остаточных апрувов.
Инциденты с устаревшими роллапами Aztec: ~$4.35M
В июне 2026 года два отдельных устаревших развёртывания Aztec были взломаны, в совокупности понеся убытки приблизительно на $4.35M. Несмотря на различные первопричины, оба инцидента произошли на границе между корректностью доказательства и семантикой расчётов.
Первый инцидент затронул RollupProcessorV3 Aztec Connect 14 июня 2026 года, вызвав потери приблизительно на $2.15M. Злоумышленник установил numTxs в значение 1, при этом вставив реальный депозит в более поздний декодируемый слот, так что путь доказательства зачислял значение внутренне, тогда как логика расчётов L1 пропускала соответствующий вызов decreasePendingDepositBalance(). Затем злоумышленник вывел образовавшийся необеспеченный баланс через стандартные каналы.
Второй инцидент поразил отдельное устаревшее развёртывание PrivateRollupBridge / RollupProcessor 18 июня 2026 года, что привело к потерям около $2.2M. Это развёртывание всё ещё открывало путь escapeHatch(bytes,bytes,bytes), а его схема никогда не ограничивала корень членства приватного join-split на совпадение с публичным oldDataRoot, потребляемым L1. Это позволило злоумышленнику доказать владение высокоценными нотами в поддельном приватном дереве, публикуя при этом реальный L1 dataRoot в качестве публичного корня. Верификатор принял доказательство, и контракт L1 выполнил вывод средств.
Вместе эти инциденты показывают, что одной лишь верификации доказательств недостаточно. Каждое значение, управляющее границами расчётов, должно быть привязано к точным публичным входным данным, которые верифицирует доказательство, а каждый приватный свидетель должен быть явно ограничен для соответствия публичному состоянию, которое расчёты фактически потребляют.
SecondFi: ~$2.4M
23 июня 2026 года SecondFi (бывший Yoroi), расширение браузерного кошелька, разработанное EMURGO, раскрыло критическую уязвимость в своей реализации подписи Ed25519, затрагивающую версии с v10.0.3 по v10.0.6.
Уязвимый код получал одноразовый номер для подписи только из публичного сообщения транзакции, опуская обязательный секретный префикс nonce. Это превратило уравнение подписи в единственное неизвестное, позволяя любому напрямую восстановить приватный ключ кошелька из публичных данных в блокчейне. Два злоумышленника независимо друг от друга воспользовались уязвимостью, опустошив приблизительно $2.4M (16M ADA) из 374 кошельков, прежде чем EMURGO спасла ещё 129M ADA.
Урок состоит в том, что код подписи кошелька требует такого же тщательного изучения, как и криптография на уровне протокола. Опускание единственного секретного входного параметра — даже выглядящего незначительным — может полностью скомпрометировать приватные ключи, поэтому пользовательские реализации Ed25519 должны проходить независимый аудит, а не использоваться с доверием, как стандартная библиотека.
Почётное упоминание: ошибка корректности Zcash Orchard
Это не попало в топ-3 рейтинга, поскольку факт эксплуатации не подтверждён, однако ошибка корректности Zcash Orchard стала одним из наиболее значимых раскрытий июня. Публично раскрытая 4 июня 2026 года, ошибка представляла собой отсутствующее ограничение равенства в схеме экранированного пула Orchard, которое могло позволить одной и той же экранированной ноте производить разные нуллификаторы и расходоваться более одного раза. Уязвимость существовала с момента активации Orchard в мае 2022 года и была исправлена посредством аварийного обновления NU6.2.
Инцидент подтверждает более глубокий урок из дела Aztec. В ZK-системе безопасность зависит от того, что схема фактически ограничивает, — а не от того, что окружающий протокол предполагает, что она ограничивает.
Читать анализ ошибки Zcash Orchard
Приведённая выше информация основана на данных по состоянию на 00:00 UTC, 1 июля 2026 года.
На этом брифинг по инцидентам безопасности за февраль завершён.
Подробнее вы можете узнать в нашей Библиотеке инцидентов безопасности.
Оставайтесь в курсе и оставайтесь в безопасности!
