За два дня, 21–22 февраля 2026 года, мы увидели сразу несколько классов инцидентов, которые внешне выглядят «разными историями», но на практике собираются из одних и тех же компонентов: злоупотребление заранее полученными правами (permit/allowance), манипуляция неликвидной ценой и оракульным отражением, компрометация административного управления и логические ошибки в мостовой финализации.
Ниже — расследование по каждому кейсу: что именно сломалось, как атакующий прошёл через контрольные точки и куда ушли активы. Мы намеренно не «сжимаем» детали: в таких инцидентах важны адреса, маршруты, промежуточные стадии, сервисы вывода и повторяющиеся элементы инфраструктуры.
Кейс 1. Фишинговый Permit: кража ~$91.5K в XAUt
Сеть: Ethereum
Дата: 21 февраля 2026
Тип: фишинговый permit → мгновенный transferFrom
Что произошло
В рамках одной транзакции злоумышленник реализовал классический «permit-drainer» сценарий: сначала используется подпись жертвы (permit) для выдачи контракту неограниченного права списания токена XAUt, а затем — сразу же выполняется вывод активов через transferFrom().
Критическая деталь: permit убирает необходимость отдельной транзакции approve от имени владельца. В фишинговых схемах это делает атаку практически мгновенной — пользователь «подписывает разрешение», не видя привычного расхода газа на approve, а дренаж происходит сразу в той же транзакции.
Как именно была выполнена кража
После выдачи unlimited-разрешения контракт злоумышленника сделал два списания transferFrom с адреса жертвы и отправил XAUt на два адреса-получателя:
-
3.588307 XAUt (≈ $18,313.50) → 0xF06b3310486F872AB6808f6602aF65a0ef0F48f8
-
14.353231 XAUt (≈ $73,254.01) → 0xFD582d41fCC008FF5cbd2996043De3Ce25e7543e
Движение средств
Поток А (3.588307 XAUt):
После поступления на 0xF06b3310486F872AB6808f6602aF65a0ef0F48f8 произошёл немедленный обмен на ETH. Важно, что этот адрес уже встречался в расследованиях — на нём присутствуют иные похищенные активы. В таких случаях трассировка именно «этих» средств становится существенно менее определённой: поток растворяется в общем пуле, и дальнейшие перемещения уже отражают совокупную ликвидность адреса, а не конкретный инцидент.
Поток B (14.353231 XAUt):
После поступления на 0xFD582d41fCC008FF5cbd2996043De3Ce25e7543e
актив обменяли на USDC, затем провели консолидацию на адрес:
0x090424fb6665eD5B5bf93494aB30848C8B08c443.
На момент фиксации расследования средства находятся на этом адресе.
Permit-фишинг — это уже не «ошибка смарт-контракта». Это эксплуатация доверия к интерфейсу подписи и непонимания пользователем, что именно он разрешает. И именно поэтому такие кейсы повторяются: инфраструктура позволяет «разрешить списание» одним кликом, а атакующий строит вокруг этого убедительную обёртку.
Кейс 2. YieldBlox DAO Pool: манипуляция ценой USTRY на Stellar DEX
Тип: манипуляция неликвидным рынком + искажённая оценка залога
Сети: Stellar → Base/Ethereum
Дата: 21 февраля 2026
Что произошло
Злоумышленник реализовал одну из наиболее опасных атак на стыке рынка, ценовых оракулов и кредитных протоколов.
Суть схемы — искусственное завышение цены неликвидного актива с последующим использованием этой цены при оценке залога и получении необеспеченного займа.
Как развивались события:
Манипуляция была построена не на баге в смарт-контракте, а на искажении цены. Неликвидный токен USTRY искусственно разогнали на Stellar DEX, после чего этот рост без дополнительных проверок был принят системой оценки залога. В результате актив с завышенной «бумажной» ценой использовали как обеспечение для займа на более чем $10 млн.
Фактически протокол выдал необеспеченный кредит, потому что доверился ценовому сигналу без учёта реальной ликвидности и устойчивости рынка.
Движение средств
- Snapshot 1
- Snapshot 2
После получения средств на Stellar (адрес GBO7…WXC) маршрутизация пошла по нескольким веткам.
Ветка 1:
- 850,000 USDC отправлены через Allbridge в сеть Base на адрес:
0x2d1ce29b4af15fb6e76ba9995bbe1421e8546482
- далее на Base выполнен обмен на ETH, после чего ETH переброшены через Relay.link в Ethereum на тот же адрес 0x2d1c….
Ветка 2:
- остальные USDC на Stellar прошли по цепочке транзитных операций, после чего также были сконвертированы в ETH и выведены на адрес:
0x2d1ce29b4af15fb6e76ba9995bbe1421e8546482 в сети Ethereum.
Ветка 3:
- небольшая часть XLM была направлена на Binance, ChangeNOW и FixedFloat;
- выход в виде ETH зафиксирован на адресе:
0xe69f6d77db6ff493fdd15d8a0b390c36e18e5b21.
Из похищенного XLM большая часть была оперативно заморожена — около ~48 млн XLM..
Где остаются украденные активы
На момент фиксации расследования «не замороженная» часть активов наблюдается на следующих адресах:
- 0xe69f6d77db6ff493fdd15d8a0b390c36e18e5b21
- 0x89533c58a162fa01086d22ad43191bb5b5a672e3
- 0x2d1ce29b4af15fb6e76ba9995bbe1421e8546482
- 0x0b2b16e1a9e2e9b15027ae46fa5ec547f5ef3ec6
«Этот кейс наглядно показывает, что атака на DeFi-инфраструктуру может начинаться не с уязвимости в смарт-контракте, а с искажения рыночного сигнала.
Если неликвидный рынок позволяет искусственно разогнать цену актива, а кредитная система безоговорочно принимает этот показатель — без временных окон, sanity-проверок, лимитов и кросс-валидации источников, — экономическая манипуляция фактически превращается в прямой вывод ликвидности из протокола.
По сути, рынок становится точкой входа для атаки, а кредитный механизм — её усилителем.»
— Аналитик КоинКит
Кейс 3. ioTube Bridge (IoTeX): несанкционированный минт 410M CIOTX и вывод резервов TokenSafe (~$4.4M)
Тип: компрометация ключа / административный захват bridge-инфраструктуры через вредоносное обновление
Сети: Ethereum, IoTeX Chain, Base, Bitcoin
Дата: 21 февраля 2026
Что произошло
В этом случае проблема была не в самой сети IoTeX и не в её блокчейне. Уязвимой была вспомогательная часть — мост на стороне Ethereum, через который управлялись выпуск токенов и хранилище резервов.
Злоумышленник получил доступ администратора, обновил контракт на вредоносную версию и фактически взял управление системой в свои руки. После этого он смог одновременно выпустить огромное количество токенов CIOTX и вывести реальные активы из резервов. При этом сама сеть IoTeX продолжала работать нормально — атака затронула только инфраструктуру управления на стороне Ethereum.
Часть A — MintPool: 410M CIOTX
После того как злоумышленник получил контроль над системой, он выпустил около 410 млн токенов CIOTX. Однако далеко не все из них можно было реально использовать или продать.
Часть токенов оказалась «заперта» в сетях без нормальной ликвидности или рабочих маршрутов вывода. Другая часть была заморожена или возвращена благодаря действиям сетей и бирж. Лишь небольшое количество удалось обменять и вывести.
Иными словами, объём выпуска был огромным на бумаге, но реальную ценность имели только те токены, которые можно было быстро обменять или вывести там, где есть ликвидность и доступ к резервам.
Часть B — TokenSafe: вывод резервов (~$4.4M) и конвертация в BTC
Из хранилища TokenSafe злоумышленник вывел активы примерно на $4,4 млн. После этого они были обменяны на Ethereum и собраны в одном месте. Далее средства перевели через мост в сеть Bitcoin и распределили по четырём адресам. В сумме на них находится около 66 BTC. На момент фиксации расследования эти средства остаются на указанных адресах:
- 135oSa2fobTxtHtm5dwTREDyRY2o1DG1Aw
- 12V7jhcPnqnGbRFMasSW2CZVBd8qpvUgAK
- 16xusPKLMyqK68SkhfXDtic6AJPDi51tqh
- 1PN2BoHU4buDQWcrNHk9T9NBA2qX8oyYEc
Совокупный баланс составляет около ~66 BTC и остаётся на этих адресах.
Snapshoot:
Ethereum-часть
Bitcoin-часть
Кейс 4. TaraClient: два инцидента 22 февраля — ошибка порядка действий в финализации
Сеть: Ethereum
Дата: 22 февраля 2026
Тип: логическая уязвимость в finalizeBlocks() (проверка кворума после изменения весов валидаторов)
Почему это стало возможным
Ключевая проблема TaraClient описывается очень просто: контракт сначала применял изменения списка/весов валидаторов из входных данных, и только потом проверял, достигнут ли кворум подписей. То есть атакующий приносил «новые правила голосования», контракт их принимал, а затем по этим же новым правилам «доказывал», что кворум есть.
Фактически это ошибка порядка действий: сначала меняем модель доверия, потом проверяем доказательство — и это позволяет атакующему подогнать доказательство под изменённую модель.
Инцидент 1 — ~$13.5k
TX: 0xa1301596c77938cb31cbd282da79f6499f23cd8ffff5e609a77216ea1cf040a4
В одной транзакции атакующий добился того, что TaraClient ошибочно признал финализацию валидной, принял атакующий root, после чего был применён мостовой путь: выполнен минт TARA, часть активов обменяна на WETH/ETH, и ETH выведен на адрес атакующего.
Все украденные средства на момент фиксации находятся на адресе:
0x7bD736631Afbe1d3795a94F60574f7fA0aE89347
Инцидент 2 — ~$2.1k
TX: 0x2074d4f995bc4d009c25a40ea746be4e661d9a7a15fdfc9fdc9a419394986e60
Здесь сценарий повторяет тот же класс логики, но с другой цепочкой вывода:
- TaraClient принял финализацию (в логах присутствует событие BlockFinalized),
- далее по мостовому пути выполнен минт TARA на адрес DODO-пула,
- пул сразу обменял TARA на 1.141488345067626941 WETH,
- затем WETH выведен в ETH и ETH ушёл на адрес атакующего.
Прибыль попала на адрес:
0x9C8624440d1Ae80F173694E6a4f650E2418b8213,
после чего злоумышленник отправил около ~2.468 ETH в протокол приватности Railgun.
Кейс 5. PearlDex / PearlFi: кража ~$40.3k через переполнение в bonding-curve
Сеть: BNB Smart Chain (BSC)
Дата: 19 февраля 2026
Тип: переполнение при умножении в buy() (unchecked/assembly) → экономическая деформация цены
Что произошло
В механике покупки токенов была ошибка в расчётах. При больших объёмах система неверно считала цену и позволяла покупать токены значительно дешевле, чем они должны стоить. Ограничений на размер покупки при этом не было.
Этим воспользовался злоумышленник: он купил большое количество токенов за небольшую сумму, а затем продал их через торговые пулы, забрав из них реальные стейблкоины. В итоге прибыль составила около $40,3 тыс., которые были выведены на адрес атакующего.
Движение средств
После получения 40,341.541995 BSC-USD на адрес 0xDbCa…5aca произошёл обмен на 66 BNB, после чего все средства ушли в миксер Tornado Cash.
Итог
Если смотреть поверх «названий проектов», паттерны почти одинаковые:
- права списания (permit/approve) всё ещё остаются одним из самых дешёвых и надёжных векторов дренажа — кейс XAUt показывает это буквально в одной транзакции;
- манипуляция ценой на неликвидном рынке превращается в прямой вывод ликвидности, если оценка collateral не имеет защиты — кейс YieldBlox/Blend на Stellar;
- административный захват моста на Ethereum-стороне ведёт к максимальным последствиям, даже если L1 сети не тронут — ioTube/IoTeX;
- ошибка порядка действий в финализации (сначала «поверили», потом «проверили») ломает безопасность light-client — TaraClient;
- unchecked-математика в bonding curve без ограничителей даёт атакующему возможность «сломать экономику» и вынуть стейбл из ликвидности — PearlDex/PearlFi.
КоинКит фиксирует эти инциденты как один и тот же системный класс риска: рынок продолжает переоценивать «кодовую безопасность» и недооценивать управление правами, конфигурации, порядок проверок и инфраструктуру обновлений.
Заключение
События 21–22 февраля показывают, что сбой всё чаще возникает не в одном смарт-контракте, а на стыке нескольких элементов: прав списания и интерфейсов подписи, цены на неликвидном рынке и её отражения в системе, административного контроля и обновлений, логики финализации и порядка проверок.
Поэтому в таких инцидентах важен не только последующий анализ, но и быстрая практическая реакция: фиксация адресов, понимание маршрутов вывода и работа с мостами, сервисами и площадками. В ряде случаев возможность повлиять на ситуацию сохраняется, но это окно всегда очень короткое — и требует заранее выстроенных процессов.
