Маловідомий інструмент ШІ з відкритим кодом попередив про вразливість Kelp DAO на $292 мільйони за 12 днів до інциденту

Оригінальна назва: Злам Kelp DAO на $292 млн: що ШІ-агент виявив за 12 днів до події — і що це означає для безпеки DeFi

Оригінальне джерело: Блог Zengineer
Оригінальний переклад: DeepTide TechFlow

Резюме DeepTide: 18 квітня Kelp DAO зазнав зламу на суму $292 мільйони, що стало найбільшим інцидентом у сфері DeFi у 2026 році. Вразливість була не в коді смарт-контракту, а в налаштуваннях вузла верифікації 1-з-1 кросчейн-мосту LayerZero — це єдина точка відмови, яка дозволила підробляти кросчейн-повідомлення.

Автор вказав на цю вразливість за 12 днів до інциденту під час сканування Kelp за допомогою власного інструменту аудиту на базі ШІ. У цій статті відтворюється процес атаки, а також міститься відверта рефлексія щодо трьох моментів, які інструмент на той час не врахував.

Що таке Kelp DAO

Kelp DAO — це протокол ліквідного рестейкінгу, побудований на базі EigenLayer. Механізм працює так: користувачі вносять ETH або токени ліквідного стейкінгу (stETH, ETHx) у контракт Kelp, який потім делегує активи операторським вузлам EigenLayer для рестейкінгу, забезпечуючи безпеку через численні сервіси, що активно валідуються (AVS). Натомість користувачі отримують rsETH як підтвердження частки.

На відміну від прямого стейкінгу на EigenLayer (де активи заблоковані), rsETH є ліквідним — його можна продавати, використовувати як заставу в таких протоколах, як Aave, а також використовувати в кросчейн-операціях.

Для досягнення такої кросчейн-ліквідності Kelp розгорнув rsETH у понад 16 мережах, використовуючи стандарт Omnichain Fungible Token (OFT) від LayerZero. Коли ви переносите rsETH з Ethereum у певну мережу L2, децентралізована мережа верифікаторів (DVN) LayerZero перевіряє, чи є це кросчейн-повідомлення легітимним. Ця архітектура мосту є ключовою для подій, що відбулися.

Kelp, заснований Амітеджем Гаджаллою та Діраджем Боррою (колишніми співзасновниками Stader Labs), був запущений у грудні 2023 року і досяг пікового показника TVL у $20,9 мільярда. Управління здійснюється через мультипідпис 6/8 та 10-денну затримку (timelock) для оновлення контрактів. Керуючий токен KERNEL контролює продуктові лінійки Kelp, Kernel та Gain.

Інцидент із крадіжкою

18 квітня 2026 року зловмисник вивів 116 500 rsETH із кросчейн-мосту Kelp DAO на суму приблизно $2,92 мільярда — це найбільший злам у DeFi у 2026 році на сьогодні. Першопричиною стала не вразливість смарт-контракту, а проблема конфігурації: налаштування DVN 1-з-1 (означає лише 1 вузол-валідатор, де консенсус досягається одним підписом), що дозволило зловмиснику підробляти кросчейн-повідомлення через один скомпрометований вузол.

За 12 днів до цього, 6 квітня, мій інструмент аудиту безпеки з відкритим кодом уже позначив цей вектор атаки.

Почнемо з головного: ця крадіжка призвела до того, що реальні люди втратили реальні гроші. Кошти вкладників WETH на Aave, які ніколи не взаємодіяли з rsETH, були заморожені; постачальники ліквідності (LP) у багатьох протоколах зіткнулися з дефолтами, на які вони не погоджувалися. Ця стаття аналізує те, що сталося, і що виявив наш інструмент, але реальні збитки для людей значно вагоміші за будь-які показники.

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

46 хвилин, що сколихнули DeFi

18 квітня о 17:35 UTC зловмисник скомпрометував цей ізольований вузол валідації DVN і змусив його «схвалити» підроблене кросчейн-повідомлення. Ендпоінт LayerZero побачив підтвердження DVN, передав повідомлення через lzReceive до контракту OFT Kelp — контракт виконав запит, випустивши 116 500 rsETH у мережі Ethereum. Повідомлення стверджувало, що еквівалентні активи були заблоковані в інших мережах як застава. Насправді цих активів ніколи не існувало.

Далі відбувся стандартний процес відмивання грошей у DeFi:

