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

За прошедшую неделю (2026/03/23 - 2026/03/29) BlockSec выявила и проанализировала восемь инцидентов, связанных с атаками. Общие оценочные потери составили ~$1,53 млн. В таблице ниже приведена сводка этих инцидентов, а подробный разбор каждого случая представлен в следующих подразделах.

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

Краткое описание

23 марта 2026 года непроверенный контракт в сети Ethereum подвергся атаке, в результате которой было похищено около $97 тыс. Причиной стало переполнение целого числа в логике распределения средств. Функция 0x317de4f6() суммировала заданные пользователем количества токенов без защиты от переполнения. Это позволило атакующему вызвать переполнение и вывести весь баланс USDT контракта через функцию claim(), заплатив всего 1 wei USDT.

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

Первопричиной стало переполнение целого числа в функции 0x317de4f6() контракта 0xF0a105...568C97. Функция принимает массив записей, каждая из которых содержит адрес аккаунта и сумму, и при обходе массива складывает все суммы в totalAmount. Поскольку при сложении не проверялось переполнение, атакующий мог передать специально составленные записи, суммы которых вызывали переполнение uint256. В результате totalAmount становился сколь угодно малым, тогда как суммы отдельных начислений оставались большими.

Анализ атаки

Приведённый ниже анализ основан на транзакции 0x73bd1384...630b053.

• Шаг 1: Атакующий получил 1 wei USDT из Uniswap V4 в качестве начального капитала для атаки.

  

• Шаг 2: Атакующий запросил баланс USDT контракта-жертвы, а затем вызвал 0x317de4f6() со специально составленным массивом. Одно значение суммы было задано близким к верхней границе uint256, а другое — равным балансу USDT контракта-жертвы. Их сумма переполнилась и стала равна 1. Благодаря этому атакующий заплатил всего 1 wei USDT, но получил право на вывод суммы, равной всему балансу USDT контракта-жертвы.

  

• Шаг 3: Атакующий вызвал claim() и вывел 97 812e6 USDT из контракта-жертвы.

  

• Шаг 4: Атакующий вернул заём в размере 1 wei USDT в Uniswap V4 и обменял оставшиеся USDT на WETH, завершив атаку.

Вывод

Этот инцидент показывает риски использования арифметики без проверки переполнения в версиях Solidity до 0.8.0. Во всех критически важных финансовых расчётах следует явно применять арифметические операции с защитой от переполнения, например SafeMath или Solidity >=0.8.x.

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

Краткое описание

23 марта 2026 года непроверенный контракт в сети Ethereum подвергся атаке с ущербом около $11 тыс. из-за уязвимости повторного входа. Функция 0xbe16634e() обновляла данные учёта ликвидности до завершения расчётов и вызывала внешний обратный вызов без защиты от повторного входа. Многократно повторно вызывая функцию до завершения предыдущего вызова, атакующий завысил учтённую за ним ликвидность, а затем вывел больше USDC и WETH, чем фактически внёс.

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

Первопричина — уязвимость повторного входа в функции 0xbe16634e() контракта 0x39Ed37...9C6b08. Эта функция обновляет состояние, связанное с ликвидностью, включая ликвидность пользователя и резервы тиков, до завершения расчётов и выполняет внешний обратный вызов через msg.sender.call() без защиты от повторного входа. Поскольку баланс проверяется отдельно для каждого вызова, атакующий может рекурсивно входить в функцию и завышать внутренние показатели учёта ликвидности. При этом одного перевода токенов в самом глубоком вызове достаточно, чтобы вложенная последовательность вызовов успешно завершилась.

Анализ атаки

Приведённый ниже анализ основан на транзакции 0x1382e898...fad993.

• Шаг 1: Атакующий получил 100e8 USDC и 10e18 WETH из Uniswap V4 в качестве начального капитала для атаки.

  

• Шаг 2: Атакующий вызвал 0xbe16634e() для добавления ликвидности. Во время выполнения контракт-жертва вызвал функцию атакующего 0x7c65be42(), которая повторно вызвала 0xbe16634e() до завершения предыдущего вызова.

  

• Шаг 3: Многократно повторив эту последовательность повторных входов, атакующий непрерывно увеличивал учтённую за ним ликвидность. В самом глубоком вызове он один раз перевёл необходимые токены, чего хватило для прохождения вложенных проверок баланса.

  

