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

За прошедшую неделю (2026/03/02 – 2026/03/08) компания BlockSec обнаружила и проанализировала семь инцидентов, связанных с атаками, общие убытки от которых оцениваются примерно в $3,25 млн. В таблице ниже представлены краткие сведения об этих инцидентах, а детальный анализ каждого случая приведен в последующих подразделах.

*Инцидент с BUBU2 был пропущен в отчете за прошлую неделю и включен сюда для полноты картины.

1. Инцидент с BUBU2

Краткий обзор

1 марта 2026 года токен BUBU2 в сети BNB Chain подвергся атаке, в результате которой было потеряно около $19,7 тыс. Первопричиной стала ошибка проектирования токена: контракт содержит механизм дефляции с накоплением по времени, который при совершении перевода напрямую вычитает токены из резервов пары AMM. Перед началом атаки владелец контракта сократил интервал срабатывания до необоснованно малого значения, что привело к накоплению и исполнению сотен раундов сжигания за один вызов. Злоумышленник использовал флэш-кредит для активации этого механизма, что привело к истощению резервов пары, искусственному завышению цены токена и последующей выгодной обратной конвертации по искаженному курсу.

Предыстория

BUBU2 — это дефляционный протокол токенов стандарта ERC-20, развернутый в сети BNB Chain. В протокол встроен механизм периодической дефляции, управляемый через burnAndMintSwitch: как только владелец активирует его с помощью setBurnAndMintSwitch(true), любой неисключенный из правил перевод, вызывающий хук _update(), запускает _triggerDailyBurnAndMint(). Эта функция сжигает токены из баланса BUBU2 торговой пары пропорционально количеству прошедших периодов TRIGGER_INTERVAL с момента последнего срабатывания и соответствующим образом синхронизирует резервы.

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

Первопричиной является конструктивный недостаток в контракте токена BUBU2 (0x3fF3...ee52). Контракт встраивает механизм периодической дефляции в свой хук _update(): при срабатывании _triggerDailyBurnAndMint() вычисляет число периодов TRIGGER_INTERVAL, прошедших с момента последнего исполнения, и сжигает пропорциональное количество BUBU2 непосредственно из торговой пары (0x7745...cd2f), после чего вызывает sync() для обновления резервов. Важно отметить, что владелец может изменять TRIGGER_INTERVAL без каких-либо временных блокировок или защиты минимальным порогом.

Перед атакой владелец вызвал setBurnAndMintSwitch(true), а затем setTriggerInterval(120), сократив интервал с 6 часов до 120 секунд. Поскольку lastTriggerTime по-прежнему указывало на время, прошедшее несколько часов назад, следующий триггер рассчитал сотни накопленных раундов, и сумма сжигания масштабировалась линейно количеству раундов. В результате один перевод привел к выводу огромного количества BUBU2 из пары, что спровоцировало крах её резервов и взлет цены токена примерно в 11 раз.

Анализ атаки

Следующий анализ основан на транзакциях 0x1bc0...141c, 0x191c...1ee4, 0xd6e5...51a6.

• Шаг 1: Владелец токена активировал механизм периодической дефляции через setBurnAndMintSwitch(true) и сократил интервал до 120 секунд через setTriggerInterval(120). Затем злоумышленник взял флэш-кредит на 18 WBNB и обменял их на примерно 18 715 856 BUBU2 из пула.

• Шаг 2: Злоумышленник инициировал небольшой перевод, запустив _triggerDailyBurnAndMint(). Баланс BUBU2 в пуле уменьшился примерно на 1 025 988 664 * 10^18 токенов; после выполнения sync() в резерве осталось лишь 6 493 352 * 10^18 BUBU2, что увеличило цену токена примерно в 200 раз.

• Шаг 3: Злоумышленник продал полученные ранее BUBU2 обратно в пул по завышенной цене, получив около 50 WBNB. После возврата флэш-кредита чистая прибыль составила примерно 32 WBNB.

Заключение

Эксплуатация BUBU2 стала возможной из-за критической ошибки проектирования контракта токена. Владелец установил необоснованно малый TRIGGER_INTERVAL, что позволило накопленным раундам сжечь резервы торговой пары за один вызов, вызвав резкий скачок цены BUBU2.

Для снижения подобных рисков в будущем:

• Защищайте критические параметры, такие как TRIGGER_INTERVAL, с помощью пороговых значений или временных блокировок.
• Ограничьте максимальное количество накапливаемых раундов исполнения.

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

Краткий обзор

