Еженедельный обзор инцидентов безопасности Web3 | 13–19 апреля 2026 г.

За прошедшую неделю (13.04.2026 – 19.04.2026) компания BlockSec обнаружила и проанализировала четыре инцидента, связанных с атаками, общие предполагаемые убытки от которых составили около $310 млн. В таблице ниже приведена сводка этих инцидентов, а подробный анализ каждого случая представлен в соответствующих подразделах.

Главное событие недели: KelpDAO

Подробный отчет, охватывающий каскадные последствия взлома, механизм восстановления Arbitrum в сети и более широкие последствия для управления, доступен по ссылке: Дилемма децентрализации: каскадные риски и чрезвычайные полномочия в кризисе KelpDAO

Этот инцидент выделяется своим инновационным вектором атаки на уровне инфраструктуры (отравление RPC против единственного DVN, а не эксплуатация смарт-контракта), каскадным воздействием на несколько сетей через DeFi-композабильность и вопросами управления, возникшими в связи с принудительным изменением состояния в Arbitrum для возврата украденных средств.

18 апреля 2026 года мост OFT (Omnichain Fungible Token) rsETH в KelpDAO на базе LayerZero подвергся атаке, в результате которой было украдено около $290 млн. Атака приписывается государственной структуре, предположительно группировке Lazarus из КНДР [1]. Первопричиной стала конфигурация KelpDAO DVN «1-из-1», которая свела проверку кроссчейн-сообщений к единой точке отказа. Злоумышленник отравил инфраструктуру RPC, которой доверяла DVN компании LayerZero Labs, вынудив её подтвердить сфабрикованное кроссчейн-сообщение. Это привело к выпуску 116 500 rsETH в сети Ethereum без соответствующего события в цепочке-источнике на Unichain.

Предыстория

LayerZero — это протокол кроссчейн-обмена сообщениями, построенный на модульной архитектуре безопасности. В его основе лежит целостность сообщений, обеспечиваемая децентрализованными сетями верификаторов (DVN) — внесетевыми сущностями, которые независимо подтверждают, что сообщение, отправленное в исходной цепочке, действительно имело место до его выполнения в целевой цепочке. Каждое приложение, развертываемое на LayerZero, настраивает свою собственную сеть DVN, включая выбор доверяемых узлов, необходимое количество и порог консенсуса. Эта модульность дает приложениям полный контроль над моделью безопасности, но налагает и полную ответственность: слабая конфигурация не может быть подстрахована самим протоколом.

Актив rsETH от KelpDAO развернут в виде OFT (Omnichain Fungible Token) на LayerZero с маршрутом моста между Unichain (источник) и основной сетью Ethereum (назначение). Стандарт OFT позволяет сжигать токены в цепочке-источнике и выпускать их из блокировки в целевой цепочке, причем кроссчейн-сообщение служит единственным разрешением на выпуск. Адаптер на стороне Ethereum (0x85d456...e98ef3) отвечает за перевод rsETH получателям после проверки и доставки корректного сообщения. Важно отметить, что KelpDAO настроил этот путь с конфигурацией DVN «1-из-1», назначив LayerZero Labs единственным верификатором. Это означало, что одного подтверждения от DVN было достаточно для авторизации любого выпуска токенов без необходимости второго мнения.

Для выполнения своих обязанностей по проверке DVN LayerZero Labs запрашивает несколько RPC-узлов, чтобы подтвердить, что событие отправки действительно произошло в исходной цепочке. Эти RPC-узлы включают как собственную инфраструктуру, так и внешних провайдеров; DVN полагается на их коллективные ответы перед подписанием подтверждения. Целостность этого процесса зависит от предположения, что большинство опрошенных узлов возвращают правдивые данные.

Анализ уязвимости

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

Во-первых, конфигурация DVN «1-из-1» в KelpDAO устранила любое резервирование на уровне проверки. Рекомендуемая модель безопасности LayerZero прямо требует использования нескольких DVN с независимыми верификаторами, чтобы ни одна DVN не могла единолично авторизовать сообщение. Полагаясь исключительно на DVN компании LayerZero Labs, KelpDAO гарантировал, что любой взлом этого единственного верификатора будет достаточен для авторизации произвольного выпуска токенов.

Во-вторых, механизм аварийного переключения (failover) DVN направляет запросы проверки на те RPC-узлы, которые остаются доступными. Этот дизайн предполагает, что недоступность узла случайна, а не преднамеренна. Однако это создаёт ситуацию, когда злоумышленнику не нужно компрометировать все источники данных: выведя здоровые узлы из строя с помощью DDoS и имея наготове отравленные узлы в качестве единственной доступной альтернативы, злоумышленник получает полный контроль над данными, получаемыми DVN.

