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

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

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

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

23 марта 2026 года верифицированный контракт в сети Ethereum был взломан на сумму около $97 тыс. из-за переполнения целых чисел в логике распределения. Функция 0x317de4f6() суммировала контролируемые пользователем суммы токенов без защиты от переполнения, что позволило злоумышленнику спровоцировать перенос разряда (wraparound) и вывести весь баланс 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 тыс. из-за уязвимости повторного входа (reentrancy). Функция 0xbe16634e() обновляла показатели ликвидности перед расчетом и вызывала внешний callback без какой-либо защиты от повторного входа. Повторно входя в функцию до завершения предыдущего вызова, атакующий завышал свои показатели ликвидности и впоследствии выводил больше USDC и WETH, чем фактически внес.

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

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

Анализ атаки

Следующий анализ основан на транзакции 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 и завершил эксплойт.

  

Заключение

Этот инцидент демонстрирует опасность обновления учета ликвидности перед расчетом при вызове незащищенного внешнего обратного вызова. Чтобы предотвратить подобные эксплойты, протоколы должны строго соблюдать паттерн «проверка-эффект-взаимодействие» (checks-effects-interactions) и защищать внешние вызовы с помощью reentrancy guards.

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\mathrm{/}availableUSDTliquidityToUse\; =\; liquidity\; \backslash cdot\; remaining\; /\; availableUSDT$

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

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

Анализ атаки

Следующий анализ основан на транзакции 0x85ac5d15...46d452.

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

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

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

  

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

Заключение

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

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

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

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

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

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

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

Анализ атаки

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

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

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

• Шаг 3: Через MC2 было обменено 2,222 млн USDT на 5,529 млн BCE в пуле.

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

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

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

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

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

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

Заключение

Инцидент вызван фундаментальным дефектом экономической логики токена. Контракт подразумевал, что пользователь платит за "уничтожение" самостоятельно, но на деле позволил злоумышленникам создавать отложенное сжигание, оплачиваемое из резервов LP.

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.

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

Хотя режимы работали с разными активами, все они обновляли переменные _exit[msg.sender] и _totalSupply. В результате позиция, созданная через stake2(), могла быть выведена через withdraw3(). 20e18 Pangolin и 20e18 Bzzt в режиме stake2() позволяли вывести 20e18 Pangolin, 200e18 Bzzt и 200e18 Bzzone через withdraw3().

Анализ атаки

Анализ основан на транзакции 0x7fcd5882...323f8d.

• Шаг 1-3: Атакующий внес активы через stake2() и вывел через withdraw3(), получив в 10 раз больше, чем внес.
• Шаг 4-5: Повторяя цикл, атакующий увеличил свой баланс Bzzt с 20e18 до 16 400e18, превратив их в BNB и вывел прибыль.

Заключение

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

6. Инцидент MYX

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

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

Заключение

Трансферы токенов не должны изменять эмиссию или запускать распределение дивидендов, если они не подкреплены притоком реальных активов.

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

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

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

Анализ атаки

• Атакующий использовал флеш-кредит для манипуляции ценой TUR.
• В момент манипуляции он внес стейк, получив "раздутый" вес (power).
• Через подконтрольные реферальные аккаунты он вывел вознаграждения, которые превышали реальный вклад в десятки раз.

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

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

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

О компании BlockSec

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

BlockSec опубликовала множество статей по безопасности, сообщила о ряде уязвимостей нулевого дня, предотвратила взломы на сумму более $20 млн и обезопасила криптоактивы на миллиарды долларов.

• Официальный сайт: https://blocksec.com/
• Официальный Twitter: https://twitter.com/BlockSecTeam
• 🔗 Аудиторские услуги BlockSec : Отправить запрос
• 🔗 Phalcon Security APP: Записаться на демо
• 🔗 Phalcon Compliance