2 марта 2026 года протокол ACPRoute в сети Base подвергся атаке с убытком около $58 тыс. Первопричиной стала ошибка бизнес-логики в контракте менеджера платежей: состояние задания (job state) загружалось как копия в память, а не как ссылка на хранилище, поэтому отслеживание совокупных выплат не фиксировалось в блокчейне. Это позволило злоумышленнику создать задание, запустить автоматический выпуск платежа во время перехода фаз, а затем повторно истребовать заблокированные средства через функцию без ограничения прав доступа.

Предыстория

ACP (Agent Commerce Protocol) — это модульный протокол коммерции в сети, предназначенный для взаимодействия клиентов и поставщиков. Его деятельность структурирована в три уровня: Accounts, Jobs и Memos. Задания следуют фиксированному жизненному циклу (REQUEST → NEGOTIATION → TRANSACTION → EVALUATION → COMPLETED), а платежи удерживаются на условном депонировании (escrow) контрактом PaymentManager на фазе TRANSACTION. Когда задание переходит в статус COMPLETED, протокол освобождает средства для поставщика через функцию releasePayment(). Чтобы предотвратить повторное получение, протокол отслеживает выплаты для каждого задания через поле amountClaimed в структуре Job. Ожидается, что при каждом вызове releasePayment() запрошенная сумма сравнивается с amountClaimed, чтобы деньги выплачивались только один раз.

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

Первопричина кроется в функции releasePayment() контракта PaymentManager (0x56c3...0684), где состояние задания загружается как копия в памяти. Хотя протокол отслеживает выплаты через amountClaimed для предотвращения двойного списания, операция job.amountClaimed += amount применяется только к временной локальной копии и никогда не записывается в блокчейн. В результате, каждый вызов releasePayment() видит amountClaimed == 0, что позволяет злоумышленнику вызвать claimBudget() и повторно обналичить средства из контракта-жертвы (0x307e...d6e8) после того, как переход фазы уже автоматически запустил releasePayment().

Анализ атаки

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

• Шаг 1: Злоумышленник занял 97 000 * 10^6 USDC через флэш-кредит в качестве оборотного капитала.
• Шаг 2: Внутри колбэка злоумышленник вызвал createJob() в ACPRouter, развернув новый контракт-поставщик для получения средств.
• Шаг 3: Злоумышленник многократно вызывал createMemo() и исполнял exec() контракта поставщика для продвижения фазы задания, пока не был достигнут статус COMPLETED. Это автоматически вызвало releasePayment() и перечислило баланс контракту поставщика. На этом этапе amountClaimed должен был обновиться, но в хранилище он остался равен 0.
• Шаг 4: Злоумышленник вызвал функцию claimBudget() и успешно забрал те же 97 000 * 10^6 USDC во второй раз в качестве прибыли.

Заключение

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

Для снижения подобных рисков в будущем:

• Убедитесь, что критические переменные состояния (например, amountClaimed) обновляются с использованием ссылок на хранилище.
• Ограничьте чувствительные функции выплат или обеспечьте строгую проверку состояния перед их выполнением.

3. Инцидент с рынком sDOLA Llamalend

Краткий обзор

2 марта 2026 года рынок sDOLA Llamalend в сети Ethereum пострадал от атаки, повлекшей убытки в $239 тыс. Первопричиной стала манипуляция ценой. sDOLA — токен ERC-4626, цену которого можно исказить через donate(). Llamalend — это кредитный рынок на базе AMM, где из-за специфики LLAMMA пользователи могут быть ликвидированы, даже если цена их обеспечения растет. Злоумышленник использовал donate() для искусственного завышения цены sDOLA, тем самым снизив показатель здоровья позиций пользователей ниже нуля и ликвидировав их ради прибыли.

Предыстория

LLAMMA (Lending-Liquidating AMM Algorithm) — кредитный рынок на базе AMM, используемый Curve [1]. В отличие от традиционных протоколов, LLAMMA размещает обеспечение пользователей в ценовых диапазонах внутри AMM. По мере движения оракульной цены $P_{oracle}P\_\{oracle\}$ обеспечение постепенно конвертируется между токенами обеспечения и crvUSD через арбитражные обмены между диапазонами (мягкая ликвидация), что снижает риск позиций без резких срывов.

Если мягкая ликвидация не справляется, активируется жесткая ликвидация [2], которая срабатывает, если уровень здоровья позиции падает ниже нуля. Здоровье рассчитывается через get_x_down() [3], оценивающую восстановимую стоимость через два ценовых якоря: один зависит от текущего $P_{oracle}P\_\{oracle\}$ (динамический), второй зафиксирован при создании позиции (статический).

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

