Звіт безпеки Web3 за серпень: 29 серйозних інцидентів, втрачено понад $68,29 млн

За даними платформи Beosin Alert, у серпні 2026 року загальні втрати від різних інцидентів безпеки склали приблизно 76,15 мільйона доларів США, відбулося 29 серйозних інцидентів безпеки, основною причиною яких були вразливості в контрактах. Серед них 18 інцидентів були пов’язані з вразливостями в контрактах/мережі, 2 інциденти — з витоком приватних ключів; безпека розумних контрактів та управління приватними ключами залишаються слабкими місцями в безпеці Web3.

13 серпня особистий адресний кошик 0x13e3....179e черезутік приватного ключабуло вкрадено криптоактиви WBTC, cbBTC, LDO, USDS, CRV тощо, загальна втрата становить близько 25,6 мільйона доларів США — це найбільший реальний збиток у безпековому інциденті. 30 серпняCronos мережа, позичальний протокол Tectonic, зазнав хакерської атаки через вразливість у контракті, очікувані збитки становлять близько 74 мільйонів. Ця атака спричинила екстрені заходи з боку мережі Cronos — призупинення мережі та відкат транзакцій, після чого хакер успішно перевів близько 6 мільйонів доларів США наEthereum мережу.

Крім того, через вразливість у ланцюжку Harmony було додатково відлито приблизно 4 мільярди токенів ONE, номінальна втрата становила понад 4 мільйони доларів США, але нарешті фальшиві токени були видалені шляхом відкоту транзакцій, тому вони не враховувалися у збитках.

У цьому місяці об’єктами атак були блокчейни, протоколи позичання, гаманці, контракти токенів, мостові з’єднання та звичайні користувачі. Найбільші втрати зафіксовано у DeFi-проектах — 33,09 мільйона доларів США; особисті адреси втратили приблизно 28,4 мільйона доларів США через витік приватних ключів або фішинг. Контракти токенів були атаковані найчастіше — 10 разів; контракти DeFi зайняли друге місце з 9 атаками.

Найбільші втрати за травень зафіксовано на Ethereum — понад 48,58 мільйона доларів США, загалом 15 інцидентів безпеки. Наразі більшість атак на DeFi-протоколи та фішингові атаки на великих гравців зосереджені саме на Ethereum. Другим за кількістю інцидентів є BNB Chain, але основними цілями тут є токен-контракти, і втрати в цьому випадку менші. Крім того, інциденти безпеки відбувалися також на Cronos, Base, Harmony, Bitcoin, Solana та інших публічних блокчейнах — атаки стають багатоланковими.

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

Tectonic та Moonwell — це протоколи позичання на ланцюзі, які були атаковані через маніпулювання цінами активів із низькою ліквідністю, що дозволило отримати надмірне позичання за завищеною вартістю активів. У атаках на Tectonic атакувачі підвищили ціну治理-токена протоколу $TONIC у 100 разів, отримавши кредитний ліміт у розмірі близько 74 мільйонів доларів США, а потім позичили активи, такі як USDT. Після інциденту мережа Cronos негайно призупинила генерацію блоків усієї мережі, а атакувачі переказали приблизно 6 мільйонів доларів США на Ethereum до призупинення мережі. Пізніше мережа Cronos виконала відкат, щоб відновити збитки.

Хакерський ефірний адреса отримання прибутку: 0xc404160B79BD8905061a1cAecBeCa2EEab3f72DD та напрямок потоку вкрадених коштів:

Зараз близько 2659 ETH зберігаються у 0xc4041, 140,1 ETH було переведено до 0x6df89c42f0abdfaa2b5b77edcdafbc945ed6ee6c, після чого продовжено розподіл на кілька новостворених адрес.

Moonwell втратив приблизно 8,7 мільйона доларів США через те, що нападник маніпулював ціною MAMO, токена з недостатньою ліквідністю, щоб позичити cbBTC:

Ці дві атаки не були зумовлені вразливостями смарт-контракту, а виникли через те, що протокол визначав вартість забезпечення на основі слабкої ліквідності спот-ринку, неправильно розрахувавши вартість забезпечення. Щоб уникнути таких атак, протокол може отримувати дані від кількох оракулів з різних джерел і додатково аналізувати ситуації різких коливань цін.

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

Harmony — це Layer 1 з підтримкою шардінгу, яка працює з чотирма шардами і переносить активи між ними за допомогою асинхронного механізму, заснованого на квитанціях. Вихідний шард генерує криптографічні квитанції для вихідних транзакцій, а цільовий шард перевіряє цю квитанцію та її доказ Merkle на відповідність підписаному заголовку вихідного блоку перед фіксацією транзакції, причому кожна квитанція може бути використана лише один раз.

Вразливість, використана в цій атакі, знаходиться в залишкових частинах системи фрагментації Harmony. Раніше Harmony перевіряла, чи була використана фрагментована квитанція, шляхом перегляду двох полів: CXMerkleProof.ShardID і BlockNum.

Оскільки ці два поля розташовані поза підписаним заголовком блоку, зловмисник може змінити їх, не порушивши жодної існуючої функціональності. У цій атакі зловмисник отримав міжшаровий чек і змінив у ньому ShardID і BlockNum, щоб перевірочна програма сприйняла його як новий чек. Цільовий шар прийняв змінений чек і зарахував його знову, тоді як початковий шар не зменшив відповідні активи.

Це дуже типовий атака відтворення. Для будь-якого поля, що використовується як «мітка одноразового використання», воно має бути частиною підписаного заголовка. Під час перевірки квитанції ідентифікатор фрагмента та номер блоку слід отримувати безпосередньо з підписаного заголовка блоку, а не довіряти непідтвердженим полям у структурі доказу.

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) або шлях відміни пропозиції під час періоду затримки. Якщо під час затримки виявлено зловмисну пропозицію, опікун може втрутитися та відмінити її негайно.

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

Тренди веб-3 безпеки

Найглибшою тенденцією у безпеці Web3 у 2026 році є систематичне розширення поверхні атак. Уразливості виникають одночасно на рівні коду, щоденних операцій та взаємодій, і лише кілька перевірок безпеки чи інструментів не можуть охопити безпеку операцій, ланцюгове управління та вразливості у бізнес-логіці. Це ставить перед проектами Web3 нові виклики щодо побудови системи захисту.

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

Цей текст було написано командою безпеки Beosin на основі системи попереджень Beosin Alert, блокчейн-даних та публічного аналізу подій від команди проекту. Якщо у вас виникнуть будь-які питання, будь ласка, зв’яжіться з нами для зворотного зв’язку.