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. Ланцюг з другим за кількістю інцидентів безпеки - 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 зазнала збитків приблизно на 8,7 мільйона доларів через маніпуляцію зловмисника ціною недостатньої ліквідності токена MAMO для отримання cbBTC:

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

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

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

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

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

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

3. Term Finance: атака на управління

Term Finance - це протокол DeFi з фіксованою процентною ставкою, кожен його фонд (Valut) є 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 та особистих користувачів. Вразливості контрактів або авторизації легко використовуються зловмисниками, розробники або оператори контрактів повинні повторно перевірити безпеку контрактів, а для контрактів, що обробляють основний бізнес, слід провести кілька, багатосторонніх аудиторських перевірок. Щодо особистих користувачів, слід регулярно використовувати блокчейн-браузери або інструменти для скасування авторизацій, щоб перевіряти та скасовувати непотрібні авторизації контрактів, а також більше дізнаватися про поширені та нові методи фішингу, підвищуючи обізнаність про безпеку.