Web3 августовский отчет о безопасности: 29 основных инцидентов, общие убытки превышают 68,29 миллиона долларов

В августе 2026 года основными причинами серьезных инцидентов безопасности стали уязвимости контрактов, среди которых 18 инцидентов связано с уязвимостями контрактов/сетей, 2 инцидента связаны с утечкой приватных ключей. Безопасность смарт-контрактов и управление приватными ключами по-прежнему остаются слабыми местами в безопасности Web3.

Автор: Beosin

Согласно данным мониторинга платформы Beosin Alert, в августе 2026 года общая сумма убытков от различных инцидентов безопасности составила около 76,15 миллиона долларов, произошло 29 серьезных инцидентов безопасности, основными причинами которых стали уязвимости контрактов. Из них 18 инцидентов связаны с уязвимостями контрактов/сетей, 2 инцидента связаны с утечкой приватных ключей. Безопасность смарт-контрактов и управление приватными ключами по-прежнему остаются слабыми местами в безопасности Web3.

Топ-10 убытков в августе

13 августа личный адрес пользователя 0x13e3....179e был взломан из-за утечки приватного ключа, в результате чего были украдены криптоактивы WBTC, cbBTC, LDO, USDS, CRV на общую сумму около 25,6 миллиона долларов, что является самым крупным инцидентом по фактическим убыткам. 30 августа кредитный протокол Tectonic на сети Cronos подвергся хакерской атаке из-за уязвимости контракта, ожидаемые убытки составили около 74 миллионов долларов. Эта атака привела к тому, что сеть Cronos приняла экстренные меры, приостановила работу сети и откатила транзакции, хакер в конечном итоге успешно перевел около 6 миллионов долларов на сеть Ethereum через кросс-цепочную транзакцию.

Кроме того, из-за уязвимости в публичной цепочке Harmony было дополнительно выпущено около 4 миллиардов токенов ONE, номинальные убытки составили более 4 миллионов долларов, но в конечном итоге статус поддельных токенов был устранен путем отката транзакций, поэтому убытки не учитываются.

Типы атакованных проектов и убытки по цепочкам

В этом месяце атакованные объекты охватывают различные типы, включая публичные цепочки, кредитные протоколы, приложения для кошельков, токеновые контракты, кросс-цепочные мосты и обычных пользователей. При этом проекты DeFi понесли наибольшие убытки, составившие 33,09 миллиона долларов; личные адреса из-за утечки приватных ключей или фишинга понесли убытки около 28,4 миллиона долларов. Контракты токенов подвергались атакам чаще всего, всего 10 раз; контракты DeFi подвергались атакам 9 раз, занимая второе место.

Цепочка с наибольшими убытками в мае - Ethereum, убытки составили более 48,58 миллиона долларов, всего 15 инцидентов безопасности. В настоящее время большинство атак на DeFi-протоколы и фишинг на крупных держателей по-прежнему сосредоточены на Ethereum. Цепочка с наибольшим количеством инцидентов безопасности после Ethereum - BNB Chain, но цели атак в основном были токеновые контракты, убытки были небольшими. Кроме того, в публичных цепочках Cronos, Base, Harmony, Bitcoin, Solana также произошли инциденты безопасности, что указывает на многоцепочечную природу атак.

Анализ основных инцидентов безопасности

1. Tectonic и Moonwell: манипуляция ценами

Tectonic и Moonwell - это кредитные протоколы на цепочке, причиной атак стало манипулирование ценами некоторых токенов с низкой ликвидностью, что позволило занять активы по завышенной стоимости. В атаке на Tectonic злоумышленник увеличил цену токена управления Tectonic $TONIC в 100 раз, получив кредитный лимит около 74 миллионов долларов, затем занял активы, такие как USDT. После инцидента сеть Cronos экстренно приостановила работу всей цепи, злоумышленник до приостановки сети перевел около 6 миллионов долларов на Ethereum. Затем сеть Cronos провела откат, чтобы вернуть убытки.

Адрес хакера на Ethereum: 0xc404160B79BD8905061a1cAecBeCa2EEab3f72DD и направление украденных средств:

В настоящее время около 2659 ETH все еще хранится на 0xc4041, 140,1 ETH было переведено на 0x6df89c42f0abdfaa2b5b77edcdafbc945ed6ee6c и затем продолжает распределяться на несколько вновь созданных адресов.

Moonwell же пострадал из-за того, что злоумышленник манипулировал ценой токена MAMO с низкой ликвидностью, заняв cbBTC, убытки составили около 8,7 миллиона долларов:

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

2. Harmony: атака повторного воспроизведения

