ІІ знайшов баг в Ethereum, який міг вимкнути валідаторів

Ethereum Foundation направила ІІ-агентів шукати вразливості в софті, на якому працюють валідатори мережі. Пошук завершився реальною знахідкою: віддалено відтворюваний крах ноди, зареєстрований як CVE-2026-34219 і вже виправлений командою.

Головний висновок команди безпеки протоколу інший. Більшість роботи пішла не на пошук багів, а на відсіювання переконливих, але фальшивих звітів від тих самих агентів. Про це Foundation розповіла у власних польових нотатках для розробників, адресованих усій ширшій криптоспільноті, яка теж почала експериментувати з подібними інструментами.

Що саме знайшли ІІ-агенти в Ethereum

Мережа Ethereum працює на тисячах звичайних комп'ютерів, кожен з яких зберігає копію блокчейна і передає повідомлення сусідам. Валідатори, ноди, що застейкали ether і голосують за коректність блоків, працюють поверх цього шару і залежать від того, чи доходять до них повідомлення.

Вразливість, яку знайшли агенти, сиділа саме в мережевому протоколі gossipsub. Вона дозволяла віддаленій системі спричинити крах: нода наштовхується на неможливе обчислення, зупиняється й вимикається, а валідатор випадає з мережі, доки оператор не перезапустить його вручну.

Складність не в пошуку багів, а в їх перевірці

За словами Нікоса Баксеваніса з команди Protocol Security, автора звіту, найбільшим сюрпризом стало не те, скільки багів знайшли агенти, а те, скільки часу пішло на відділення реальних вразливостей від тих, що лише виглядали реальними.

"Сюрпризом виявилося те, як мало роботи пішло на пошук багів, і як багато пішло на те, щоб відрізняти справжні від тих, що лише виглядали справжніми."

Нікос Баксеваніс, команда Protocol Security, Ethereum Foundation, польові нотатки від липня 2026

Різниця в тому, що видає інструмент. Фазер, стандартний інструмент, який закидає в софт зіпсовані дані, повертає крах і точку, де він стався, а інженер підтверджує це за хвилини. Агент натомість повертає готову історію: пояснює, як дістатися до вразливості, чому вона небезпечна, яку оцінку критичності поставити, і додає код, що нібито демонструє атаку. Написано все це однаково впевнено, незалежно від того, реальний баг чи вигаданий.

Три типи хибних спрацьовувань

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

Перший сценарій це крах, що трапляється лише в тестовій збірці, де компілятор вмикає перевірки безпеки, відсутні в реальному софті. У продакшені нічого не ламається. Другий сценарій це атака, яка спрацьовує тільки тоді, коли небезпечне значення підкласти в програму вручну, бо кожен реальний шлях доставки цього значення ззовні його відхиляє. Третій сценарій це формальний доказ (практика математично довести коректність коду), де доказ проходить, демонструючи щось тривіально істинне, і нічого не каже про реальну безпеку коду.

Чому ІІ погано бачить багатокрокові атаки

Ще одна слабкість агентів полягає в тому, що вони добре міркують про одну дію, але гірше бачать послідовність з кількох по-своєму коректних кроків, де проблема ховається саме в порядку дій.

Саме так побудована більшість атак на крипто-протоколи цього року. Кожен окремий крок виглядає звичайною транзакцією, а шкода ховається в їхній послідовності. Злам Edel Finance цього місяця обійшов коректний ціновий фід Chainlink через шар обгортки над ним. В атаці на BONK DAO купівля токенів, голосування і виконання рішення теж були кожна по собі звичайними транзакціями. Kurslog вже розповідав, як зловмисник вивів так $20 мільйонів через голосування в BONK DAO.

Через це Foundation не покладається на агентів як на самостійних аудиторів. Їхня роль полягає в тому, щоб запропонувати підозрілі послідовності дій, які варто перевірити. Фінальну перевірку і тестування все одно виконують класичні інструменти та люди, а не текстовий опис від моделі, хай навіть дуже переконливий.

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

Уроки для команд безпеки

Ethereum не єдиний проєкт, який експериментує з ІІ для пошуку вразливостей. У 2026 році подібні пілоти запускають і біржі, і DeFi-протоколи менших розмірів, сподіваючись прискорити аудит коду без пропорційного збільшення штату. Але розмір мережі Ethereum і обсяг застейканого ether роблять ціну будь-якої пропущеної помилки особливо високою, тож досвід команди безпеки протоколу варто читати уважно навіть тим, хто працює з набагато меншим бюджетом.

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

• Довіряти, але перевіряти: звіт агента це гіпотеза, а не підтверджений баг, доки її не пройшли класичні тести.
• Окремо оцінювати багатокрокові сценарії: агенти пропускають атаки, де кожен крок сам по собі легальний.
• Публікувати польові нотатки: відкриті звіти про невдалі спроби економлять час іншим командам розробників.

Головний ризик після таких експериментів полягає не в тому, що ІІ пропустить справжню вразливість, а в тому, що команда безпеки втратить час і довіру, ганяючись за десятками переконливих, але порожніх звітів. Ethereum Foundation вирішила цю проблему прозоро: опублікувала методику і залишила фінальне рішення за людьми.