• Шаг 4: Завысив учтённую ликвидность, атакующий проверил состояние пула и перевёл в него дополнительные средства, чтобы в пуле оказалось достаточно USDC и WETH для предстоящего вывода.

  

• Шаг 5: Атакующий снова вызвал 0xbe16634e(), на этот раз для удаления ликвидности, и вывел из пула USDC и WETH исходя из завышенных учётных данных.

  

• Шаг 6: Атакующий вернул заём Uniswap V4, обменял оставшиеся USDC на WETH и завершил атаку.

  

Вывод

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

3. Инцидент с Cyrus Finance

Краткое описание

23 марта 2026 года протокол доходного фарминга Cyrus Finance в сети BNB Chain подвергся атаке с ущербом около $512 тыс. Причиной стала ошибочная формула удаления ликвидности, зависящая от текущей спотовой цены пула. Протокол использует NFT-позиции CYRP для представления пропорциональной доли в своей ликвидности PancakeSwap V3, однако при преобразовании доли пользователя в базовую ликвидность считывает slot0(), значение которого можно изменить в рамках одной транзакции. Сдвинув цену с помощью свопа, профинансированного флеш-кредитом, атакующий завысил стоимость ликвидности своей NFT-позиции и вывел больше, чем ему полагалось.

Общая информация

Cyrus Finance — протокол доходного фарминга в сети BNB Chain, управляющий позициями ликвидности в пулах PancakeSwap V3. Пользователи вносят USDT и получают NFT-позиции CYRP, представляющие их долю в ликвидности протокола, распределённой между несколькими позициями PancakeSwap V3. Через функцию exit() пользователи могут вывести внесённые средства вместе с вознаграждением.

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

Уязвимость находится в функции withdrawUSDTFromAny() контракта CyrusTreasury (0xb042Ea...0aE10b). При обработке вывода функция получает sqrtPriceX96 из slot0() пула PancakeSwap V3, то есть текущую спотовую цену, и передаёт её в getAmountsForLiquidity(), чтобы оценить, какому количеству amount0 / amount1 соответствует вся ликвидность позиции протокола в данный момент.

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

$liquidityToUse = liquidity \cdot remaining / availableUSDT$

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

Такой подход небезопасен, поскольку значением slot0() можно манипулировать в рамках одной транзакции. Временно изменив цену пула, атакующий может исказить availableUSDT, что напрямую влияет на вычисляемое значение liquidityToUse.

Анализ атаки

Приведённый ниже анализ основан на транзакции 0x85ac5d15...46d452.

• Шаг 1: Атакующий получил флеш-кредит из пула PancakeSwap V3, заняв около 1 798 ETH.

• Шаг 2: Атакующий провёл крупный обмен ETH на USDT в целевом пуле, где протокол размещал ликвидность, намеренно изменив цену пула и текущий тик. Одновременно он перевёл NFT-позицию CYRP #15505 с адреса 0x01737d...6ffa3 на атакующий контракт через safeTransferFrom().

• Шаг 3: Атакующий вызвал exit(15505) в CyrusTreasury. Во время выполнения withdrawUSDTFromAny() считала значение slot0() из пула PancakeSwap V3 и вычислила availableUSDT на основе изменённой спотовой цены. Из-за искажённого тика протокол завысил стоимость ликвидности, соответствующей доле NFT. Затем он вызвал decreaseLiquidity() и collect(), выдав избыточное количество USDT сверх справедливой стоимости позиции Cyrus.

  

• Шаг 4: Атакующий восстановил состояние пула, вернул флеш-кредит и перевёл оставшуюся прибыль (~$512 тыс.) на адрес EOA 0xf96EB1...3b63b.

Вывод

Для устранения уязвимости при преобразовании ликвидности в доступные для вывода USDT следует заменить спотовую цену из slot0() на цену, устойчивую к манипуляциям: TWAP за достаточно длительный период наблюдения или данные внешнего оракула, например Chainlink.

4. Инцидент с токеном BCE

Краткое описание

23 марта 2026 года пул PancakeSwap BCE-USDT в сети BNB Chain подвергся атаке с ущербом около $679 тыс. из-за ошибочного механизма сжигания токена BCE. Атакующий развернул два вредоносных контракта, чтобы обойти ограничения на покупку и продажу BCE, и вызвал сжигание токенов из резервов пула ликвидности. Так он изменил цену в пуле и вывел из него USDT.

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

