Back to Blog

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

Code Auditing
March 4, 2026
10 min read

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

Дата Инцидент Тип Оценочный ущерб
23.02.2026 Инцидент LAXO Ошибка в дизайне токена ~$137 тыс.
23.02.2026 Инцидент YieldBloxDAO Неверная настройка оракула ~$10 млн
24.02.2026 Инцидент STO Ошибка в дизайне токена ~$16,1 тыс.
26.02.2026 Инцидент HedgePay Ошибка бизнес-логики ~$15,7 тыс.
27.02.2026 Инцидент Ploutos Неверная настройка оракула ~$390 тыс.
27.02.2026 Инцидент FOOMCASH Ошибка бизнес-логики ~$2,26 млн
28.02.2026 Неизвестный инцидент Некорректная проверка входных данных ~$180 тыс.

1. Инцидент LAXO

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

22 февраля 2026 года токен стандарта ERC20 LAXO в сети BNB Smart Chain подвергся атаке, что привело к убыткам в размере около $137 320 в паре LAXO-USDT. Первопричиной стал дефектный механизм сжигания, который активировался при прямой передаче LAXO в пару PancakeSwap. Поскольку роутер был добавлен в белый список и не запускает логику сжигания в функции transfer(), злоумышленник обошел ограничение: он отправил LAXO в пару напрямую, а затем вызвал низкоуровневую функцию swap() пула, которая сожгла токены пары и вызвала sync(), искусственно завысив цену. После этого злоумышленник обменял токены обратно на USDT, получив прибыль.

Предыстория

Токен LAXO реализует механизм сжигания. Когда получателем перевода является адрес пары PancakeSwap USDT–LAXO, токен интерпретирует это как продажу: он сжигает соответствующее количество токенов из пары, а затем вызывает sync() для обновления резервов пары.

Кроме того, токен LAXO использует белый список (_isExcludedFromFee), чтобы освободить определенные адреса (например, роутеры обмена) от механизма сжигания и комиссий.

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

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

Анализ атаки

Анализ атаки основан на транзакции 0xd58f3ef6...d98ac7d3.

  1. Злоумышленник взял флэш-кредит на 350 000e18 USDT через PancakeSwap V3.

  2. Злоумышленник обменял USDT на LAXO через PancakeSwap Router. Чтобы обойти торговые ограничения (buyEnabled = false) и логику комиссий, злоумышленник создал пару BNB–LAXO V2 и направил торговлю через нее.

  1. Злоумышленник перевел все имеющиеся LAXO непосредственно в пару USDT–LAXO. Это уменьшило резерв LAXO в пуле, в то время как резерв USDT остался почти неизменным, что привело к резкому росту цены LAXO в паре USDT–LAXO.

  2. Злоумышленник обменял burnAmount токенов LAXO на ~487 500e18 USDT, исходя из манипулируемой цены.

  3. Злоумышленник погасил флэш-кредит и оставил остаток USDT в качестве прибыли.

Заключение

Первопричина инцидента кроется в дефектном механизме сжигания LAXO, который позволяет злоумышленникам выводить USDT из пула через манипуляцию ценой. Инцидент привел к убыткам в размере около $137,3 тыс. Для предотвращения подобных проблем проект обязан проводить комплексное тестирование механизма сжигания.


2. Инцидент YieldBloxDAO

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

22 февраля 2026 года пул кредитования под управлением YieldBlox DAO на платформе Stellar Blend V2 подвергся атаке, что привело к убыткам, превышающим $10 млн [1]. Инцидент был вызван не ошибкой в смарт-контрактах, а неверной конфигурацией со стороны оператора пула (YieldBlox DAO).

В частности, злоумышленник манипулировал рынком USTRY/USDC на SDEX. Настроенный оракул Reflector в пуле принял манипулируемую цену, что привело к переоценке USTRY в качестве залога и позволило атакующему вывести активы из пула, включая USDC и XLM.

Предыстория

В блокчейне Stellar протокол Blend V2 является протоколом ликвидности, позволяющим создавать изолированные пулы кредитования. Пулы способствуют кредитованию и заимствованию активов между пользователями. В данном инциденте пострадавший пул позволял пользователям брать в долг XLM и USDC, используя USTRY в качестве залога. Кроме того, при создании пула был выбран оракул Reflector [2]. Цена USTRY, предоставляемая оракулом Reflector, обновляется каждые пять минут на основе рынка USTRY/USDC на Stellar DEX (SDEX) [3].

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