Harmony - это Layer 1, поддерживающий шардирование, работающий с четырьмя шардированными цепями и использующий асинхронный механизм кросс-шардирования на основе квитанций для перемещения активов между ними. Исходная шардированная цепь генерирует зашифрованные квитанции для исходящих транзакций, а целевая шардированная цепь отвечает за проверку этих квитанций и их Merkle-доказательства перед записью транзакции, причем каждая квитанция может использоваться только один раз.

Уязвимость в этой атаке существовала в наследственной части системы шардирования Harmony. Ранее Harmony проверял, использовались ли квитанции шардирования, проверяя два поля CXMerkleProof.ShardID и BlockNum,

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

Это типичная атака повторного воспроизведения. Для любых полей, используемых в качестве «однократных меток», они должны быть частью подписанного заголовка. При проверке квитанций следует считывать Shard ID и номер блока непосредственно из уже подписанного заголовка блока, а не доверять неподтвержденным полям в структуре доказательства.

3. Term Finance: атака на управление

Term Finance - это протокол DeFi с фиксированной процентной ставкой, каждый из его хранилищ (Vault) является ERC-4626 Vault на основе кода Yearn V3. Однако управление хранилищем Term Finance не основано на голосовании за одобрение, а на голосовании против. Когда куратор предлагает изменения параметров, управляющие открывают окно, в котором LP-токенодержатели могут высказывать свои возражения. Однако в настройках голосования управления есть серьезные уязвимости:

● Отсутствие абсолютного порога голосов или капитала: условия, при которых предложение проходит, isSupportThresholdReached() и isMinParticipationReached(), проверяют только относительные пропорции, а не абсолютное количество голосов. Это означает, что как только будет достигнуто относительное большинство, предложение может быть принято, независимо от общего числа голосующих или общего объема капитала.

● Очень низкий уровень участия: почти ни один вкладчик не конвертировал долю хранилища (tmvETH) в токены управления (gtmvETH) для участия в голосовании. Это привело к тому, что общее предложение токенов управления соответствующего хранилища было крайне низким.

Злоумышленник использовал вышеупомянутые проектные недостатки, чтобы осуществить атаку на управление хранилищем с очень низкими затратами:

(1) Получение прав голоса: злоумышленник обменял около 0,5 ETH на около 0,485 доли хранилища tmvETH и конвертировал ее 1:1 в 0,485 токена управления gtmvETH, получив права голоса.

(2) Инициирование злонамеренного предложения: при создании предложения контракт зафиксировал общее предложение токенов управления на тот момент всего 0,535 gtmvETH. Это означает, что 0,485 gtmvETH, принадлежащие злоумышленнику, составляют 90,66% от общего объема.

(3) Голосование и выполнение: злоумышленник, будучи единственным голосующим, подал голос «за». Поскольку не было голосов против, его поддержка значительно превышала порог в 50%; кроме того, его личные права голоса также превышали минимальный порог участия, рассчитанный на основе крайне низкого общего предложения (minVotingPower).

(4) Извлечение активов: после принятия предложения была выполнена злонамеренная операция, в результате которой активы из хранилища (WETH) были извлечены.

Злоумышленник использовал ту же тактику, чтобы атаковать 6 хранилищ Term Finance, что привело к убыткам около 8,5 миллиона долларов.

Эта атака также является типичной атакой на управление протоколом на цепочке. Для управления на цепочке проектные команды должны установить следующие контрольные точки для предотвращения:

● Установить абсолютный порог голосов или капитала: предложения по управлению не могут полагаться только на относительные пропорции. Необходимо установить жесткий порог на основе абсолютного количества, например, требовать, чтобы количество голосов «за» достигало определенной суммы (например, 1 миллион долларов) или количества независимых адресов.

● Оснастить временные замки опекунами или путями отмены: хотя выполнение управления обычно задерживается, это лишь сохраняет определенное время для реакции. Проектные команды должны обеспечить эффективный механизм опеки (Guardian) или путь отмены предложений на период задержки выполнения. Если в течение этого периода будет обнаружено злонамеренное предложение, опекун может немедленно вмешаться и отменить его.

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

Тенденции угроз безопасности Web3

В 2026 году безопасность Web3 демонстрирует глубокую тенденцию к систематическому расширению атак. Уязвимости возникают одновременно на уровне кода, в повседневной эксплуатации и взаимодействии, и полагаться только на несколько аудитов безопасности или инструменты недостаточно для охвата операционной безопасности, управления на цепочке, логики коммерческой деятельности и других аспектов. Это ставит новые вызовы перед проектными командами Web3 в построении систем безопасности.

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