Уязвимость связана с ошибочным механизмом сжигания токена BCE (0xcdb189...999999). Главная проблема состоит в том, что переменная состояния scheduledDestruction, на которую может влиять пользователь, используется для сжигания токенов непосредственно с адреса пары PancakeSwap, а не с баланса самого пользователя. При продаже контракт накапливает в scheduledDestruction сумму для сжигания, рассчитанную по объёму сделки и текущим резервам пула. Эта сумма не вычитается из баланса продавца. Вместо этого позднее она используется в отдельной ветке кода, которая сжигает токены пары и вызывает sync().

Поскольку атакующий контролирует объём сделок и может изменять резервы пула, он способен задать для scheduledDestruction произвольное значение и вызвать сжигание, которое уменьшит резерв BCE пары и изменит цену в пуле в его пользу.

Анализ атаки

Приведённый ниже анализ основан на транзакции 0x85ac5d15...46d452.

• Шаг 1: Атакующий вызвал вредоносный контракт (MC1), чтобы занять 123,5 млн USDT с помощью нескольких флеш-кредитов и пула кредитования.

• Шаг 2: Атакующий развернул второй вредоносный контракт (MC2) и перевёл на него все заёмные USDT.

• Шаг 3: Атакующий через MC2 обменял 2,222 млн USDT на 5,529 млн BCE в пуле BCE-USDT.

• Шаг 4: Атакующий перевёл 5,529 млн BCE из MC2 в MC1 через MC1.drain(); из-за механизма сжигания MC1 получил 2,764 млн BCE.

• Шаг 5: Атакующий через MC1 обменял 2,488 млн BCE на 1,368 млн USDT. При этом значение переменной scheduledDestruction обновилось примерно до 174 тыс. на основе резервов пула и суммы обмена. Позднее эта переменная определила количество сжигаемых токенов.

• Шаг 6: Атакующий через MC2 обменял 34,9 млн USDT на 3,484 млн BCE, дополнительно изменив резерв BCE так, что он приблизился к 174 тыс.

• Шаг 7: Атакующий перевёл 3,484 млн BCE и оставшиеся USDT из MC2 в MC1. Поскольку значение scheduledDestruction было больше 0, то есть составляло около 174 тыс., перевод BCE вызвал сжигание, сократившее резерв BCE примерно до 10 000.

• Шаг 8: Атакующий обменял оставшиеся BCE на USDT по изменённой цене.

• Шаг 9: Атакующий вернул все займы и получил чистую прибыль около $679 тыс.

Вывод

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

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

Краткое описание

25 марта 2026 года непроверенный стейкинг-контракт в сети BNB Chain подвергся атаке с ущербом около $1,2 тыс. из-за несогласованного учёта между несколькими режимами стейкинга. Контракт использовал одну и ту же переменную позиции для stake2()/withdraw2() и stake3()/withdraw3(), хотя эти функции работали с разными наборами токенов и соотношениями. Атакующий внёс средства через облегчённый режим stake2() и вывел их через более затратный для контракта режим withdraw3(), многократно получая избыточные токены.

Общая информация

Этот стейкинг-контракт поддерживает несколько режимов внесения и вывода средств. Стандартная пара stake() и withdraw() представляет собой полный режим стейкинга, который работает с набором токенов Pangolin, Bzzt и Bzzone и включает логику учёта вознаграждений. Пара stake3() и withdraw3() использует тот же набор из трёх токенов и то же соотношение при внесении и выводе, но пропускает дополнительный учёт вознаграждений. В отличие от них, пара stake2() и withdraw2() представляет собой облегчённый режим, работающий только с Pangolin и Bzzt, а потому использует другую комбинацию токенов и другое соотношение.

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

Первопричиной стал несогласованный учёт в контракте 0x29d36c...774137. Хотя stake2()/withdraw2() и stake3()/withdraw3() работали с разными наборами токенов, все они обновляли одни и те же переменные _exit[msg.sender] и _totalSupply. Поэтому позицию, созданную через облегчённый режим stake2(), можно было погасить через более затратный для контракта режим withdraw3().

