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

За прошедшую неделю (со 2 по 8 февраля 2026 г.) компания BlockSec обнаружила и проанализировала шесть инцидентов со взломами, суммарный ущерб от которых оценивается примерно в $3,8 млн. В таблице ниже представлены краткие сведения об этих инцидентах, а подробный анализ каждого случая приведен в следующих подразделах.

1. Инцидент с CrossCurve

Краткое резюме

2 февраля 2026 года протокол CrossCurve подвергся взлому, в результате чего было потеряно около 2,8 млн долларов. Первопричиной стало то, что контракт ReceiverAxelar предоставлял доступ к функции expressExecute() без надлежащей проверки прав доступа, что позволяло обойти стандартный процесс валидации Axelar Gateway. Получатель проверял только адрес узла на основе данных, предоставленных извне. В итоге злоумышленник сформировал вредоносный кроссчейн-вызов для активации механизма сжигания и разблокировки, что привело к несанкционированному выпуску 999 787 453e18 токенов EYWA на адрес атакующего.

Предыстория

CrossCurve — это протокол кроссчейн-моста, разработанный Eywa.Fi и построенный на базе фреймворка для обмена сообщениями Axelar.

Согласно предполагаемой модели безопасности Axelar, кроссчейн-сообщения передаются через Axelar Gateway и должны проходить явную валидацию в целевой сети с помощью функции validateContractCall(). К исполнению допускаются только те сообщения, которые получили криптографическое подтверждение от шлюза.

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

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

Первопричиной стало то, что ReceiverAxelar открыл доступ к функции expressExecute() без проверки прав доступа, что позволяло напрямую получить доступ к привилегированному пути _execute() без авторизации Axelar Gateway.

В корректной модели безопасности Axelar кроссчейн-сообщения должны сначала одобряться шлюзом посредством выполнения с подтверждением, а затем валидироваться в целевой сети через validateContractCall(), которая привязывает (commandId, sourceChain, sourceAddress, contractAddress, payloadHash) к конкретному авторизованному исполнению.

Однако путь expressExecute() полностью обходил эту проверку. Он полагался только на проверку узла с использованием sourceChain и sourceAddress, оба из которых контролировались злоумышленником, и поэтому не обеспечивал реальной безопасности. Это позволило атакующему подделать сообщение, форсировать ветку receiveData и выполнить произвольную полезную нагрузку, которая в конечном итоге инициировала unlock() в Eywa CLP Portal, что привело к несанкционированному выводу кроссчейн-активов.

Анализ атаки

• Шаг 1: Атакующий напрямую вызвал expressExecute(), подделав sourceChain, sourceAddress и payload. Поскольку expressExecute() обходит проверку шлюза и переходит напрямую к _execute(), единственной оставшейся мерой безопасности была проверка белого списка адресов узлов: require(peers[sourceChain] == sourceAddress.toAddress()). Эта проверка была недостаточной, так как и sourceChain, и sourceAddress предоставлялись извне. Предоставив корректный адрес узла из белого списка, атакующий обошел её.

• Шаг 2: Сфальсифицированная полезная нагрузка (payload) была перенаправлена в ветку Receiver.receiveData(). Функция resume() выполнила кроссчейн-операцию PortalV2.unlock() на основе вредоносного payload, что привело к несанкционированной разблокировке средств для атакующего.

Заключение

Данный инцидент был фундаментально вызван недостаточным контролем доступа на ускоренном пути исполнения внутри контракта кроссчейн-получателя. Сделав expressExecute() общедоступной функцией и полагаясь исключительно на внешнюю информацию об узлах, CrossCurve фактически позволил злоумышленникам обойти гарантии безопасности Axelar Gateway и исполнить произвольные кроссчейн-команды.

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

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

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

• Рассматривать процесс экспресс-исполнения как привилегированную операцию и применять многоуровневые проверки, идентичные стандартным путям валидации.

Тщательное следование этим принципам критически важно при проектировании кроссчейн-систем, где один обход валидации может привести к системной потере активов в нескольких сетях одновременно.

2. Инцидент с GYD

Краткое резюме

