
24 и 26 марта 2026 года зафиксированы два инцидента с суммарным ущербом около $141 тыс. Оба эксплуатируют недостаточные проверки входных данных: в одном случае протокол доверяет поддельному резерву, в другом — считает цену актива по данным, которые можно исказить прямо в той же транзакции.
Манипуляция ценой TUR — $133 тыс
Ход инцидента
Дата: 26 марта 2026. Сеть: BNB Smart Chain.
TX: 0x96c9ce3c527681bf0da18511d142efb5769ad8dac1d9d659a6b70a697381e348
Злоумышленник накрутил цену TUR в связанных пулах, застейкал TUR по этой завышенной цене и через реферальные адреса забрал из Stake завышенные награды. Затем продал TUR обратно и вывел 133,490 BSC-USD.
Почему это стало возможным
Контракт Stake считал силу стейка по текущим резервам AMM-пула, то есть прямо по цене токена в момент транзакции. Цену можно было исказить там же. Дополнительно в stake() обновлялся rewardDebt только для самого стейкера, а реферальные адреса получали power, но без обновления своего rewardDebt. Из-за этого они сразу могли забрать завышенные награды.
Движение средств
Средства поступили на адрес 0xEf670D9c2e24D1788f39AD35C70f4cc51b4e5898, затем на 0x4f865B9c2b4FB8BdF903E2A8d77c085e81B56E02, где остаются на балансе на момент расследования.
Поддельный houseOfReserve — $8 тыс
Ход инцидента
Дата: 24 марта 2026. Сеть: Base.
Атакующий передал в liquidateUser() поддельный houseOfReserve. Контракт принял его как настоящий, забрал collateral у пользователей и передал его атакующему. Долг при этом фактически не погашался. Затем через настоящий HouseOfReserve.withdraw() атакующий обменял reserve-токены на реальные активы.
Почему это стало возможным
не проверял, что houseOfReserve — это зарегистрированный контракт протокола. Такая проверка есть в
liquidateUser()mintCoin(), но в функции ликвидации её не добавили. Дополнительно арифметика в _computeCostOfLiquidation() позволила сделать стоимость ликвидации равной нулю при положительном объёме изъятого collateral.
Движение средств
Средства поступили на 0xdB731450e065ea7f6Bef6d27e88Dd07D6E2d1AF5, затем переброшены через deBridge в Ethereum на 0x0B97a72CFdb70e61881af1672B19b24326761cD0. Далее средства смешались с другими на 0xba1b0E433EE9C849Ec4aeBAf6e739E14881D8bA3 и остаются на балансе.
Заключение
Оба инцидента демонстрируют: недостаточная валидация входных данных остаётся одной из наиболее распространённых ошибок. Протокол доверяет данным, которые атакующий сам передал, либо считает цену по данным, которые можно исказить в той же транзакции.
Команда КоинКит продолжает мониторинг адресов, связанных с инцидентами.