На практике stake2(amount) принимала лишь amount токенов Pangolin и amount токенов Bzzt, тогда как withdraw3(amount) возвращала amount токенов Pangolin, 10 * amount токенов Bzzt и 10 * amount токенов Bzzone. Это означало, что внесение 20e18 Pangolin и 20e18 Bzzt через stake2() создавало баланс _exit, с помощью которого позднее можно было вывести через withdraw3() 20e18 Pangolin, 200e18 Bzzt и 200e18 Bzzone. Многократно используя это несоответствие, атакующий непрерывно выводил из контракта избыточные токены.

Анализ атаки

Приведённый ниже анализ основан на транзакции 0x7fcd5882...323f8d.

• Шаг 1: Атакующий развернул контракт по адресу 0x9bce07d8bbe4f19dfe465710ff9612878bfe3302, пополнил его на 0,05 BNB, преобразовал эти средства в WBNB, обменял их ровно на 20e18 Pangolin, 20e18 Bzzt и 200e18 Bzzone, а затем разрешил стейкинг-контракту расходовать приобретённые токены.

  

• Шаг 2: Атакующий вызвал stake2() с аргументом 20e18. Функция перевела 20e18 Pangolin и 20e18 Bzzt в стейкинг-контракт и увеличила общий для режимов баланс _exit атакующего на 20e18.

  

• Шаг 3: Затем атакующий вызвал withdraw3() с аргументом 20e18. Поскольку withdraw3() проверяла только общий баланс _exit, контракт вернул 20e18 Pangolin, 200e18 Bzzt и 200e18 Bzzone, хотя позиция была создана через stake2().

  

• Шаг 4: Атакующий многократно повторил цикл stake2() -> withdraw3() в рамках одной транзакции. На каждом шаге возвращённые Pangolin и небольшая часть возвращённых Bzzt использовались для следующего вызова stake2(), а Bzzone отправлялись обратно в стейкинг-контракт, чтобы последующие вызовы withdraw3() продолжали успешно выполняться. В результате этого цикла атакующий увеличил свой баланс Bzzt с 20e18 до 16 400e18.

• Шаг 5: Атакующий обменял полученные токены обратно на WBNB, преобразовал средства в BNB и перевёл около 2,007e18 BNB на свой EOA, завершив атаку.

  

Вывод

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

6. Инцидент с MYX

Краткое описание

25 марта 2026 года контракт sMYX проекта MYX Network в сети Ethereum подвергся атаке. В результате из пула было выведено около 6,67 млн токенов MYX (прибыль составила ~$3,6 тыс.). Первопричиной стало ошибочное взаимодействие между учётом предложения токенов в функции перевода и логикой распределения дивидендов в контракте sMYX. Многократно переводя sMYX между подконтрольными аккаунтами, атакующий завысил переменную прибыли на долю, создал не обеспеченные активами дивиденды и вывел больше MYX, чем внёс изначально.

Общая информация

Контракт sMYX (0x404328...d27F66) работает по модели токена с распределением дивидендов. Пользователи вносят токены MYX через функцию покупки и получают доли sMYX, представляющие их вклад. Для учёта дивидендов используется глобальный накопительный показатель прибыли на долю, хранящийся в stor_11. Доступные пользователю дивиденды рассчитываются как разница между его пропорциональной долей накопленной прибыли и зафиксированной базой уже учтённых выплат. Концептуально эта модель похожа на более ранние токены с механизмом отражения, в которых поступающая стоимость перераспределяется между существующими держателями.

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

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

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

Анализ атаки

Приведённый ниже анализ основан на транзакции 0x843c9ea7...a55b90.

• Шаг 1: Атакующий получил начальный капитал через флеш-своп и обменял его на MYX, после чего внёс токены в контракт sMYX и получил доминирующую долю в системе распределения дивидендов. Это обеспечило ему контроль над большей частью будущих выплат.

• Шаг 2: Атакующий разделил свою позицию между двумя подконтрольными контрактами и запустил согласованный цикл, в котором получение дивидендов чередовалось с изменением состояния. Это позволило многократно задействовать уязвимую логику учёта.

• Шаг 3: Многократными переводами между подконтрольными аккаунтами атакующий искусственно завышал показатель прибыли на долю и одновременно уменьшал учтённое общее предложение, создавая не обеспеченные активами дивиденды и увеличивая темп их распределения.

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

• Шаг 5: Атакующий закрыл все позиции, обменял выведенные MYX обратно на WETH, вернул флеш-кредит и оставил остаток себе в качестве прибыли.

