Еженедельный обзор инцидентов безопасности Web3

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

Дата	Инцидент	Тип	Оценочный ущерб
10.02.2026	Неизвестный инцидент	Ошибка бизнес-логики	~$10 тыс.
14.02.2026	Инцидент с `OCA`	Ошибка бизнес-логики	~$422 тыс.
14.02.2026	Инцидент с `SOF`	Ошибка бизнес-логики	~$225 тыс.

1. Неизвестный инцидент

Краткая сводка

10 февраля 2026 года был атакован контракт 0x560d39 в сети BNB Smart Chain, что привело к убыткам на сумму около $10 тыс. Первопричиной стала ошибка в бизнес-логике функции 0xb1a87f2c(), из-за которой процесс добавления ликвидности стал уязвим для сэндвич-атаки.

Предыстория

В контракте 0x560d39 функция 0xb1a87f2c() переводит от пользователя соответствующее количество USDT на основе входного параметра. Полученный USDT обрабатывается, и 85% от общей суммы выделяется для последующих операций с ликвидностью.

Из этой 85-процентной доли половина обменивается на AFX через пул PancakeSwap, а полученные AFX переводятся на контракт 0x671ce4. Затем функция выводит AFX из 0x671ce4.

Далее, через роутер PancakeSwap V2, оставшаяся половина 85% доли USDT и AFX, выведенные из 0x671ce4, используются для добавления ликвидности в торговую пару USDT-AFX. Любой остаток USDT или AFX возвращается пользователю.

После завершения добавления ликвидности USDT–AFX функция получает дополнительные токены AFX с адреса 0x146933. Количество AFX, изъятое из 0x146933, устанавливается равным количеству, предварительно выведенному из 0x671ce4. Затем функция рассчитывает необходимое количество AHT на основе текущего соотношения цен в пуле ликвидности PancakeSwap V2 AFX–AHT. Затем она предоставляет AFX, полученные из 0x146933, вместе с соответствующим количеством AHT (также полученных из 0x146933), для добавления ликвидности в торговую пару AFX–AHT.

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

Уязвимым является контракт 0x560d39. Контракт 0x146933 служит источником финансирования AFX, используемого для добавления ликвидности AFX-AHT, и в конечном итоге несет убытки.

Первопричина кроется в ошибке бизнес-логики функции 0xb1a87f2c() в контракте 0x560d39. При получении AFX, приобретенных в результате обмена USDT через контракт 0x671ce4, функция не проверяет изменение баланса AFX в 0x671ce4 до и после обмена. Вместо этого она просто выводит все токены AFX, хранящиеся в 0x671ce4.

Это позволяет злоумышленнику заранее пожертвовать большое количество AFX контракту 0x671ce4, а затем вызвать 0xb1a87f2c() с небольшим количеством USDT. Поскольку количество AFX, забираемых из 0x146933, привязано к количеству AFX, выведенному из 0x671ce4, искусственное завышение вывода из 0x671ce4 вынуждает 0x146933 внести непропорционально большое количество AFX для добавления ликвидности AFX-AHT.

Злоумышленник может вернуть свое «пожертвование» через возврат оставшихся USDT и AFX из 0x560d39, в то время как 0x146933 берет на себя расходы по избыточному предоставлению ликвидности.

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

Анализ атаки

Основные этапы транзакции атаки сведены к следующему:

Этап 1: Злоумышленник взял флэш-кредит на 1 130 500e18 токенов AFX на PancakeSwap V2.
Этап 2: Злоумышленник перевел 511 965e18 AFX на контракт 0x671ce4.
Этап 3: Злоумышленник использовал оставшиеся AFX для обмена на 52 316e18 AHT в пуле AFX-AHT на PancakeSwap V2. Поскольку AHT — это токен с комиссией при переводе, злоумышленник получил только 26 158e18 AHT.
Этап 4: Злоумышленник вызвал контракт 0x560d39 и функцию 0xb1a87f2c() с параметром, установленным на 100. Поскольку функция вывела все AFX из 0x671ce4 (включая пожертвованные злоумышленником токены), она попыталась добавить непропорционально большую ликвидность в пары USDT-AFX и AFX-AHT. Любые оставшиеся USDT и AFX, которые не удалось соединить в пару, были возвращены злоумышленнику, что позволило ему компенсировать большую часть затрат.
Этап 5: Злоумышленник обменял 26 158e18 AHT на 1 129 417e18 AFX.
Этап 6: Злоумышленник погасил флэш-кредит и обменял оставшиеся AFX на USDT, получив около $10 тыс. прибыли.