1. Депозит вкрадених rsETH як застави в Aave V3, Compound V3, Euler

2. Позика WETH на суму близько $236 мільйонів під цю незабезпечену заставу

3. Збір близько 74 000 ETH, виведення через Tornado Cash

О 18:21, через 46 хвилин, мультипідпис екстреної зупинки Kelp заморозив контракт. Зловмисник двічі намагався випередити систему (по 40 000 rsETH кожен раз, близько $100 мільйонів), але обидві транзакції були скасовані — це дозволило заблокувати ще близько $200 мільйонів.

Однак наслідки були жахливими. Aave V3 зазнав дефолтів на суму близько $177 мільйонів. Токен AAVE впав на 10,27%. ETH знизився на 3%. Коефіцієнт використання WETH на Aave миттєво досяг максимуму в 100%, оскільки вкладники поспішали вивести кошти. rsETH у понад 20 мережах L2 за одну ніч перетворилися на активи сумнівної вартості.

Висновки звіту від 6 квітня

На початку квітня, невдовзі після крадіжки $285 мільйонів у Drift Protocol 1 квітня, я створив open-source навичку для Claude Code — crypto-project-security-skill — архітектурну систему оцінки ризиків за допомогою ШІ, яка аналізує DeFi-протоколи, використовуючи публічні дані (DeFiLlama, GoPlus, Safe API, ончейн-верифікацію). Це не сканер коду чи інструмент формальної верифікації.

Інцидент із Drift змусив мене усвідомити: головна причина найбільших втрат криється не в коді смарт-контрактів, а у вразливостях управління, прорахунках у конфігурації, архітектурних «сліпих зонах» — сферах, невидимих для сканерів коду. Як наслідок, я розробив інструмент спеціально для оцінки цих рівнів: структури управління, залежності від оракулів, економічних механізмів, кросчейн-архітектури, порівнюючи кожен протокол із шаблонами атак відомих історичних інцидентів (Drift, Euler, Ronin, Harmony, Mango).

6 квітня я провів комплексний аудит Kelp DAO. Повний звіт доступний публічно на GitHub із незмінною міткою часу коміту.

Загальний бал оцінки, наданий Kelp, становить 72/100 (середній ризик). Озираючись назад, цей бал був занадто м'яким — кілька кросчейн-прогалин в інформації мали б знизити оцінку. Але навіть при рейтингу «середнього ризику» звіт висвітлив поверхню атаки, яка згодом була використана.

На скріншоті нижче показано оригінальний текст розділу звіту «Інформаційна прогалина» — про проблему з конфігурацією DVN у Kelp, що зрештою призвело до крадіжки $292 мільйонів:

Розділ звіту «Інформаційна прогалина» від 6 квітня прямо вказував на відсутність прозорості в конфігурації DVN

Нижче наведено порівняння кожного позначеного пункту у звіті з тим, як саме відбувся злам.

Виявлення 1: Непрозора конфігурація DVN (раннє попередження)

Текст звіту: «Конфігурація LayerZero DVN (набори валідаторів для кожної мережі, вимоги до порогу) публічно не розкрита»

Що сталося насправді: Kelp використовував конфігурацію DVN 1-з-1. Один вузол. Одна точка. Скомпрометувавши цей єдиний вузол, зловмисник підробив кросчейн-повідомлення. Якби конфігурація була 2-з-3 (рекомендований галузевий мінімум), зловмиснику довелося б зламати кілька незалежних валідаторів одночасно.

Давайте прояснимо: це проблема Kelp, а не LayerZero. LayerZero — це інфраструктура, вона надає фреймворк DVN, а кожен протокол обирає свою конфігурацію: скільки вузлів-валідаторів (1-з-1, 2-з-3, 3-з-5...), чиї вузли використовувати та поріг для кожної мережі. При розгортанні мосту OFT Kelp обрав 1-з-1. LayerZero повністю підтримує 2-з-3 або вище — це власне рішення Kelp не використовувати це.

Наприклад: AWS пропонує MFA (багатофакторну автентифікацію). Якщо ваш акаунт скомпрометовано, тому що ви ніколи не вмикали MFA, це ваша проблема, а не AWS. LayerZero має необхідні заходи безпеки, але Kelp їх не використав.