Вывод

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

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

Краткое описание

26 марта 2026 года стейкинг-контракт TUR с реферальными вознаграждениями в сети BNB Chain подвергся атаке с ущербом около $133,5 тыс. Контракт Stake рассчитывал стоимость депозита по текущим спотовым ценам AMM, которыми можно манипулировать в рамках одной транзакции. Атакующий использовал флеш-кредит, чтобы завысить цену TUR, внёс токены в стейкинг во время этого временного повышения и вывел несоразмерно большие вознаграждения в TUR через подконтрольные реферальные аккаунты.

Общая информация

Контракт Stake (0x03D809...415Abe) — это стейкинг-контракт TUR с реферальными вознаграждениями. Сначала пользователи привязывают вышестоящий аккаунт через bind(), а затем вызывают stake(). Эта функция сжигает внесённые TUR, отправляя их на 0xdead, и начисляет пользователю внутренний показатель power — вес, от которого зависит, сколько TUR пользователь сможет впоследствии получить в качестве вознаграждения.

power не начисляется по фиксированному соотношению. Вместо этого getPowerAmount() переводит внесённые TUR в стоимость, выраженную в USDT, последовательно применяя две текущие цены AMM: TUR/NOBEL и NOBEL/USDT. Обе цены считываются из текущих резервов пар. Кроме того, контракт начисляет дополнительный показатель power реферерам первого и второго уровня через _distributeRefPower().

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

Первопричиной стала небезопасная зависимость контракта Stake от спотовых цен. При каждом внесении stake() рассчитывает uValue = getPowerAmount(amount), преобразует его в _power = _uValue * 100, обновляет учётные данные пользователя, а затем вызывает _distributeRefPower() для начисления дополнительного показателя power вышестоящим реферерам.

В частности, uValue рассчитывается следующим образом:

$uValue = getPowerAmount(amount)$

где getPowerAmount() фактически вычисляет:

$amount \times \text{TUR/NOBEL spot price} \times \text{NOBEL/USDT spot price}$

Реализация считывает эти цены непосредственно из текущих резервов пар через getReserves(). Поэтому оценка внесённых в стейкинг средств полностью зависит от спотовых цен в той же транзакции, а не от устойчивого к манипуляциям оракула или TWAP.

Это позволяет атакующему временно завысить ончейн-оценку TUR, внести токены в стейкинг в период манипуляции и получить завышенные uValue и power. Реферальная логика усиливает ущерб: _distributeRefPower() начисляет первому рефереру 20% показателя power пользователя, а второму — 5%, однако эти дополнительные начисления не сопровождаются соответствующим обновлением rewardDebt для рефереров. Поэтому подконтрольные атакующему реферальные аккаунты могут немедленно получить несоразмерно большие вознаграждения в TUR из контракта Stake.

Анализ атаки

Приведённый ниже анализ основан на транзакции 0x96c9ce3c...81e348.

• Шаг 1: Атакующий занял 1 900 000e18 USDT у контракта Moolah проекта ListaDAO в качестве флеш-кредита.

• Шаг 2: Атакующий использовал заёмные средства, чтобы изменить состояние пулов NOBEL-USDT и TUR-NOBEL, временно резко завысив спотовую оценку TUR.

• Шаг 3: Во время действия изменённой цены атакующий внёс 7 770 707e18 TUR в контракт Stake. Транзакция сгенерировала событие StakeEvent с сильно завышенным uValue в размере 8 283 864e18 и соответствующим power в размере 828 386 488e18.

• Шаг 4: Поскольку атакующий заранее подготовил подконтрольные реферальные аккаунты, _distributeRefPower() начислила им дополнительный показатель power, рассчитанный на основе внесённых по изменённой цене токенов. Первый и второй рефереры получили предусмотренные начисления в размере 20% и 5%.

• Шаг 5: Затем реферальные аккаунты с завышенным показателем power получили вознаграждения в TUR из контракта Stake. В той же транзакции Stake перевёл 15 238 941e18 TUR на 0xFd11...AcEaB и 3 809 924e18 TUR на 0x9007...E550B; оба адреса сразу переслали полученные суммы атакующему. Соотношение выплат 4:1 соответствует предусмотренному контрактом распределению реферального показателя power в размере 20% и 5%.