3 февраля 2026 года протокол GYD подвергся взлому, в результате чего было потеряно около $700 тыс. Первопричиной стало то, что его CCIP-приемник доверял данным сообщения, контролируемым злоумышленником, как контексту выполнения. Взлом был инициирован CCIP-сообщением из Arbitrum, которое было корректно аутентифицировано на уровне передачи, но чья декодированная полезная нагрузка позже использовалась для выполнения произвольных внешних вызовов в _ccipReceive(). Установив декодированный адрес получателя на контракт токена GYD и передав данные вызова approve(attacker, type(uint256).max), эскроу непреднамеренно предоставил неограниченное разрешение на распоряжение своим балансом GYD. Впоследствии злоумышленник вывел средства через transferFrom().

Предыстория

Контракт GydL1CCipEscrow — это эскроу-контракт для кроссчейн-активов, построенный на стандарте Chainlink CCIP. Пользователи блокируют токены GYD в этом контракте в сети L1, после чего он отправляет кроссчейн-сообщение через CCIP в целевую сеть. И наоборот, когда кроссчейн-сообщение прибывает в эскроу, CCIP проверяет его подлинность и запускает _ccipReceive(). Эта функция анализирует входящие данные вызова для извлечения tx.recipient и data, выполняет логику перевода или разблокировки GYD на основе параметров (сумма и получатель), и, если data не пуста, выполняет произвольный внешний вызов через recipient.functionCall(data).

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

Основная уязвимость заключается в том, что GydL1CCipEscrow не валидирует адрес tx.recipient, декодированный из кроссчейн-сообщений. Злоумышленник может установить tx.recipient как адрес контракта токена GYD и сформировать data как approve(attacker, type(uint256).max). Поскольку эскроу-контракт содержит большое количество заблокированных токенов GYD, этот неограниченный внешний вызов заставляет эскроу дать злоумышленнику полное разрешение на использование токенов GYD, после чего тот может вывести все средства через transferFrom().

Анализ атаки

• Шаг 1: Злоумышленник инициировал вредоносное CCIP-сообщение в Arbitrum, указав tx.recipient как контракт токена GYD в Ethereum, а tx.data — как закодированный вызов approve(attacker, type(uint256).max).

• Шаг 2: При обработке сообщения в Ethereum функция _ccipReceive() контракта GydL1CCipEscrow выполнила одобрение на контракте токена GYD без проверки tx.recipient. Затем злоумышленник вызвал transferFrom() на токене GYD, чтобы вывести все депонированные средства.

Заключение

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

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

• Внедрить белый список целей исполнения: ограничить tx.recipient (или tx.target) четко определенным набором доверенных адресов.

3. Инцидент с токеном SOFI

Краткое резюме

5 февраля 2026 года токен SOFI в сети BNB Chain подвергся взлому, в результате чего было потеряно около $29,6 тыс.

Первопричиной стал механизм сжигания, реализованный внутри переопределенной функции _transfer(). Используя логику отложенного сжигания, которая удаляла токены непосредственно из пула ликвидности PancakeSwap и запускала последующий sync(), атакующий смог искусственно завысить цену SOFI. Путем повторяющихся переводов и обменов злоумышленник извлек избыточную ликвидность USDT из пула и вернул флэш-кредит с прибылью.

Предыстория

SOFI — это пользовательский токен стандарта ERC-20, развернутый в BNB Chain. В отличие от стандартной реализации ERC-20, токен SOFI переопределяет внутреннюю функцию _transfer(), чтобы включать дополнительную логику, связанную со сжиганием токенов во время операций продажи.

Токен торгуется в AMM-пуле с постоянным произведением в стиле PancakeSwap (SOFI–USDT). В таких пулах цена токена зависит от соотношения резервов. Любое неожиданное изменение балансов пула, особенно не вызванное обменами, может напрямую манипулировать ценой.

В этой архитектуре сам контракт токена взаимодействует с пулом ликвидности во время переводов, что делает учет резервов пула зависимым от логики стороны токена, а не чисто от механики AMM.

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

Уязвимость заключается в механизме сжигания SOFI в сочетании с взаимодействием с пулом внутри _transfer().