На момент складання звіту ми не могли визначити конкретний поріг DVN (оскільки Kelp ніколи його не розкривав), але ми чітко вказали на цю відсутність прозорості як на невирішену інформаційну прогалину та пункт ризику. Сама по собі відсутність розкриття інформації є «червоним прапорцем».

Виявлення 2: Єдина точка відмови в 16 мережах (пряме влучання)

Оригінальний звіт: «Єдина точка відмови LayerZero DVN, що потенційно впливає на 16 мереж, які підтримують rsETH ончейн.»

Що сталося насправді: Підроблене повідомлення безпосередньо вразило основну мережу Ethereum, спричинивши ефект доміно в усіх мережах, де розгорнуто rsETH. LayerZero завчасно призупинив усі вихідні мости OFT з Ethereum. Власники rsETH у понад 20 мережах L2 за одну ніч опинилися в ситуації, коли не знали, чи забезпечені їхні токени.

Це демонструє системний ризик мультичейн-розгортання: rsETH циркулює в багатьох L2, таких як Arbitrum, Optimism, Base та Scroll, але вартість усіх цих токенів походить від активів у мережі Ethereum. Оскільки міст основної мережі було скомпрометовано, rsETH у кожній L2 одночасно втратив забезпечення — власники не могли здійснити обмін і не могли перевірити, чи їхні токени все ще мають цінність. earnETH від Lido (що має експозицію на rsETH) та міст LayerZero від Ethena — обидва були змушені зупинити роботу. Радіус ураження вийшов далеко за межі самого Kelp.

Виявлення 3: Неперевірений кросчейн-контроль управління (супутня проблема)

Оригінальний звіт: «Неперевірений контроль управління над конфігураціями LayerZero OFT у різних мережах — зокрема, чи належить цей контроль тому самому мультипідпису 6/8 та 10-денній затримці, чи він керується незалежними ключами адміністратора.»

Що сталося насправді: Конфігурація DVN, очевидно, не підпадає під суворе управління основного протоколу. Якби зміни конфігурації мосту також регулювалися мультипідписом 6/8 та 10-денною затримкою, налаштування DVN 1-з-1 вимагало б згоди 6 із 8 підписантів — така конфігурація навряд чи залишилася б без нагляду.

Це викриває поширену «сліпу зону» управління: хоча багато протоколів мають суворі налаштування мультипідпису та затримки для оновлення основних контрактів, операційні зміни — такі як конфігурації мостів, параметри оракулів та управління білими списками — часто покладаються на єдиний ключ адміністратора. Управління основним протоколом Kelp є найкращим у своєму класі (мультипідпис 6/8 + 10-денна затримка), але ці засоби захисту не поширюються на найбільшу поверхню атаки: кросчейн-мости.

Виявлення 4: Відповідність шаблону атаки Ronin/Harmony (пряме влучання)

Оригінальний звіт: «Найбільш релевантний історичний прецедент стосується безпеки мостів. Розгортання LayerZero у Kelp у 16 мережах створило операційну складність, подібну до мультичейн-архітектури Ronin.»

Що сталося насправді: Шлях атаки майже ідеально повторив сценарій Ronin — злам валідаторів мосту, підробка повідомлень і виведення активів. Модуль зіставлення шаблонів атак нашого інструменту порівняв архітектуру протоколу з категоріями історичних атак, правильно визначивши це як вектор атаки з найвищим ризиком.

Історичний контекст: У 2022 році міст Ronin зазнав збитків у $625 мільйонів через злам 5 із 9 валідаторів; того ж року міст Horizon від Harmony втратив $100 мільйонів через злам 2 із 5 валідаторів.

Ситуація з Kelp була ще екстремальнішою — лише 1 валідатор, що знизило поріг атаки до абсолютного мінімуму. Причина, чому інструмент зміг позначити цей ризик, полягає в тому, що він автоматично порівнює архітектуру протоколу з цими історичними шаблонами атак, а не просто перевіряє код.

Виявлення 5: Відсутність страхового пулу (посилення збитків)

Оригінальний звіт: «Протокол наразі не має виділеного страхового пулу, а також механізму соціалізованого поглинання збитків для покриття подій конфіскації.»

Що сталося насправді: Через відсутність страхового резерву збитки у $292 мільйони були повністю поглинуті наступним протоколом. Резерв відновлення Aave покрив лише 30% дефолту на $177 мільйонів. Постачальники ліквідності, не пов'язані з конфігурацією мосту Kelp, прийняли на себе основний удар.

