За прошедшую неделю (25 января – 1 февраля 2026 г.) компания BlockSec обнаружила и проанализировала шесть инцидентов, связанных с атаками, с общими оценочными убытками около $18.05 млн. В таблице ниже представлены эти инциденты, а подробный анализ каждого случая приводится в следующих подразделах.
| Дата | Инцидент | Тип | Оценочный убыток |
|---|---|---|---|
| 2026/01/25 | Инцидент SwapNet | Ненадлежащая проверка входных данных | ~$13.41 млн |
| 2026/01/25 | Инцидент Aperture Finance | Ненадлежащая проверка входных данных | ~$3.67 млн |
| 2026/01/27 | Инцидент PGNLZ | Уязвимость в дизайне токена | ~$100 тыс. |
| 2026/01/28 | Инцидент XPlayer | Уязвимость в дизайне токена | ~$717 тыс. |
| 2026/01/28 | Инцидент Holdstation | Компрометация ключа | ~$100 тыс. |
| 2026/01/30 | Инцидент Revert Finance | Ошибка бизнес-логики | ~$50 тыс. |
1. Инцидент SwapNet
Краткий обзор
25 января 2026 года протокол SwapNet в сетях Base, BSC и Arbitrum подвергся атаке, что привело к убыткам в размере около $13.41 млн. Инцидент был вызван недостаточной проверкой входных данных от пользователей, что позволило злоумышленнику сформировать вызовы, инициирующие transferFrom() с контролируемыми им параметрами. Злоупотребляя существующими разрешениями на использование токенов (allowances), атакующий фактически выполнял переводы вида token.transferFrom(victim, attacker, amount), что позволило ему вывести одобренные активы жертв.
Предыстория
Протокол SwapNet — это агрегатор DEX, предназначенный для поиска оптимальных маршрутов обмена путем агрегирования ликвидности из нескольких ончейн-источников, включая AMM и частных маркет-мейкеров. Протокол также позволяет пользователям указывать пользовательские маршрутизаторы или пулы при выполнении обменов, обеспечивая дополнительную гибкость.
Анализ уязвимости
Этот инцидент обусловлен недостаточной проверкой входных данных от пользователя, что позволяет атакующему инициировать вызовы transferFrom() с произвольными параметрами. В результате активы, которые ранее были одобрены для контрактов-жертв (например, 0x616000e384Ef1C2B52f5f3A88D57a3B64F23757e), могли быть переведены на адрес злоумышленника.
Судя по декомпилированному байт-коду, в функции 0x87395540() отсутствует надлежащая проверка критических входных данных. Заменяя ожидаемый адрес маршрутизатора или пула на адрес токена (например, USDC), контракт ошибочно воспринимает токен как допустимую цель выполнения. Это приводит к низкоуровневому вызову, выполняемому с calldata, контролируемыми атакующим.
В результате контракт жертвы выполняет вызовы вида: approvedAsset.transferFrom(victim, attacker, amount), позволяя атакующему выкачать все одобренные активы.
Анализ атаки
В отношении SwapNet было замечено несколько атак. Здесь мы используем транзакцию в сети Base 0xc15df1d131e98d24aa0f107a67e33e66cf2ea27903338cc437a3665b6404dd57 в качестве примера. Атакующий просто вызвал функцию 0x87395540() контракта жертвы с вредоносными входными данными. Этот вызов состоит из двух основных шагов.
-
Ключевая внутренняя переменная (например,
v51) была установлена в значениеUSDC, что обошло задуманную логику маршрутизации.
-
Был выполнен низкоуровневый вызов с использованием контролируемых атакующим calldata, что привело к выполнению
USDC.transferFrom()и выводу всех одобренных средств вUSDC.
Заключение
Инцидент вызван недостаточной проверкой входных данных от пользователя; добавление надлежащих проверок параметров ввода в функцию помогло бы предотвратить эту проблему.
2. Инцидент Aperture Finance
Краткий обзор
25 января 2026 года протокол Aperture в сетях Ethereum, Base и Arbitrum подвергся атаке, повлекшей убытки в размере около $3.67 млн. Первопричиной стала недостаточная проверка входных данных, что позволило злоумышленнику инициировать вызовы transferFrom() с произвольными параметрами через внутреннюю функцию 0x1d33(). В результате атакующий смог выполнять вызовы вида approvedToken.transferFrom(victim, attacker, amount), что позволило ему вывести все одобренные активы.
Предыстория
Aperture Finance — это DeFi-протокол, который управляет позициями концентрированной ликвидности (например, Uniswap V3 LP) от имени пользователей. Его контракты с закрытым исходным кодом (например, 0xD83d960deBEC397fB149b51F8F37DD3B5CFA8913) позволяют пользователям создавать и управлять позициями Uniswap V3 с использованием нативных токенов.
Задуманный рабочий процесс для создания позиций Uniswap V3
При создании позиций Uniswap V3 через функцию 0x67b34120() контракт выполняет трехэтапный процесс:
-
Обертывание нативных токенов.
-
Обмен обернутых токенов через внутреннюю функцию
0x1d33(). -
Минтинг позиций UniswapV3.
Проблема возникает на шаге 2: Внутренняя функция 0x1d33() выполняет кастомный обмен с помощью низкоуровневого вызова, где критические параметры (например, цель вызова и calldata), по-видимому, контролируются пользователем и недостаточно проверяются, что открывает возможность для несанкционированных внешних вызовов. Более подробная информация приведена в следующих разделах.
Анализ уязвимости
Инцидент вызван недостаточной проверкой входных данных при низкоуровневых вызовах. Когда вызывается 0x67b34120(), внутренняя функция 0x1d33() выполняет низкоуровневый вызов, используя предоставленные пользователем calldata без строгих ограничений на цель вызова или селектор функции.
Как показано на рисунке ниже, calldata, используемые для запуска низкоуровневого вызова, полностью основаны на входных данных атакующего.
Это позволяет атакующим формировать вредоносные calldata, что приводит к выполнению approvedToken.transferFrom(victim, attacker, amount) в контексте контракта жертвы. В результате могут быть выведены не только токены ERC20, но и одобренные NFT позиций Uniswap V3.
Анализ атаки
В отношении Aperture Finance было замечено несколько атак. В этом разделе мы используем транзакцию в сети Ethereum 0x8f28a7f604f1b3890c2275eec54cd7deb40935183a856074c0a06e4b5f72f25a в качестве показательного примера.
-
Атакующий создал контракт атаки
0x5c92884dFE0795db5ee095E68414d6aaBf398130. -
Контракт атаки вызвал функцию
0x67b34120()с вредоносными входными данными и 100 вей ETH (т.е. msg.value == 100).
- a. Нативные ETH были обернуты в WETH через функцию
WETH.deposit().
- b. Была вызвана внутренняя функция
0x1d33()для выполнения низкоуровневого вызова. На этом шаге выполняется вызовWBTC.transferFrom(victim, attacker, amount)в контексте контракта жертвы, что позволяет атакующему вывести одобренные токены. Стоит отметить, что проверка баланса в конце функции0x1d33()прошла успешно. В частности, функция0x1d33()сравнивала изменения баланса с выходным значением обмена (т.е.varg2.word2), которое также было указано атакующим. В результате операции были выполнены успешно, хотя по факту ничего не было получено.
- c. Наконец, была вызвана функция
NonfungiblePositionManager.mint()для создания позиции для атакующего с использованием 100 вей WETH.
Интересные находки
Сравнивая нормальные и аномальные транзакции минтинга, мы заметили, что в обеих транзакциях токены одобрялись для одного и того же адреса (например, OKX DEX: TokenApprove), но были указаны разные адреса маршрутизаторов (т.е. DexRouter и WBTC). Это предполагает, что контракт может проверять одобрение адреса ("spender"), но не проверяет фактическую цель исполнения, оставляя критическую брешь для произвольных вызовов.
Нормальная транзакция: ссылка на tx1
Аномальная транзакция: ссылка на tx2
Заключение
Инцидент вызван недостаточной проверкой входных данных пользователя. Добавление надлежащих проверок входных данных помогло бы смягчить эту проблему.
3. Инцидент PGNLZ
Краткий обзор
27 января 2026 года пул PancakeSwap V2 USDT–PGNLZ в сети BNB Smart Chain подвергся атаке, что привело к убыткам около $100 тыс. Первопричиной стал ошибочный механизм сжигания в токене PGNLZ, который позволил атакующему сжигать PGNLZ непосредственно с баланса пула. Это искусственно сократило резервы PGNLZ в пуле, создав резкий дисбаланс резервов и исказив цену в блокчейне. Затем атакующий использовал манипулированную цену для выполнения обменов, которые вывели USDT из пула.
Предыстория
Токен PGNLZ представляет механизм сжигания, направленный на пул PancakeSwap V2. Механизм сжигания может быть запущен при определенных условиях. В частности, при каждой покупке в пуле токен проверяет, достиг ли баланс USDT пула заранее определенного порога. Как только порог достигнут, он сжигает определенное количество PGNLZ из пула и устанавливает tradingEnabled = true, позволяя обычным пользователям взаимодействовать с пулом впоследствии. Когда режим торговли включен и пользователь продает PGNLZ в пуле, токен сначала сжигает количество PGNLZ, удерживаемое пулом, основываясь на объеме продажи PGNLZ предыдущим пользователем.
Анализ уязвимости
Основной проблемой был ошибочный механизм сжигания, введенный токеном PGNLZ, который уязвим для атаки с манипулированием ценой. В частности, атакующему разрешено обходить ограничение режима торговли для манипулирования резервами пула (т.е. покупки PGNLZ), установив получателя как адрес isExcludedFromFee (т.е. 0xdEaD). Затем атакующий использует механизм сжигания (через функцию _executeBurnFromLP()), чтобы напрямую сжечь PGNLZ из пула, что еще больше манипулирует резервами пула. В результате атакующий может получать прибыль, выполняя обратный обмен (т.е. продажу PGNLZ) в манипулированном пуле.
Анализ атаки
Следующий анализ основан на транзакции: 0xc7270212846136f3d103d1802a30cdaa6f8f280c4bce02240e99806101e08121
-
Атакующий занял
1.059e18 BTCBчерез флэш-займ в Moolah и занял30,000,000e18 USDT, предоставив1.059e18 BTCBв Venus. -
Атакующий обменял
23,337,952e18 USDTна978,266e18 PGNLZв пуле PancakeSwap V2, когда режим торговли был отключен. Атакующий сделал обмен возможным, установив получателя как0xdEaD, что обошло соответствующие проверки. -
Атакующий обменял ранее полученные
17e18 PGNLZнаUSDTв пуле PancakeSwap V2. Во время этого обмена была запущена функция_executeBurnFromLP(), сжигающая4,240e18 PGNLZиз пула (на основе предыдущего объема продажиPGNLZ). Этот процесс сжигания оставил резерв пула только с0.00000001e18 PGNLZ, еще больше манипулируя резервомPGNLZпула. При истощенном резервеPGNLZатакующий смог вывести23,438,853e18 USDTиз пула, имея всего17e18 PGNLZ. -
Атакующий погасил позицию в Venus и в конечном итоге получил прибыль в размере
100,901e18 USDT.
Заключение
Первопричиной этих инцидентов является ошибочный механизм сжигания PGNLZ, который позволил атакующим вывести USDT из пула путем выполнения атаки с манипулированием ценой. В результате инцидент привел к общим убыткам в размере около $100 тыс. Чтобы смягчить такие проблемы, проект должен реализовать надлежащий контроль доступа внутри системы и провести комплексное тестирование механизма сжигания, чтобы избежать потенциальных атак с манипулированием ценой.
4. Инцидент XPlayer
Краткий обзор
28 января 2026 года пул PancakeSwap V2 XPL/USDT в сети BNB Smart Chain подвергся атаке, что привело к убыткам около $717 тыс. Инцидент был вызван ошибочным механизмом сжигания в токене XPL, который позволил атакующему сжигать XPL непосредственно из баланса пула. Искусственно сократив резервы XPL пула, атакующий создал серьезный дисбаланс резервов и исказил цену обмена, а затем использовал манипулированное ценообразование для вывода USDT из пула.
Предыстория
Токен XPL представляет механизм сжигания, который сжигает токены XPL из соответствующего пула, а затем вызывает функцию sync(), чтобы обновить резервы пула. В частности, в контракте NodeDistributePlus функцию DynamicBurnPool() можно вызывать для выполнения ежедневной задачи сжигания в течение периода исполнения. Объем сжигания не должен превышать остаток дневного лимита сжигания.
Анализ уязвимости
Первопричина этого инцидента кроется в ошибочном механизме сжигания контракта XPL. В частности, функция DynamicBurnPool() в контракте XPL позволяет определенным привилегированным адресам сжигать XPL непосредственно из пары ликвидности.
Одним из таких привилегированных адресов является контракт NodeDistributePlus (т.е. nodeShareAddress), который реализует ежедневный график сжигания. После того, как привилегированная учетная запись устанавливает ежедневную цель сжигания, любой вызывающий может вызвать NodeDistributePlus.DynamicBurnPool() в течение 2-дневного окна до тех пор, пока не будет достигнут дневной лимит сжигания.
В результате такой дизайн позволяет любому сжигать XPL из соответствующего пула и принудительно обновлять резервы. Атакующий может использовать этот дизайн для манипулирования резервами пула и выполнения обратного обмена для вывода USDT из пула.
Анализ атаки
Следующий анализ основан на транзакции: 0x9779341b2b80ba679c83423c93ecfc2ebcec82f9f94c02624f83d8a647ee2e49
-
Атакующий занял около
239,523,169e18 USDTчерез флэш-займы.
-
Атакующий обменял
100e18 USDTна69e18 XPL. Этот шаг синхронизировал резервы пула с текущими балансами.
- Атакующий обменял
217,118,801e18 USDTна около691,022e18 XPL. Этот шаг был тщательно рассчитан, чтобы настроить состояние пула для последующей манипуляции резервами.
- Атакующий вызвал функцию
DynamicBurnPool()для сжигания3,078e18 XPLиз пула. Этот процесс сжигания еще больше манипулировал резервомXPLпула до чрезвычайно малого значения (например, 1 вей).
- Атакующий обменял
69e18 XPLна218,083,490e18 USDTс помощью манипулированных резервов.
- Атакующий погасил флэш-займ и получил прибыль в размере
718,844e18 USDT.
Заключение
Этот инцидент вызван ошибочным механизмом сжигания, который позволяет любому сжигать XPL непосредственно из пула для манипулирования его резервами. В результате такой ошибочный дизайн позволяет атакующим выполнять атаку с манипулированием ценой для вывода ценных активов из пула. Чтобы смягчить подобные проблемы, проекты должны предотвращать произвольное сжигание активов из пула.
5. Инцидент Holdstation
Краткий обзор
28 января 2026 года Holdstation сообщила о взломе, связанном с захватом контролируемого проектом кошелька, с общими оценочными убытками ~$100 тыс. Атакующий вывел несколько активов на сумму ~$66 тыс., включая WLD, USD1, BNB и BERA, в сетях World Chain, BSC, Berachain и zkSync, а затем консолидировал доходы в сети Ethereum в размере около 22.41 ETH, прежде чем перевести их в Bitcoin в размере около 0.755 BTC. Инцидент был связан с компрометацией устройства члена команды, предположительно через вредоносное расширение для IDE или браузера, что позволило захватить кошелек.
Анализ уязвимости
Взлом произошел из-за вредоносного программного расширения, установленного ключевым разработчиком, что представляет собой человеческую ошибку на операционном уровне. В частности, разработчик установил вредоносное и ненадежное расширение IDE/браузера, что привело к компрометации учетной записи и финансовым убыткам.
Анализ атаки
Соответствующие адреса и транзакции мостов перечислены ниже:
Адреса атакующего
0x54e127b8dbf3bebf64bb1d62a195a6f60113130d0x9d3a398cc667b97841a2a92ba808ee8dd368a1f2bc1qykmc6mllm3s4zpldww764v6vcgtqwshyw02k9c
Адреса жертв
- (World Chain)
0xa92e09e0a52b7EdEaD75d3125e21bDFB9752C69e - (World Chain)
0xD768da05e0E6771Ea81b441026CE9355421eF7c9 - (World Chain)
0xA581ED1dEB42E8496E5275468C79D250b91d6a75 - (World Chain)
0x9BD647B2C8Fed689ADd2e7AA8b428d3eD12f75cb - (BSC)
0x2Edf158DDCe35733d6f7D9D7227610ca0531f0AD - (BSC)
0xA581ED1dEB42E8496E5275468C79D250b91d6a75 - (Bera Chain)
0xA581ED1dEB42E8496E5275468C79D250b91d6a75 - (Bera Chain)
0x628cEf732301aDF6d62bB2bcDFeBB291750C4D9a - (zkSync)
0xA581ED1dEB42E8496E5275468C79D250b91d6a75 - (zkSync)
0x8C826F795466E39acbfF1BB4eEeB759609377ba1 - (zkSync)
0x4Cf7baB01b8D3572b3dC08642ebbE2AD1aCF3B99 - (zkSync)
0x2Edf158DDCe35733d6f7D9D7227610ca0531f0AD - (zkSync)
0x2D2D047c50d7828Aedb6A151bA1717766606Bf33
Транзакции через мосты
-
World Chain → Ethereum
- Сумма:
114,308 WLD → 15.317 ETH - Отправитель:
0x54e127b8dbf3bebf64bb1d62a195a6f60113130d - Получатель:
0x54e127b8DBF3BEBf64bB1d62A195A6f60113130d - TXs:
- Сумма:
-
BSC → Ethereum
- Сумма:
10.09 BNB → 2.992 ETH - Отправитель:
0x54e127b8dbf3bebf64bb1d62a195a6f60113130d - Получатель:
0x54e127b8DBF3BEBf64bB1d62A195A6f60113130d - TXs:
- Сумма:
-
BSC → Ethereum
- Сумма:
6,101.6 USD1 → 2.027 ETH - Отправитель:
0x54e127b8dbf3bebf64bb1d62a195a6f60113130d - Получатель:
0x54e127b8DBF3BEBf64bB1d62A195A6f60113130d - TXs:
- Сумма:
-
Berachain → Ethereum
- Сумма:
7,185 BERA → 1.45 ETH - Отправитель:
0x54e127b8dbf3bebf64bb1d62a195a6f60113130d - Получатель:
0x54e127b8dbf3bebf64bb1d62a195a6f60113130d - TXs:
- Сумма:
-
Ethereum → Ethereum
- Сумма:
22.41 ETH → 22.41 ETH - Отправитель:
0x54e127b8dbf3bebf64bb1d62a195a6f60113130d - Получатель:
0x9D3A398cC667B97841a2A92ba808ee8dD368a1f2 - TXs:
- Сумма:
-
Ethereum → Bitcoin
- Сумма:
22.41 ETH → 0.755 BTC - Отправитель:
0x9d3a398cc667b97841a2a92ba808ee8dd368a1f2 - Получатель:
bc1qykmc6mllm3s4zpldww764v6vcgtqwshyw02k9c - TXs:
- Сумма:
Заключение
Первопричиной этого инцидента является компрометация ключа. Ключи администратора, особенно те, которые связаны с ключевыми ролями (например, владельца) в основных контрактах, следует тщательно защищать. Рекомендуется использовать мультисиг-кошельки, чтобы избежать единых точек отказа и повысить системную устойчивость.
6. Инцидент Revert Finance
Краткий обзор
30 января 2026 года Revert Finance в сети Base подвергся атаке, что привело к убыткам около $50 тыс. Первопричиной стала ошибка бизнес-логики в контракте GaugeManager, которая позволила атакующему вывести залог без погашения соответствующего долга. Злоупотребляя executeV3UtilsWithOptionalCompound(), атакующий обошел задуманный поток погашения долга и извлек средства.
Предыстория
Revert Finance — это комплексная платформа с инструментами, предназначенная для поставщиков ликвидности (LP) в Automated Market Maker (AMM). Она в основном предлагает функции анализа, управления, автоматизации и кредитования, помогая LP повысить эффективность капитала и контроль рисков.
В протоколе пользователи могут вносить свои позиции Uniswap v3 в качестве залога для получения активов из кредитных пулов Revert Finance. Кроме того, протокол позволяет пользователям стейкать свои позиции, которые используются в качестве залога, для получения дополнительных вознаграждений через функцию stakePosition().
Анализ уязвимости
Первопричиной инцидента было отсутствие проверки платежеспособности (solvency check) при анстейкинге позиций, используемых в качестве залога. В частности, функция executeV3UtilsWithOptionalCompound() позволяет пользователям анстейкать позицию, указав соответствующую инструкцию (т.е. whatToDo = 1). Однако этой функции не хватает проверки платежеспособности при анстейкинге заложенных позиций. В результате атакующий может выкупить заложенную позицию, не погашая непогашенные долги.
Анализ атаки
Следующий анализ основан на транзакции: 0x10429eaeb479f9149854e4aeb978a35ac02d9688f6e22371712b3878c63a64ab
-
Атакующий занял
10e8 cbBTCи10,000,000e6 USDCчерез флэш-займ, чтобы создать позицию (т.е. NFT). -
Атакующий заложил NFT и взял в долг
49,000e6 USDC. -
Атакующий застейкал заложенный NFT через функцию
stakePosition(). -
Атакующий мгновенно анстейкал заложенный NFT с помощью функции
executeV3UtilsWithOptionalCompound(). Заложенная позиция была сожжена, а соответствующие базовые активы были собраны атакующим. Из-за отсутствия проверки платежеспособности в процессе анстейкинга заложенная позиция была сожжена без погашения соответствующих долгов.
- Атакующий погасил флэш-займ и получил прибыль в размере
49,000e6 USDC.
Заключение
Первопричиной инцидента является отсутствие проверки платежеспособности при анстейкинге заложенных позиций. Этот инцидент подчеркивает важность проверок платежеспособности в кредитных протоколах. Внедрение надежных мер проверки платежеспособности для каждого использования позиции необходимо для обеспечения стабильности и надежности.
Список литературы
[1] SwapNet & Aperture https://blocksec.com/blog/17m-closed-source-smart-contract-exploit-arbitrary-call-swapnet-aperture
[2] PGNLZ: https://x.com/Phalcon_xyz/status/2016154398817505595
[3] XPlayer: X Player Official https://x.com/XPlayer_Media/status/2016700861578403910
[4] XPlayer: X Blocksec Phalcon https://x.com/Phalcon_xyz/status/2016521384609067103
[5] Holdstation: https://x.com/Phalcon_xyz/status/2016823122373296583
[6] Revert Finance: https://paragraph.com/@revertfinance/post%E2%80%91mortem-aerodrome-lend-vault-incident-on-base?referrer=0x8cadb20A4811f363Dadb863A190708bEd26245F8
О компании BlockSec
BlockSec — это полнофункциональный поставщик решений для безопасности блокчейнов и крипто-комплаенса. Мы создаем продукты и услуги, которые помогают клиентам проводить аудит кода (включая смарт-контракты, блокчейны и кошельки), перехватывать атаки в режиме реального времени, анализировать инциденты, отслеживать незаконные средства и соблюдать требования AML/CFT на протяжении всего жизненного цикла протоколов и платформ.
BlockSec опубликовала множество статей по безопасности блокчейнов на престижных конференциях, сообщила о нескольких атаках нулевого дня на DeFi-приложения, заблокировала множество хакерских атак, спасая более 20 миллионов долларов, и обеспечила безопасность криптовалют на миллиарды долларов.
-
Официальный сайт: https://blocksec.com/
-
Официальный аккаунт в Twitter: https://twitter.com/BlockSecTeam