Заключение

Этот инцидент был вызван тем, что контракт 0x560d39 при получении AFX напрямую выводил все токены с контракта 0x671ce4 без проверки изменения баланса последнего до и после обмена.

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

Краткая сводка

14 февраля 2026 года неизвестный протокол в сети BNB Smart Chain подвергся эксплойту, что привело к убыткам на сумму около $422 тыс. Первопричиной стала логическая ошибка: после завершения обмена протокол вызывал функцию переработки (recycle) в контракте токена OCA, чтобы извлечь токены с DEX и вернуть их вызывающему абоненту и другим адресам. Такой односторонний вывод токенов OCA искусственно сокращал резервы пула, завышая рыночную цену и позволяя злоумышленнику многократно выводить USDC из пула.

Предыстория

Контракт протокола (0xe0d5ec) содержал функцию sellOCA() (селектор 0x9c1dad28), которая обменивала указанное пользователем количество OCA на USDC через DEX. Токен OCA включает дефляционный механизм переработки: после обмена контракт забирает обратно такое же количество OCA, которое только что было продано, и перераспределяет их между вызывающим лицом и другими адресами. Поскольку OCA изымается из пула уже после того, как USDC были выплачены, резервы OCA в пуле снижаются при сохранении низких резервов USDC, что искусственно завышает цену OCA.

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

Суть уязвимости заключается в том, что механизм обратного получения токенов в sellOCA() создает примитив для манипуляции ценой. Каждый вызов имеет следующий эффект для пула DEX: пул теряет USDC во время обмена и также теряет OCA из-за дефляционного механизма, в то время как пользователь получает USDC и возвращает свои OCA. Поскольку резервы OCA уменьшаются без соответствующего притока USDC для уравновешивания сделки, каждый такой цикл искусственно завышает курс OCA/USDC. Злоумышленник может повторять это: покупая OCA, вызывая sellOCA(), чтобы спровоцировать механизм возврата, а затем продавая полученные OCA по завышенной цене, постепенно выкачивая ликвидность USDC из пула.

Анализ атаки

Основные этапы транзакции атаки сводятся к следующему:

Этап 1: Взят флэш-кредит на 8 704 860e18 USDC.
Этап 2: Обменено 8 704 860e18 USDC на 940 991e18 OCA на PancakeSwap.
Этап 3: Вызвана функция sellOCA() со всеми 940 991e18 OCA. Функция обменяла OCA на USDC на DEX, затем механизм переработки изъял проданные токены OCA из пула и перераспределил их, вернув злоумышленнику. В итоге злоумышленник получил USDC от обмена и сохранил свои OCA. Резервы OCA в пуле резко упали, взвинтив цену.
Этап 4: Полученные 940 991e18 OCA были проданы обратно за USDC на PancakeSwap по уже завышенной цене. Этапы 2–4 были повторены для постепенного опустошения пула.
Этап 5: На последней итерации злоумышленник обменял всего 9 999e18 OCA на 433 238e18 USDC (из-за крайне высокой цены OCA), а затем погасил флэш-кредит, завершив атаку.

Заключение

Основная причина эксплойта — логическая ошибка в потоке sellOCA: после обмена OCA на USDC контракт изымал почти все токены OCA из пула через механизм «переработки» и возвращал их пользователю. Этот процесс искусственно снижал баланс OCA в пуле, вызывая скачок цены. Повторяя цикл «купил OCA -> вызвал sellOCA -> продал OCA по завышенной цене», злоумышленник вывел почти всю ликвидность USDC.

3. Инцидент с SOF

Краткая сводка