Когда токены SOFI переводятся на адрес пула ликвидности, контракт интерпретирует перевод как продажу и увеличивает внутреннюю переменную-аккумулятор waitBurnTokenAmount. Однако накопленное количество сжигается не сразу. Вместо этого оно сжигается из баланса пула при последующем переводе в пул, после чего вызывается функция пула sync().

Эта архитектура создает две критические проблемы:

1. Прямая манипуляция балансом пула Сжигание токенов непосредственно из пула уменьшает резерв SOFI без соответствующего оттока USDT, что нарушает инвариант AMM и искусственно увеличивает цену SOFI.

2. Отложенное и контролируемое атакующим исполнение Поскольку сжигание происходит только при будущем переводе, атакующий может точно контролировать, когда произойдут сжигание и sync(), что позволяет им извлечь выгоду из искажения цены.

В результате цена в пуле перестает отражать реальную динамику спроса и предложения, что делает возможным извлечение прибыли через арбитраж.

Анализ атаки

• Шаг 1: Взять флэш-кредит в USDT.

• Шаг 2: Обменять USDT на SOFI в пуле SOFI–USDT.

• Шаг 3: Перевести SOFI в пул и вызвать skim(), чтобы увеличить waitBurnTokenAmount с минимальными потерями.

• Шаг 4: Снова перевести SOFI в пул, чтобы запустить сжигание + sync(), подталкивая цену SOFI вверх, а затем обменять SOFI на USDT.

• Шаг 5: Повторить шаг 4. Вновь накопленный waitBurnTokenAmount сжигается только на следующем переводе, поэтому требуется несколько итераций.

• Шаг 6: Вывести USDT из пула, затем вернуть флэш-кредит.

Заключение

Этот инцидент был в конечном итоге вызван небезопасным механизмом сжигания на стороне токена, который напрямую манипулировал балансами AMM-пула. Внедряя логику отложенного сжигания внутри _transfer() и выполняя сжигание из самой ликвидности пула, токен SOFI нарушил фундаментальные предположения AMM с постоянным произведением и допустил детерминированные манипуляции ценой.

Для токенов ERC-20, которые переопределяют _transfer(), разработчикам следует проявлять особую осторожность, чтобы избежать:

• Сжигания токенов непосредственно из пулов ликвидности.

• Внедрения отложенных или зависимых от состояния механизмов, влияющих на резервы пула.

• Слишком тесной связи логики токена с внутренними механизмами AMM.

В целом, логика токеномики никогда не должна позволять произвольно изменять балансы пулов, поскольку даже небольшие отклонения могут быть многократно использованы для вывода ликвидности.

4. Инцидент с неизвестным протоколом стейкинга (5 февраля 2026 г.)

Краткое резюме

5 февраля 2026 года неизвестный протокол стейкинга в Ethereum подвергся взлому, в результате чего было потеряно около $71,6 тыс.

Первопричиной стала зависимость протокола от невалидированных пользовательских входных данных во время вывода средств. Протокол пересылал контролируемые злоумышленником данные routerCalldata и объемы LP в роутер Pendle без проверки. Сформировав данные вызова, которые удаляли всю позицию LP протокола и устанавливали атакующего в качестве получателя, тот смог вывести все активы, хранящиеся в хранилище.

Предыстория

Протокол стейкинга — это простое хранилище доходности (yield vault), построенное на базе Pendle Finance. Пользователи вносят активы в хранилище, которое затем направляет их через роутер Pendle для минтинга доходных позиций. Внутри хранилища депозиты конвертируются в SY, разделяются на PT и YT и объединяются для формирования токенов LP протокола Pendle.

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

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

Первопричина — невалидированные входные данные. Функция withdrawWithCalldataMultiToken() принимает четыре параметра: базовый токен, объем базового актива, объем LP и routerCalldata. Она проверяет только достаточность баланса пользователя, но не валидирует объем LP или содержимое routerCalldata. При удалении ликвидности через роутер Pendle контракт полностью полагается на параметры, встроенные в routerCalldata. В результате злоумышленник мог передать полный баланс LP протокола и назначить себя получателем, выведя все активы хранилища.

Анализ атаки

• Шаг 1: Взять флэш-кредит в USDC.