Зловмисник використав вкрадені rsETH як заставу, вніс їх у Aave V3, Compound V3 та Euler, а потім позичив реальні WETH. Як тільки rsETH було підтверджено як незабезпечені, ці позиції стали «неповоротними» дефолтами — застава перетворилася на папір, а позичені WETH уже зникли. Використання WETH на Aave миттєво досягло максимуму, не даючи навіть звичайним користувачам вивести кошти. Якщо ви є вкладником WETH на Aave, навіть якщо ви ніколи не торкалися rsETH, ваші кошти постраждали. Страхове партнерство між Kelp та Nexus Mutual покривало лише специфічні казначейські продукти, а не основну експозицію протоколу rsETH.

Це випадок, коли обидві сторони не виконали свої обов'язки. З боку Kelp: протокол із TVL $1,3 мільярда, нульовим страховим пулом і нульовим механізмом поглинання збитків. Коли міст було скомпрометовано, не було буфера для поглинання шкоди. З боку Aave: прийняття rsETH як застави без належної оцінки ризику конфігурації кросчейн-мосту.

Параметри ризику Aave (LTV, поріг ліквідації) були розроблені для звичайних коливань цін, але не враховували хвостовий ризик сценарію «компрометація конфігурації мосту, що призводить до знищення застави». Навіть резерв відновлення у 30% не може покрити такий сценарій. По суті, це був провал ціноутворення ризиків: Aave ставився до rsETH як до звичайного активу, що коливається, але насправді він ніс бінарний хвостовий ризик відмови мосту. Провали з обох сторін посилилися — Kelp не мав страховки, щоб запобігти потраплянню поганої застави в систему, а Aave не провів достатньо детального моделювання ризиків, щоб обмежити експозицію в цьому сценарії.

Де ми припустилися помилок

Три речі можна було зробити краще:

Недооцінка рейтингу ризику. Ми оцінили ризик кросчейн-мосту як «середній». З 5 невирішених інформаційних прогалин у звіті 3 стосувалися конфігурації мосту LayerZero, що збігалося з історичним шаблоном атаки Ronin/Harmony — це мало бути оцінено як «високий» або «критичний». Сама по собі непрозорість мала бути сильнішим сигналом.

Ми не змогли проникнути на рівень конфігурації. Звіт неодноразово просив Kelp розкрити поріг DVN, але ми не могли перевірити це незалежно. Це та сама структурна «сліпа зона», на яку вказує аналіз The Block після інциденту: існуючі інструменти аудиту зосереджуються на логіці коду і пропускають ризики на рівні конфігурації. Ми позначили проблему, але не змогли дати відповідь.

Ми не перевірили ончейн. Конфігурацію DVN насправді можна було прочитати ончейн безпосередньо через контракт EndpointV2 від LayerZero. Ми могли б зробити запит до реєстру ULN302, щоб незалежно підтвердити поріг DVN Kelp, замість того, щоб позначати його як «нерозкритий». Якби ми перевірили тоді, ми б безпосередньо побачили конфігурацію 1-з-1 без потреби в розкритті інформації від Kelp. Це найбільш конкретний напрямок покращення для інструментів: додавання ончейн-верифікації конфігурації DVN до процесу оцінки кросчейн-ризиків.

Виявлення було недостатньо конкретним і недостатньо дієвим. Фраза «конфігурація DVN не розкрита» була спостереженням прогалини в документації, а не прогнозуванням атаки. Ці ризики (централізація оракулів, залежність від мостів, відсутність страхування) насправді однаково поширені в більшості кросчейн-DeFi протоколів. Інструмент позначив непрозорість Kelp, але він також позначив подібні шаблони в десятках протоколів, які не були атаковані. Без розкриття рівня хибнопозитивних результатів твердження «ми це передбачили» є перебільшенням фактів. Більш чесним твердженням було б: ми поставили кілька правильних запитань, які ніхто інший не ставив, і одне з них випадково торкнулося критичної слабкої точки.

Про «відповідальне розкриття»

Справедливе запитання: якщо ми визначили ці ризики 6 квітня, чому ми не повідомили Kelp до атаки 18 квітня?