Первопричиной стала манипуляция ценой на низколиквидном рынке USTRY/USDC на SDEX, что привело к некорректному обновлению цены USTRY в оракуле Reflector. Из-за крайне низкой ликвидности рынка USTRY/USDC злоумышленник смог поглотить обычные ордера и разместить аномальные, чтобы завысить цену USTRY в 100 раз. Эта цена транслировалась в оракул Reflector, позволяя злоумышленнику занять все активы (XLM и USDC) из пула, предоставив в залог переоцененный USTRY.

Анализ атаки

  1. (Tx 1, 2) Злоумышленник манипулировал ценой USTRY на SDEX, подняв её с $1.06 до примерно $107. Поскольку рынок USTRY/USDC на SDEX крайне неглубок, злоумышленник поглотил все обычные ордера и разместил аномальные, резко толкнув цену вверх.
  1. (Tx 3) Оракул Reflector получил манипулируемую цену с SDEX и соответствующим образом обновил ценовую ленту.
  1. (Tx 4, 5) Злоумышленник занял 1 000 196e7 USDC, предоставив в залог 12 881e7 USTRY. 7.png
  2. (Tx 6, 7) Злоумышленник занял 6 124 927 810e7 XLM, предоставив в залог 14 987 610e7 USTRY.
  1. (Txs 8, 9, 10) Наконец, злоумышленник перевел выведенные активы через мосты на другие сети, включая Base, BSC и Ethereum.

Заключение

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

Ссылки

[1] https://blocksec.com/blog/yieldblox-dao-incident-on-stellar-oracle-misconfiguration-enabled-a-10m-drain

[2] https://reflector.network/

[3] USTRY/USDC Market on the SDEX


3. Инцидент STO

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

23 февраля 2026 года пул STO-WBNB на PancakeSwap в сети BNB Smart Chain был опустошен, что привело к убыткам около $16,1 тыс. Первопричиной стал дефектный механизм сжигания в токене STO. При продаже пользователями токенов STO в пуле срабатывал механизм сжигания, изымающий токены STO из пула и завышающий цену. В итоге злоумышленник воспользовался этой уязвимостью, чтобы вывести WBNB из пула.

Предыстория

Токен STO содержит механизм сжигания, ориентированный на пул PancakeSwap V2. Он срабатывает, только если функция продажи STO включена (sellEnabled == true) и pendingBurnFromSell > 0. Когда пользователь продает STO, механизм сжигает токены из пула. В частности, 94% проданных токенов сжигаются в последующей транзакции.

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

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

Анализ атаки

Анализ основан на транзакции 0x8ba17bea...5a54020c.

  1. Злоумышленник взял флэш-кредит на 360 894e18 WBNB.

  2. Злоумышленник вызвал функцию initializeLiquidity(), чтобы активировать функциональность покупки и продажи STO.

  1. Злоумышленник обменял 360 894e18 WBNB на 7 848 832e18 STO.

  2. Атакующий вызвал transfer(), активировав механизм сжигания для манипулирования резервами пары (цена STO выросла), одновременно установив сумму сжигания для следующей транзакции в 173 391e18.

  1. Злоумышленник вызвал swap(), чтобы обменять STO на WBNB, получив прибыль на манипулируемой цене.

  2. Атакующий повторял шаги 4 и 5 до исчерпания WBNB в пуле.

  3. Злоумышленник вернул кредит, сохранив прибыль в 26e18 WBNB.

Заключение

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


4. Инцидент HedgePay

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

25 февраля 2026 года протокол HedgePay в BNB Smart Chain подвергся атаке с убытком около $15,7 тыс. Первопричиной стала логическая ошибка в контракте стейкинга HedgePay. Функция forceExit() уязвимого контракта (0xBe189fe9f84cA531CD979630E1f14757b88dD80d) позволяла пользователям выводить заблокированные активы, не обновляя их баланс в стекинге. Это позволило злоумышленнику многократно вызывать forceExit() и вывести все токены HPAY из контракта.

Предыстория