• Шаг 2: Внести небольшую сумму USDC в протокол, который направит средства через Pendle Router для добавления ликвидности и минтинга LP.

• Шаг 3: Вызвать withdrawWithCalldataMultiToken() со специально сформированными routerCalldata, которые устанавливают receiver на атакующего, а lpAmount — на весь баланс LP протокола.

• Шаг 4: Протокол удаляет ликвидность через Pendle Router, используя контролируемые параметры, и отправляет все активы атакующему.

• Шаг 5: Обменять полученные активы обратно на USDC, вернуть флэш-кредит, а остаток оставить себе в качестве прибыли.

Заключение

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

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

• Относиться ко всем входным данным пользователя, включая calldata, как к ненадежным и строго их валидировать.

• Вычислять чувствительные параметры (такие как объемы LP и получатели) внутри системы, а не принимать их от пользователей.

• Применять многоуровневую защиту, обеспечивая согласованность между внутренним учетом и результатами внешнего исполнения.

Невыполнение этих требований может привести к тому, что даже один вызов на вывод средств скомпрометирует все активы протокола.

5. Инцидент с протоколом LZMultiCall

Краткое резюме

7 февраля 2026 года инцидент с LZMultiCall привел к потере примерно $142 тыс. в сети Ethereum.

Инцидент был вызван не уязвимостью самого контракта LZMultiCall, а неправильным использованием пользователями. LZMultiCall — это контракт без состояния (stateless) для пакетного исполнения, не предназначенный для хранения активов или ERC-20 разрешений (allowances). Однако некоторые пользователи по ошибке предоставили токенам разрешения для этого контракта. Злоумышленник воспользовался этими «висячими» разрешениями, вызвав execute() со специально сформированными данными вызова для функции transferFrom(), выведя токены пострадавших пользователей.

Предыстория

LZMultiCall — это служебный контракт для пакетного исполнения общего назначения. Его цель — позволить пользователям объединять несколько вызовов в одну транзакцию, пересылая полученные от пользователя calldata целевым контрактам.

Важно, что LZMultiCall спроектирован как контракт без хранения состояния и активов. Он не предназначен для удержания активов, и пользователи никогда не должны предоставлять ему разрешения ERC-20. Любые разрешения токенов, предоставленные LZMultiCall, нарушают его явные предположения об использовании и подвергают пользователей риску, поскольку контракт может пересылать произвольные вызовы от имени вызывающего.

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

Хотя LZMultiCall функционировал согласно спецификации, его общедоступная функция execute() стала инструментом для взлома, как только пользователи ошибочно предоставили ему разрешения ERC-20. Поскольку контракт пересылает произвольные calldata любой цели, атакующий мог вызвать execute() с данными, кодирующими transferFrom(victim, attacker, amount) на контрактах токенов, эффективно выводя любые доступные разрешения.

Анализ атаки

• Злоумышленник вызвал execute() со специально сформированными calldata, нацеленными на контракт токена, используя transferFrom(), чтобы перевести токены от имени пользователей, которые ошибочно предоставили разрешения для LZMultiCall.

Заключение

Этот инцидент был вызван нарушением явных правил использования контракта для пакетного исполнения. LZMultiCall никогда не предназначался для хранения средств или разрешений ERC-20. Как только пользователи ошибочно предоставили разрешения, модель общедоступного исполнения контракта позволила любому пользователю вывести эти средства через произвольные пересылаемые вызовы.

Для пользователей и разработчиков, взаимодействующих с контрактами типа «multicall» или пакетного исполнения:

• Никогда не предоставляйте разрешения ERC-20 контрактам, которые не предназначены для хранения активов.

• Относитесь к контрактам общего назначения для пересылки вызовов как к небезопасным поверхностям исполнения.

• По возможности отдавайте предпочтение разрешениям на одну транзакцию или архитектурам без разрешений (например, permit).

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

6. Инцидент с неизвестным протоколом (8 февраля 2026 г.)

Краткое резюме

8 февраля 2026 года неизвестный протокол в сети Ethereum подвергся взлому, что привело к убыткам около $63 тыс.

