Три инцидента начала февраля: reentrancy, Safe-модули и опасные allowances
11.02.2026 | CoinKyt Company

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

В отличие от «классических» взломов, во всех трёх кейсах злоумышленник действовал в рамках разрешённой логики контрактов. Ниже — подробный разбор каждого инцидента и движение средств после атак.

 

О проведении крипторасследования


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

 


Начать крипторасследование совместно с КоинКит

 

 

Кейс 1. Reentrancy в ERC-1155 bonding-curve контрактах


Потери:
~6.7 ETH (≈ $14k)

Дата: 8 февраля 2026

Сеть:
Ethereum


Тип:
reentrancy из-за внешнего вызова до обновления состояния



Что произошло


В одной транзакции атакующий контракт последовательно взаимодействовал сразу с четырьмя ERC-1155 контрактами с bonding-curve-механикой:


- RIGHT


- F1


- JNGL


- THRY


Анализ внутренних вызовов показывает, что выплаты и возвраты ETH происходили до обновления внутреннего состояния контрактов — цен, балансов и параметров кривой. Это создало окно для повторного входа в buy() / sell() по устаревшей цене.

Фактически атакующий многократно извлекал ETH, пока контракт считал, что его состояние ещё не изменилось.



Техническая механика


Паттерн атаки соответствует классическому reentrancy-сценарию:


1. вызов функции покупки/продажи;


2. получение ETH через внешний вызов;


3. повторный вход в функцию до фиксации нового состояния;


4. извлечение value по старым параметрам.


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



Куда ушли средства


Полученные 6.7021 ETH были выведены с контракта атакующего
0x0a28036a285d309f3b5345a5703fd357dadd15fb
на EOA-адрес злоумышленника
0x66D3832bd138b94b7329c0c2806145ab665ed717.


Далее средства были заведены в протокол приватности Railgun через контракт Railgun: WETH Helper. Вход в Railgun осуществлялся несколькими операциями, включая транзакции на 0.1 ETH и 6.8449899 ETH.


После депозита в Railgun дальнейшая трассировка движения средств становится существенно ограниченной.

 

 

Кейс 2. Safe-модуль как вектор атаки — кража ~$63.9k USDe



Дата:
7 февраля 2026

Сеть: Ethereum

Тип: злоупотребление включённым Safe-модулем (execTransactionFromModule)



Что произошло


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

Атака была реализована через собственный контракт злоумышленника
0x40D24cc6D173e9d2433446F4838BEe76D592A55d
с использованием flash-ликвидности.



Ход атаки

Злоумышленник инициировал атаку, взяв flash-займ в размере 1,000,000 USDe в Uniswap. Далее, используя включённый модуль Safe и вызов execTransactionFromModule, он заставил Safe-аккаунт погасить долг в Aave и вывести залог в виде sUSDe на контролируемый контракт.

Полученный sUSDe был обменян через Curve Finance и связанные маршрутизаторы обратно в USDe. После этого flash-займ был полностью возвращён, а разница в размере 63,967.4744 USDe зафиксирована как чистая прибыль злоумышленника.



Движение средств после атаки

После поступления 63,967.4744 USDe на адрес
0x8F9c041dff53AA584be5057F2acAf27EB01d33Cc,
средства были разделены на две части.

30,000 USDe были обменяны на DAI и отправлены в протокол приватности Railgun. Оставшиеся 33,967 USDe были обменяны на ETH и также направлены в Railgun, что существенно ограничило дальнейшую трассировку средств.

 


Кейс 3. LZMultiCall и опасные allowances — кража 2 WBTC

Потери: 2 WBTC (≈ $130k)

Дата: 6 февраля 2026

Сеть:
Ethereum


Тип:
злоупотребление allowance в LZMultiCall



Что произошло


Адрес жертвы
0xE2E1808Ed4cC4A6f701696086838F511Ee187d57
выдал разрешение (approve) на 2 WBTC контракту LZMultiCall
(spender = 0xAcdDAC6C77318B615f7F6fB9bb67c6833e9c05f1).


Следующей транзакцией злоумышленник воспользовался этим разрешением и заставил контракт LZMultiCall списать токены:


2 WBTC ушли с адреса жертвы на адрес атакующего

0x129B5Ea8f9822AA2b2AcB19C857A31530AB152b0



Почему это сработало


Контракт LZMultiCall — это универсальный инструмент для выполнения внешних вызовов. Любой пользователь может вызвать execute(), передав в него набор операций.

Контракт исполняет эти вызовы от имени msg.sender. Если пользователь заранее выдал ему allowance, любой другой участник может воспользоваться этим разрешением и списать токены через transferFrom().

Важно, что риск прямо указан в коде контракта: LZMultiCall не предназначен для хранения разрешений на токены.

Таким образом, уязвимость была не в коде LZMultiCall как таковом, а в небезопасно выданном разрешении — со стороны пользователя или интерфейса, который он использовал.



Куда ушли средства


2 WBTC были обменяны на ~65.95 ETH. Далее полученный ETH был отправлен тремя транзакциями на адрес
0x73ee51c85d272ddd25399d75c1039a704646d3ad.

После консолидации средств на этом адресе произошёл обмен ETH на 129,847 USDC, а затем — своп в 129,847 aEthUSDC. На момент подготовки материала активы остаются на балансе и не были выведены дальше.

С полной визуализацией движения средств можно ознакомиться здесь.

 

 

Итог



Все три кейса демонстрируют один и тот же системный класс рисков:


- reentrancy всё ещё возможен при ошибочном порядке обновления состояния;

 

- Safe-модули без строгого контроля превращаются в прямой вектор атаки;

 


- allowance-модель остаётся критически опасной при взаимодействии с универсальными контрактами;

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

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