Уязвимые контракты включают crvUSD Controller (0xad44...fb86) и LLAMMA AMM (0x0079...a1f7). Контракт-жертва — рынок sDOLA Llamalend (0x2b08...4fbe).

sDOLA — токен хранилища ERC-4626, цена которого зависит от отношения активов к количеству долей. Поскольку любой может вызвать donate() для пополнения хранилища, цена доли может быть искусственно завышена за одну транзакцию. Это и стало манипулируемым оракулом, от которого зависит функция get_x_down().

Функция рассчитывает здоровье путем симуляции «туда-обратной» конвертации через два якоря. При искусственно завышенной цене оракула динамический якорь растет, а статический — нет. В результате симуляция конвертирует crvUSD в обеспечение по завышенной оракульной цене, а обратно — по исходной, из-за чего оцениваемая восстановимая стоимость падает, вызывая ликвидацию даже при росте цены обеспечения.

Анализ атаки

Анализ основан на транзакции 0xb935...d8a4.

• Шаг 1: Манипуляция состоянием LLAMMA для смещения active_band.
• Шаг 2: Манипуляция ценой sDOLA через пожертвования и swap(0) для фиксации цены в пуле AMM.
• Шаг 3: Запуск пересчета здоровья через users_to_liquidate().
• Шаг 4: Из-за разрыва между динамическим и статическим ценовыми якорями многие позиции переходят в зону здоровья ниже нуля.
• Шаг 5: Пакетная ликвидация пользователей ради прибыли.

Заключение

Атака на манипуляцию ценой обеспечения. Из-за механизма расчета здоровья в LLAMMA даже рост цены обеспечения может привести к ликвидации. Рекомендации:

• Использовать задержку или TWAP-цены при ликвидации.

4. Инцидент с V4 Router от z0r0z

Краткий обзор

3 марта 2026 года на Ethereum был атакован V4 Router от z0r0z ($42 тыс. убытков). Причина — дефект логики авторизации в swap(), полагавшейся на фиксированное смещение в calldata для сравнения плательщика с msg.sender. Поскольку кодирование ABI для динамических типов не гарантирует фиксированную раскладку, злоумышленник подделал calldata, имитируя одобренного пользователя как плательщика и перенаправив результат обмена на свой адрес.

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

Причина кроется в контракте 0x0000...ce97. В функции swap() авторизация проверялась через ассемблерный блок, сравнивающий calldataload(164) с caller(). Протокол полагал, что смещение байтов всегда равно 0x40. Однако динамические параметры ABI лишь ссылаются на смещение в хвосте, и это смещение может указывать на любое выровненное место в calldata. Злоумышленник переместил смещение bytes, вставив произвольные данные, чтобы обмануть проверку и подставить свой адрес как отправителя, при этом фактически используя средства жертвы.

Заключение

Не полагайтесь на жестко закодированные смещения calldata для авторизации. Используйте каноническое декодирование ABI.

5. Инцидент с контрактом BitcoinReserveOffering

Краткий обзор

5 марта 2026 года был атакован контракт BitcoinReserveOffering в сети Ethereum ($2,7 млн убытков). Причина: логика минтинга выполнялась дважды при депозите ERC-3525 SFT (один раз в обратном вызове, другой — в основном потоке). Злоумышленник использовал циклы сжигания и минтинга для инфляции баланса токенов BRO, которые затем обменивал на SolvBTC.

Заключение

Убедитесь, что учет активов происходит ровно один раз за операцию. Добавьте проверку инвариантов, чтобы предотвратить превышение суммы минтинга над депозитом.

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

Краткий обзор

7 марта 2026 года протокол MoltEVM в сети Base потерял $127 тыс. из-за слабой логики проверки прав доступа. Модификатор onlySpawnerToken проверял лишь наличие интерфейса у вызывающего контракта, что легко обходилось деплоем вредоносного контракта с нужным ответом функции initialized().

Заключение

Не полагайтесь на легко подделываемые проверки контрактов. Проверяйте идентичность вызывающего субъекта через явные белые списки или реестры.

7. Инцидент с LEDS

Краткий обзор

8 марта 2026 года токен LEDS в BNB Chain пострадал от атаки на $64 тыс. Первопричина — наличие нескольких независимых механизмов сжигания без защиты или ограничения по времени. Атакующий объединил их в одной транзакции, полностью опустошив резервы пары LEDS и выведя средства через обратные обмены.

Заключение

Никогда не выставляйте функции сжигания из пары без прав доступа и ограничения частоты вызовов (cooldown).

О BlockSec

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

• Официальный сайт: https://blocksec.com/
• Twitter: https://twitter.com/BlockSecTeam
• Аудиторские услуги
• Phalcon Security APP