В-третьих, замена исполняемого файла op-geth на RPC-узлах требовала доступа уровня ОС к базовым серверам. Точный вектор первоначального доступа не раскрыт, но компрометация двух независимых узлов в разных кластерах может указывать на общую слабость в том, как контролировался доступ к этим серверам.

Вместе эти три условия сформировали полную цепочку атаки: первое гарантировало отсутствие независимой DVN для кросс-проверки сообщения, второе дало возможность полностью контролировать данные, которые получала единственная DVN, а третье обеспечило плацдарм для манипуляции данными. Ни одно из этих условий по отдельности не было бы достаточным. Без конфигурации «1-из-1» вторая DVN, опрашивающая независимую инфраструктуру, отклонила бы поддельное сообщение. Без логики failover здоровые узлы перевесили бы отравленные. Без компрометации серверов у злоумышленника не было бы способа внедрить поддельные данные.

Анализ атаки

Приведённый ниже анализ основан на транзакции 0x1ae232...4222 и официальном заявлении LayerZero Labs.

• Шаг 1: Злоумышленник получил список конкретных RPC-узлов, которым доверяла DVN LayerZero Labs. Этот список был высокоценной целью, поскольку знание точных узлов позволило спланировать хирургическую операцию, а не широкомасштабную атаку на инфраструктуру.

• Шаг 2: Получив доступ к ОС на двух RPC-узлах, злоумышленник заменил исполняемые файлы op-geth на вредоносные версии. Эти узлы работали в независимых кластерах без прямого соединения между собой, что предполагает использование общей вышестоящей зависимости (например, скомпрометированные учетные данные развертывания, CI/CD конвейер или социальная инженерия). Точный метод первоначального доступа не был раскрыт.

• Шаг 3: Вредоносный исполняемый файл op-geth использовал целевую логику ответов: он возвращал поддельные данные транзакций исключительно на IP-адрес DVN, в то же время предоставляя правдивое состояние блокчейна всем остальным запрашивающим сторонам, включая системы мониторинга LayerZero, обозреватели блоков и сервисы сканирования. Эта выборочная «отравленность» сделала атаку невидимой для всех систем наблюдения.

• Шаг 4: Внутренний консенсус DVN требовал согласия как отраваленных, так и некомпрометированных узлов. Чтобы разрешить этот конфликт, злоумышленник подверг DDoS-атаке оставшиеся корректные узлы в окне атаки (с 10:20 до 11:40 по тихоокеанскому времени), что вызвало срабатывание логики failover и вынудило DVN полагаться исключительно на скомпрометированную инфраструктуру.

• Шаг 5: Поскольку DVN получала только контролируемые злоумышленником данные, сфабрикованное кроссчейн-сообщение LayerZero было подтверждено как валидное. DVN подтвердила нонс 308 в целевой конечной точке Ethereum, хотя в Unichain исходящего события с таким нонсом не существовало (максимальный исходный нонс оставался 307).

• Шаг 6: Адаптер rsETH на стороне Ethereum, получив валидно подтвержденное сообщение, выпустил 116 500 rsETH на адрес получателя в руках злоумышленника (0x8b1b6c...0d3b), профинансированный через Tornado Cash несколькими часами ранее. Украденные токены были немедленно распределены по семи кошелькам и ликвидированы через обеспечение на Aave, прямые обмены ETH и повторные мосты в Arbitrum. Итоговые средства сконцентрировались на 0x5d3919...7ccc в Ethereum и соответствующем сборщике в Arbitrum.

• Шаг 7: После завершения атаки вредоносный файл выполнил процедуру самоудаления вместе со всеми локальными журналами и конфигурационными файлами. Это существенно затруднило криминалистический анализ и демонстрирует высокий уровень операционной подготовки злоумышленника.

• Шаг 8: Последующая попытка злоумышленника использовать тот же путь для получения еще 40 000 rsETH (~$95 млн) была заблокирована после того, как KelpDAO обнаружил аномалию и приостановил работу всех соответствующих контрактов [2].

Более широкое влияние

Ущерб вышел далеко за пределы первоначального взлома моста в $290 млн. Злоумышленник внес около 89 567 rsETH (~$221 млн) в Aave на различных рынках, заняв WETH при коэффициенте LTV в 93% через E-Mode [4]. Поскольку Aave не могла отличить легитимно «перемощенный» rsETH от токенов, выпущенных по поддельному сообщению, «отравленное» обеспечение было принято как полностью валидное. Это привело к заморозке резервов WETH в сетях Ethereum, Arbitrum, Base, Mantle и Linea, затронув пользователей, которые вообще не имели отношения к rsETH. Это каскадное распространение воздействия от дефекта конфигурации одного моста до нарушения работы рынков кредитования нескольких сетей иллюстрирует, как DeFi-композабильность усиливает масштаб и стоимость единой точки отказа.