HedgePay — это протокол стейкинга, позволяющий зарабатывать вознаграждения за стейкинг HPAY. Функция forceExit() позволяет пользователям принудительно выводить активы.

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

Первопричиной стала ошибка в логике функции forceExit(). Когда пользователи делают стейкинг через stake(), их баланс (_balances[msg.sender]) обновляется. Однако при принудительном выводе через forceExit() контракт забывает обновить _balances[msg.sender]. В результате баланс злоумышленника в памяти контракта не уменьшается, и он может повторять вывод до полного исчерпания средств.

Анализ атаки

Анализ основан на транзакции 0x5f2ea6cb...46ed137f.

  1. Злоумышленник взял флэш-кредит на 1 247 859e18 HPAY. a. Застейкал 1 197 944e18 HPAY. b. Многократно вызвал forceExit() для вывода средств.
  1. Атакующий вернул кредит, обменяв часть выведенных HPAY на прибыль в 26e18 WBNB.

Заключение

Ошибка в forceExit(), не обновлявшей состояние баланса, позволила провести атаку. Проектам следует проводить тестирование инвариантов состояния для каждой функции контракта.


5. Инцидент Ploutos

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

26 февраля 2026 года в протоколе Ploutos на Ethereum были потеряны около $390 000 из-за неверной настройки оракула. Оракул был ошибочно настроен на использование BTC/USD Chainlink для пары USDC. Это позволило злоумышленнику занять 187 ETH, предоставив в залог всего 8 USDC.

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

Ploutos — это форк Aave v3.0.2. Инцидент произошел из-за неправильной конфигурации оракула в пуле кредитования (0xD060...F945D2).

В блоке 24538896 оракул для USDC был настроен на передачу цен BTC/USDC. В следующем блоке хакер воспользовался этим, заняв 187.3 ETH под залог 8.88 USDC.

Анализ атаки

  1. Хакер отследил изменение настроек оракула в транзакции 0xcfedf6...bd193ab6.
  2. Мгновенно отправил транзакцию (0xa17dc37e...705f8474), выводя активы.
  3. Оплатил комиссии и получил прибыль ~181.7 ETH.

Заключение

Неверная настройка оракула привела к убыткам в $390 000. Критические настройки конфигурации должны быть защищены мультиподписными кошельками или механизмом timelock.


6. Инцидент FOOMCASH

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

26 февраля 2026 года протокол FOOMCASH подвергся атаке из-за уязвимой верификации доказательств Groth16 [1], что привело к потере более $2.26 млн.

Предыстория

FOOMCASH — лотерейный протокол, использующий доказательства Groth16 для верификации вывода средств. Контракт WithdrawG16Verifier выполнял проверку, но из-за некорректной настройки параметров (gamma и delta) доказательства могли быть подделаны.

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

В контракте WithdrawG16Verifier параметры γ\gamma (гамма) и δ\delta (дельта) имели идентичные значения (G_2G\_{2}), что позволяло злоумышленнику генерировать валидные доказательства с произвольными входными данными. Это полностью обошло систему защиты.

Анализ атаки

Злоумышленник создал контракт, конструирующий фальшивые доказательства.

  1. Сформировал доказательство.
  2. Вызвал collect() в контракте FoomLottery с вредоносными данными.
  3. Повторил это 30 раз, выведя 19,695,576,757,802e18 FOOM.

Заключение

Комплексные криптографические настройки должны проходить тщательный аудит перед развертыванием в основной сети.


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

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

27 февраля 2026 года неизвестный контракт в BSC подвергся атаке [1] с ущербом $180 тыс. Причина — неверная проверка входных данных. В функции _verifySignatures() отсутствовала проверка на пустоту списков, что позволило хакеру обойти проверку подписей, предоставив пустые массивы.

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

Функция проверяла только равенство длин массивов, но не проверяла, являются ли они пустыми.

Анализ атаки

  1. Злоумышленник вызвал poolWithdraw() с пустыми массивами allSigners и signatures.
  1. Проверка была пройдена, и контракт перевел USDT на адрес атакующего.

Заключение

Базовые проверки на пустоту входных данных критически важны для безопасности.


О компании BlockSec

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

Best Security Auditor for Web3

Validate design, code, and business logic before launch. Aligned with the highest industry security standards.

BlockSec Audit