Первопричиной стали невалидированные входные данные в пути исполнения модуля Gnosis Safe. Служебный контракт (0xF5E4), зарегистрированный как SafeModule, предоставлял колбэк для флэш-кредитов, который декодировал произвольные пользовательские данные и напрямую вызывал GnosisSafe.execTransactionFromModule(). Поскольку вызовы, инициированные модулем, по дизайну обходят проверку подписи, атакующий смог исполнить произвольные транзакции, авторизованные владельцем Safe, вернуть долг Safe в протоколе Aave V3 и вывести весь залог на адреса, контролируемые злоумышленником.

Предыстория

Архитектура протокола строится вокруг кошелька Gnosis Safe, который управляет позицией с кредитным плечом в Aave V3. Gnosis Safe поддерживает модульную модель исполнения, где назначенные SafeModules могут исполнять транзакции от имени Safe без необходимости подписи владельцев. Эта архитектура предназначена для автоматизации, интеграций и сложных стратегий.

В данной настройке контракт 0xF5E4 был сконфигурирован как SafeModule для этого кошелька. Контракт представляет собой вспомогательную утилиту для управления позициями на основе флэш-кредитов. Он реализует колбэк receiveFlashLoan(), который вызывается внешними поставщиками ликвидности во время исполнения флэш-кредита.

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

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

SafeModule 0xF5E4 открывает колбэк флэш-кредита receiveFlashLoan(), который декодирует внешние userData и напрямую использует их для вызова GnosisSafe.execTransactionFromModule(). Так как 0xF5E4 зарегистрирован как SafeModule, вызовы от него не требуют проверки подписи. Однако receiveFlashLoan() не аутентифицирует вызывающего и не проверяет декодированные параметры (такие как адрес цели, сумма, calldata или тип операции). В результате атакующий может передать сформированные userData, чтобы заставить модуль исполнять произвольные транзакции через Safe, вернуть долг Safe в Aave V3, вывести весь залог и присвоить позицию.

Анализ атаки

• Шаг 1: Злоумышленник взял флэш-кредит в Uniswap V4 и перевел средства в GnosisSafe.

• Шаг 2: Злоумышленник вызвал flashLoan() в Balancer со сформированными userData, не заимствуя активы фактически, и установил recipient на 0xF5E4.

• Шаг 3: Внутри 0xF5E4.receiveFlashLoan() контракт декодировал предоставленные атакующим userData. Поскольку 0xF5E4 зарегистрирован как модуль Safe, он обошел проверку подписи и вызвал execTransactionFromModule(), исполняя произвольные вызовы согласно параметрам в userData.

• Шаг 4: Используя эту возможность, атакующий вернул долг GnosisSafe в Aave V3 и вывел весь залог, получив прибыль.

Заключение

Этот инцидент был в конечном итоге вызван небезопасным использованием модульного исполнения в сочетании с невалидированными внешними данными. Пересылая произвольные userData в execTransactionFromModule(), модуль SafeModule 0xF5E4 фактически открыл неограниченный контроль над Gnosis Safe. Поскольку модули Safe по дизайну обходят проверку подписи, эта ошибка привела к полному захвату позиции Safe в Aave V3.

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

• Относиться ко всем внешним входным данным, включая userData флэш-кредитов, как к ненадежным и строго их валидировать.

• Ограничить исполнение модуля четко определенным набором действий, целей и селекторов.

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

Невыполнение этих мер защиты может превратить обычный вспомогательный контракт в полноценный административный бэкдор.

О компании BlockSec

BlockSec — это полноценный провайдер услуг в области безопасности блокчейна и соблюдения крипто-комплаенса. Мы создаем продукты и предоставляем услуги, которые помогают нашим клиентам проводить аудит кода (включая смарт-контракты, блокчейны и кошельки), перехватывать атаки в реальном времени, анализировать инциденты, отслеживать незаконные средства и соблюдать обязательства AML/CFT на протяжении всего жизненного цикла протоколов и платформ.

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

• Официальный сайт: https://blocksec.com/

• Официальный Twitter-аккаунт: https://twitter.com/BlockSecTeam

• 🔗 Аудиторские услуги BlockSec : Отправить запрос

• 🔗 Приложение Phalcon Security: Записаться на демо

• 🔗 Phalcon Compliance