Последствия также подняли важные вопросы о практической реализации децентрализации. LayerZero Labs объявила, что их DVN больше не будут подписывать сообщения для приложений, использующих конфигурации «1-из-1» [1], подразумевая, что децентрализация на уровне протокола не может компенсировать слабости конфигурации на уровне приложения.

На уровне сети Совет безопасности Arbitrum предпринял экстренные меры, заморозив 30 766 ETH, удерживаемых злоумышленником в Arbitrum One. Как проанализировала компания BlockSec [5], это было достигнуто через принудительное изменение состояния на уровне сети: Совет безопасности временно обновил контракт входящих сообщений (inbox), внедрил неподписанное L1-to-L2 сообщение, имитирующее адрес злоумышленника, и восстановил исходную реализацию, причём всё это без необходимости подписи владельца адреса [3].

Это действие стало легитимным использованием чрезвычайных полномочий, определенных управлением, и было проведено прозрачно в координации с правоохранительными органами. Однако это также демонстрирует, что L2-сети по своей конструкции сохраняют возможности для централизованного вмешательства: любой актив в Arbitrum One в принципе может быть перемещен Советом безопасности по той же схеме. Разрыв между теоретической моделью доверия системы и её фактической границей доверия — это именно та область, где скрываются наиболее опасные риски.

Заключение

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

Три меры защиты могли бы предотвратить этот результат по отдельности:

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

• Анализ доступности при выборе RPC: Резкое падение количества доступных узлов во время активного окна проверки должно рассматриваться как потенциальный сигнал атаки, а не как штатная проблема доступности. Реализации DVN должны приостанавливать работу или выдавать предупреждения вместо продолжения с ограниченным набором узлов.

• Усиление инфраструктуры RPC: Возможность заменить исполняемый файл на работающем RPC-узле указывает на недостаточный контроль доступа к базовым серверам. Инфраструктура, на которую полагаются DVN, должна быть защищена так же строго, как и серверы, где хранятся ключи подписи DVN.

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

Ссылки

[1] LayerZero Labs, "KelpDAO Incident Statement," April 20, 2026. https://x.com/LayerZero_Core/status/2046081551574983137

[2] KelpDAO, "April 18 Incident: Additional Context," April 21, 2026. https://x.com/KelpDAO/status/2046332070277091807

[3] Arbitrum, "Security Council Emergency Action," April 21, 2026. https://x.com/arbitrum/status/2046435443680346189

[4] LlamaRisk, "rsETH Incident Report," April 20, 2026. https://governance.aave.com/t/rseth-incident-report-april-20-2026/24580

[5] BlockSec, "Arbitrum Security Council Freeze Mechanism Analysis," April 21, 2026. https://x.com/Phalcon_xyz/status/2046467830498173088

Другие инциденты этой недели

Rhea Finance

16 апреля 2026 года Burrowland, протокол кредитования и маржинальной торговли в сети NEAR под управлением Rhea Finance, подвергся взлому на сумму около $18,4 млн из-за логической ошибки в модуле маржинальной торговли. При открытии позиции с плечом протокол использует verify_token_out() для проверки ожидаемого результата обмена перед принятием позиции. Однако эта функция некорректно суммировала объёмы token_out с промежуточных этапов обмена, если токен совпадал с финальным, не учитывая, что эти промежуточные суммы впоследствии повторно использовались как token_in. Злоумышленник развернул фейковые токены и пулы, выстроил путь из циклических обменов, который завысил ожидаемый результат и прошёл проверки на платежеспособность, выведя из протокола около $18,4 млн.

Предыстория

Burrowland — это open-source протокол кредитования на NEAR. Помимо стандартного предоставления и получения займов, он поддерживает маржинальную торговлю, используя три переменные: token_c (обеспечение), token_d (долговой актив) и token_p (актив позиции).

Для длинной позиции пользователь вносит token_c и занимает token_d с выбранным плечом. Занятый актив меняется на DEX на token_p (актив, на движения которого ставит пользователь).

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

Позиция должна быть закрыта для фиксации прибыли или убытка, при этом token_p обменивается обратно в token_d для покрытия долга.

Открытие позиции обрабатывается функцией internal_margin_open_position().

Перед подтверждением позиция проходит четыре проверки: is_min_amount_out_reasonable() (сравнение заявленного минимума с оракулом Pyth), is_open_position_liquidatable() (проверка ликвидационного порога), is_open_position_forcecloseable() (состояние аккаунта) и get_open_position_lr() (максимальное допустимое плечо).

Правильность всех проверок зависит от того, что min_token_p_amount соответствует реальности. Именно за это должна отвечать функция verify_token_out(), реализованная через RefV1TokenReceiverMessage::get_token_out().

Анализ уязвимости