• Шаг 6: Транзакция также показывает, что комиссии за получение вознаграждений поступили из Stake на адрес фонда 0xb302...89923. Это соответствует реализации claim(), которая удерживает комиссию в размере 3% TUR перед отправкой вознаграждений получателям.

• Шаг 7: Выведя увеличенные вознаграждения в TUR, атакующий обменял их обратно на USDT, вернул флеш-кредит в размере 1 900 000 USDT и перевёл 133 490e18 USDT на 0xEf67...4e5898 в качестве прибыли.

Вывод

Причиной инцидента стала модель оценки вознаграждений в контракте Stake, допускающая манипуляции, а не отдельный механизм учёта дивидендов поставщиков ликвидности токена TUR. Привязав стейкинговый показатель power и реферальные вознаграждения к текущему соотношению резервов AMM, контракт позволил атакующему с помощью флеш-кредита завысить спотовую цену TUR, создать избыточное право на вознаграждения и вывести TUR из стейкинг-контракта через подконтрольные реферальные аккаунты. Более безопасная архитектура должна заменить оценку по текущим резервам на устойчивый к манипуляциям оракул или TWAP за достаточно длительный период, а также обеспечивать согласованное обновление учёта задолженности по вознаграждениям при любом увеличении реферального показателя power.

8. Инцидент с токеном EST

Краткое описание

27 марта 2026 года контракт BNBDeposit в сети BNB Chain подвергся атаке с ущербом около $92,3 тыс. из-за двух проблем: зависимости BNBDeposit от спотовой цены и ошибочного механизма сжигания токена EST. Зависимость от цены позволила атакующему получить большое количество EST, а ошибка механизма сжигания — вывести средства из пула EST-WBNB с помощью манипуляции по принципу сэндвич-атаки.

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

Инцидент имел две первопричины:

1. Функция onTokenReceived() контракта BNBDeposit (0xE71547...d29A61) рассчитывала доступную пользователям сумму на основе баланса контракта и спотовой цены EST. Обоими показателями легко манипулировать.

   

2. Токен EST (0xD4524B...498a91) имел ошибочный механизм сжигания, позволяющий атакующему сжигать EST в пуле EST-WBNB путём прямого перевода EST в пул.

   

Использовав обе уязвимости, атакующий провёл сэндвич-атаку и вывел WBNB из пула EST-WBNB.

Анализ атаки

Приведённый ниже анализ основан на транзакции 0x2f1c33ea...bd1626.

• Шаг 1: Атакующий занял 250 000e18 WBNB через Moolah и преобразовал 15e18 WBNB в BNB для проведения атаки.

• Шаг 2: Атакующий 34 раза перевёл по 0,3e18 BNB в BNBDeposit (всего 10,2e18 BNB). Каждый прямой перевод запускал логику внесения средств. На этом этапе атакующий получил ~9 100e18 LP-токенов (в виртуальном учёте) и 2,65e18 WBNB в качестве бонуса.

• Шаг 3: Атакующий обменял 400e18 WBNB примерно на 822Me18 EST, указав BNBDeposit получателем. Это увеличило баланс EST контракта BNBDeposit и цену EST в пуле.

• Шаг 4: Атакующий перевёл 1e18 EST в BNBDeposit, чтобы запустить механизм получения токенов, и получил 20Me18 EST на основе завышенных цены и баланса.

• Шаг 5: Атакующий обменял 245 000e18 WBNB примерно на 330Me18 EST, вновь указав BNBDeposit получателем.

• Шаг 6: Атакующий около 150 раз выполнил операции перевода и skim, чтобы непрерывно сжигать EST в пуле EST-WBNB.

• Шаг 7: Атакующий обменял оставшиеся EST на 245 560e18 WBNB.

• Шаг 8: Атакующий вернул флеш-кредит и получил чистую прибыль в размере 150 WBNB.

Вывод

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

О BlockSec

BlockSec — поставщик комплексных решений для безопасности блокчейна и соблюдения нормативных требований в сфере криптовалют. Мы создаём продукты и предоставляем услуги, которые помогают клиентам проводить аудит кода, включая смарт-контракты, блокчейны и кошельки, предотвращать атаки в реальном времени, анализировать инциденты, отслеживать незаконные средства и выполнять обязательства в сфере ПОД/ФТ на всех этапах жизненного цикла протоколов и платформ.

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

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

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

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

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

• 🔗 Phalcon Compliance