Жодного повідомлення. Причина в тому, що звіт виявив непрозорість — «Конфігурація DVN не розкрита», а не конкретну вразливість, яку можна експлуатувати. Ми не знали, що конфігурація була 1-з-1, лише те, що вона не була публічною. Не було нічого достатньо конкретного для розкриття. «Ваша конфігурація мосту не задокументована» було спостереженням за управлінням, а не звітом, придатним для подання в програму винагород за знайдені помилки (bug bounty).

Озираючись назад, ми могли б безпосередньо зв'язатися з командою Kelp, щоб запитати про їхній поріг DVN. Ця розмова могла б викрити конфігурацію 1-з-1 і призвести до виправлення. Ми цього не зробили. Це урок: навіть якщо відкриття здається занадто розмитим для офіційного процесу розкриття, все одно варто написати приватне повідомлення і поставити запитання.

Що це означає для безпеки DeFi

Крадіжка в Kelp — як і крадіжка в Drift 17 днів тому — сталася не через помилку в смарт-контракті. Автоматизовані сканери коду, такі як Slither, Mythril або навіть GoPlus, не можуть це виявити. Вразливість полягає в конфігураціях розгортання, прогалинах в управлінні та архітектурних рішеннях, що знаходяться над рівнем коду.

Це також основний принцип crypto-project-security-skill:

Безпека протоколу — це не лише безпека коду. Протокол може мати бездоганний Solidity, п'ять аудитів від топових фірм, винагороду за помилки у $250 000 — і все одно втратити $292 мільйони через проблему конфігурації валідатора мосту.

Інструменти мають відкритий код на GitHub — кожен може переглянути методологію, запустити її самостійно або покращити.

Хронологія

12 днів. Сигнали були давно. Питання в тому: як екосистемі створити інструменти, які зможуть бачити ці сигнали до того, як завалиться наступний міст?

Що ви можете зробити

Якщо у вас є активи в DeFi-протоколі з кросчейн-мостом:

1. Проведіть самоаудит. Інструмент має відкритий код. Не довіряйте, перевіряйте.

2. Перевірте конфігурацію валідатора мосту. Якщо протокол не бажає розкривати свій поріг DVN, вважайте це «червоним прапорцем». Саме це зробив наш звіт, і він виявився правильним.

3. Не припускайте, що аудити коду покривають усе. Kelp пройшов понад 5 аудитів коду від відомих компаній та платформ (Code4rena, SigmaPrime, MixBytes). Традиційні аудити коду не призначені для виявлення ризиків на рівні конфігурації, таких як налаштування порогу DVN — це інший тип аналізу, і це не провина аудиторських фірм.

4. Оцініть страхове покриття. Якщо протокол не має страхового пулу, а ви є постачальником ліквідності на кредитній платформі, яка приймає його токен як заставу, ви неявно страхуєте його. Інцидент з вкладниками WETH на Aave навчив цього на гіркому досвіді.

Ширша картина: ШІ-агент як рівень безпеки

Ця стаття обговорює інструмент і злам. Але основна теза ширша: ШІ-агент може бути незалежним рівнем безпеки для DeFi-інвесторів.

Традиційна модель безпеки в криптоіндустрії виглядає так: протокол наймає аудиторську фірму, фірма перевіряє код, фірма публікує звіт. Ця модель має «сліпі зони» — як продемонстрував інцидент із Kelp, вона зосереджується на коректності коду, але ігнорує ризики конфігурації, управління та архітектури.

Те, що пропонують Claude Code та подібні інструменти, — це інший шлях: будь-хто може запустити ШІ-оцінку ризиків будь-якого протоколу, використовуючи публічно доступні дані за лічені хвилини. Вам не потрібно витрачати $200 000 на аудиторську фірму. Вам не потрібно знати, як читати Solidity. Ви дозволяєте агенту порівняти архітектуру протоколу з відомими шаблонами атак, і він надає вам запитання, які ви повинні поставити перед внесенням коштів.

Це не замінює професійні аудити — але знижує бар'єр належної перевірки першого рівня до рівня, доступного кожному. Постачальник ліквідності, який розглядає можливість виділення коштів на новий протокол стейкінгу, тепер може провести DeFi-аудит.

Звіт по Kelp не був ідеальним. Він оцінив ризик мосту як середній, хоча він мав бути критичним. Він не заглибився в рівень конфігурації. Але він поставив правильні запитання — якби команда Kelp або будь-який постачальник ліквідності сприйняли ці запитання серйозно на той час, збитків у $292 мільйони можна було б уникнути.

Посилання на оригінальну статтю