Ошибка заключается в verify_token_out(). Функция берёт token_out последнего шага как финальный и суммирует min_amount_out каждого шага, производящего такой же токен. Это верно для мульти-путевого обмена, но не учитывает шаги, где результат сразу тратится как token_in следующего шага. Циклический путь типа A->B->A->B заставляет каждый этап ->B засчитываться в сумму, хотя этот токен тратится в следующем шаге B->A и не достигает Burrowland. Заявленная сумма становится фиктивной.

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

Анализ атаки

Приведённый анализ основан на транзакции GcXEKm...fnFT.

Этап 1: Развертывание фейковых токенов и пулов

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

Этап 2: Открытие маржинальной позиции

• Шаг 1: Использование функции маржинальной торговли с циклическим маршрутом A->B->A->B через свои пулы.
• Шаг 2: Из-за суммирования в verify_token_out() злоумышленник завысил min_token_p_amount.
• Шаг 3: Заниженные проверки здоровья были обмануты.
• Шаг 4: Реально в протокол вернулись следовые количества токенов, но позиция была зафиксирована как здоровая.
• Шаг 5: Занятый актив token_d был выведен из пулов злоумышленника через remove_liquidity().
• Шаг 6: Повторение цикла до вывода $18,4 млн.

Заключение

Инцидент вызван ошибкой бизнес-логики. Протоколы маржинальной торговли должны воспринимать заявленные пользователем минимумы как ненадежный ввод, а не суммировать их без проверки на цикличность. Также следует ограничивать заявленное проскальзывание (slippage) значениями, основанными на оракулах, чтобы предотвратить искусственную накачку стоимости.

Hyperbridge

13 апреля 2026 года кроссчейн-мост Hyperbridge подвергся атаке на $242 тыс. из-за отсутствия проверки входных данных в логике доказательств MMR (Merkle Mountain Range). Функция MerkleMountainRange.VerifyProof() не проверяла, что leaf_index < leafCount, что позволило сфабриковать доказательство и совершить привилегированные действия, включая минт 1 000 000 000 DOT.

Предыстория

Hyperbridge использует модель верификатора на Ethereum. Контракт HandlerV1 проверяет доказательства против overlayRoot, если проверка успешна, сообщения идут в модули вроде TokenGateway. Этот модуль позволяет управлять активами, включая минт токенов при смене прав администратора через changeAdmin(). Безопасность всего моста зависела от корректности доказательств, проходящих через HandlerV1.

Анализ уязвимости

Ошибка в VerifyProof(). Она лишь проверяет, что root == CalculateRoot(...), но не проверяет границы leaf_index < leafCount. Установив leafCount = 1 и leaf_index = 1, злоумышленник заставлял CalculateRoot() пропускать включение поддельной транзакции в корень, делая корень «исторически верным» для любого содержимого.

Анализ атаки

Приведён на основе транзакции 0x240aeb...1109. Злоумышленник с помощью фейковых вызовов сменил администратора токена DOT на свой контракт и выпустил 1 млрд токенов, обналичив их на 108.2 ETH.

Заключение

Инъекция границ leaf_index < leafCount необходима для фиксации привязки сообщения к доказательству. Без этого исторический корень можно использовать для валидации любого Payload.

Ссылки

[1] BlockSec, "Hyperbridge Attack Analysis," April 13, 2026. https://x.com/Phalcon_xyz/status/2043601549893738970

Dango

13 апреля 2026 года децентрализованная биржа бессрочных фьючерсов Dango на Cosmos была взломана на $1,5 млн из-за отсутствия проверки знака числа. Функция replenish_insurance_fund() использовала is_non_zero() вместо is_positive(), позволяя внести отрицательный объём долларов, что перекачивало средства из страхового фонда на маржинальный аккаунт злоумышленника.

Предыстория

Страховой фонд нужен для покрытия убытков при ликвидациях. Любой пользователь может внести туда маржу.

Анализ уязвимости

В replenish_insurance_fund() отсутствовала защита от отрицательных сумм.

1. is_non_zero() лишь проверяет, что число не ноль.
2. user_state.margin >= amount (где -amount при положительной марже всегда проходят проверку). В итоге margin увеличивалась, а insurance_fund уменьшался.

Анализ атаки

Злоумышленник внес 1USDC в качестве обеспечения, вызвал функцию с отрицательным значением -1.5 млн, перекачал средства из фонда на свой маржинальный баланс и вывел их. Лимиты мостов позволили спасти часть средств, но $410 тыс. ушло в Ethereum.

Заключение

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

О компании BlockSec

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

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

• Официальный сайт: https://blocksec.com/
• Twitter: https://twitter.com/BlockSecTeam
• 🔗 Аудит безопасности BlockSec : Отправить запрос
• 🔗 Phalcon Security APP: Записаться на демо
• 🔗 Phalcon Compliance