14 февраля 2026 года токен SOF в сети BNB Smart Chain был атакован (убыток ~$225 тыс.) из-за некорректного механизма белого списка в логике _update() и системе освобождения от комиссий. Уязвимость позволила злоумышленнику обойти ограничения на покупку с помощью адреса, освобожденного от комиссий, а затем запустить механизм burn-on-sell (сжигание при продаже), который манипулировал резервами пула Uniswap V2 (PancakeSwap). Вынудив пул передать собственные токены на адрес сжигания и немедленно вызвав sync(), злоумышленник искусственно завысил цену токена. Это позволило вывести USDT из пула путем обмена небольшого количества SOF по манипулированному курсу. Эксплойту способствовала неадекватная защита от флэш-кредитов, которая не отслеживала tx.origin, что позволило совершить фазы покупки и продажи в рамках одной транзакции с разных адресов.

Предыстория

SOF — это токен стандарта BEP-20 в сети BNB Smart Chain с кастомными дефляционными механиками и автоматизированным управлением комиссиями. Токен взаимодействует с пулом ликвидности, совместимым с Uniswap V2 (PancakeSwap), для обеспечения торговли парами с USDT.

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

Во время операций продажи контракт переводит 90% от суммы продажи из пула на адрес _destroyAddress и вызывает sync(), чтобы немедленно обновить резервы с учетом уменьшившегося баланса.

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

Первопричина кроется в ошибке механизма белого списка в функции _update() смарт-контракта 0x1f3863 (строка 438). Если адрес to находится в белом списке, любой from может выполнить покупку.

 /// SOF.sol:433-480
433|      function _update(
434|          address from,
435|          address to,
436|          uint256 amount
437|      ) internal override {
438|          if (isExcludedFromFees[to] || isExcludedFromFees[from]) {
439|              super._update(from, to, amount);
440|              return;
441|          }
442|  
443|          require(!_blackList[from] && !_blackList[to], "refuse address");
...

Анализ атаки

Основные этапы транзакции атаки сведены к следующему:

Этап 1: Злоумышленник взял флэш-кредит на 315 520 309e18 USDT для этапа 2 и перевел 875e18 SOF на адрес 0xc4DB5B для этапа 3.
Этап 2: Обменял 313 567 718e18 USDT на 991 223e18 SOF через swapTokensForExactTokens(). Адрес to был адресом, освобожденным от комиссий, что удовлетворило проверку isExcludedFromFees[to], позволив пропустить проверку _isPairs[from] (в противном случае покупка была бы отклонена). Это позволило злоумышленнику сжечь почти все SOF в пуле на этапе 3. Данное действие также обошло _antiFlashloanGuard() — контракт не зафиксировал эту покупку, что позволило этапу 3 пройти без блокировки. Важно, что эта масштабная покупка была рассчитана так, чтобы оставить в паре лишь 787e18 SOF (вместе с 313 816 344e18 USDT).
Этап 3: С адреса 0xc4DB5B обменял 875e18 SOF на USDT. Роутер PancakeSwap V2 сначала выполняет SOF.transferFrom(), а затем обрабатывает обмен. Во время transferFrom() логика продажи в _update() переводит 90% от 875e18 (т.е. 787e18) из пула на _destroyAddress — что фактически опустошило резервы SOF в этой паре. После сжигания и вызова sync() в паре осталось 313 816 344e18 USDT и только 10e9 SOF. Поскольку цена SOF стала астрономически высокой, последующий обмен принес огромную выплату в USDT.
Этап 4: Злоумышленник погасил флэш-кредит и оставил себе прибыль — около $225 тыс.

Заключение

Уязвимость показывает, что для токенов с механизмом «сжигания перед продажей» критически важно контролировать, кто может покупать токен. Любой, кто способен продать токен, может получить прибыль; если злоумышленник может покупать токены из пула, он может искусственно завысить цену, а затем продать их обратно, выведя все средства из пула.

Расследование показало, что функция _antiFlashloanGuard() реализована некорректно. Она ограничивает одного и того же msg.sender от совершения покупки и продажи, вместо того чтобы отслеживать tx.origin. Это позволяет злоумышленнику обходить защиту, выбирая адрес, освобожденный от комиссий, в качестве to (получателя) при операции покупки.

Чтобы предотвратить подобные эксплойты, разработчики должны гарантировать, что покупки в пуле могут совершать только авторизованные роли. Кроме того, реализация _antiFlashloanGuard() должна фиксировать как tx.origin, так и адрес пользователя, чтобы предотвратить использование нескольких кошельков для выполнения покупки и продажи в рамках одной транзакции.

О компании BlockSec

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

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