AI виявив уразливість у мережі Ethereum: можна примусити валідаторів ETH аварійно завершувати роботу й виходити з мережі

Фундація Ethereum відправила команду AI-агентів, які виявили вразливість із можливістю віддаленого тригеру, достатньо критичну, щоб спричинити крах, і через це верифікатори могли піти офлайн, а також розкрила її як CVE-2026-34219. Але та сама партія AI одразу згенерувала близько 1,000 фальшивих сповіщень-попереджень, а найскладніше — розрізнити, які з них справжні.
(Передумови: На щастя! Компанія з кібербезпеки виявила вразливість в Aptos: системний ризик для 70 млрд доларів США в криптовалюті)
(Додатковий контекст: AI повністю автоматично «хакерить і викуп» — викрито! Кодова назва JadePuffer, фокусується на криптогаманцях)

Один набір AI-агентів, спроєктований Фундацією Ethereum, справді знайшов вразливість, здатну відправити верифікаторів офлайн! Фундація Ethereum змусила AI сканувати програмне забезпечення, яке виконують верифікатори; ціль — протоколи на рівні мережі, якими в екосистемі Ethereum consensus client (клієнт консенсусу, відповідальний за валідацію блоків і підтримання консенсусу між нодами) обмінюються повідомленнями між собою. Якщо простіше, це канал для «шепоту» між верифікаторами — щоб вони могли підтвердити, що бачать ту саму ланцюжок.

AI-агенти тут виявили віддалено-тригируемий crash-вразливість: зовнішня особа, надіславши повідомлення в певний спосіб, може примусити вузол до виконання «обчислення, яке неможливо завершити»; програмне забезпечення не витримує, відмовляється й вимикається само. У результаті верифікатори переходять офлайн, і їм доводиться чекати, поки operator (оператор ноди) вручну перезапустить систему; у цей час упущені обов’язки можуть вплинути і на прибутковість, і на стабільність мережі.

Наразі цю вразливість вже швидко виправлено, а також розкрито як CVE-2026-34219; проблема — в реалізації gossipsub бібліотеки libp2p у Rust (набір низькорівневих мережевих програмних бібліотек, який дозволяє різним нодам знаходити одна одну, встановлювати з’єднання та передавати повідомлення).

У публічних field notes автор Nikos Baxevanis пише, що на пошук цих вразливостей пішло зовсім небагато часу; справді час забирає розрізнення, що є справжнім, а що лише виглядає правдоподібно.

AI-фальшиві попередження, упаковані в наратив

Традиційні інструменти нечітких (fuzzy) тестів, коли знаходять проблему, повертають лише «крах» і «місце, де це сталося», тож інженери за кілька хвилин можуть підтвердити, чи це насправді так. Але AI-агенти повертають цілу історію: вони простежують, як саме вразливість була спровокована, обґрунтовують, чому ця подія важлива, присвоюють серйозність, а ще додають фрагмент атакувального демонстраційного коду, який можна одразу запускати — усе це подається в гладкому тексті. Насправжні вразливості й ті, що є просто вигадкою, читаються майже однаково.

Команда Фундації Ethereum узагальнила три типи фальшивих попереджень, які повторюються знову і знову:

• Проблеми, які спричиняють крах лише в тестових збірках (перевірки безпеки, які увімкнені в експлуатаційній збірці, але не входять у реальні дистрибутиви; реальні користувачі з цим не зіткнуться)
• Атаки, які стають можливими лише після ручного підставлення небезпечних числових значень у код (кожен шлях, яким може піти зовнішній зловмисник, фактично спочатку блокує це значення)
• А також «некоректні докази», породжені формальною верифікацією (formal verification, коли математикою доводять, чи поведінка програми є коректною): доведена очевидна дрібниця, яка не дає програмному забезпеченню жодної нової інформації.

Набагато кореневіша проблема полягає в тому, що AI добре виводить, що сталося в «одну конкретну мить», але слабше визначає вразливості, які складаються з «кількох кроків, які кожен сам по собі легальний», — коли в кожному кроці окремо немає помилки, а помилка — в послідовності.

Triage — це продукт

Рішення, яке пропонує Фундація Ethereum, не полягає в тому, щоб викинути AI, і не полягає в тому, щоб приймати все за чисту монету; натомість AI-агенти мають відповідати за «рекомендації», які послідовності операцій варто тестувати, тоді як реальна перевірка як і раніше працює за традиційними тестами та ручним аудитом. Повноваження прийняття рішень не передаються; роль AI завжди лишається інструментом пошуку, а не заміною безпекових дослідників.

Схоже, що найбільш дефіцитна здатність на найближчий час — не знаходити вразливості автоматично, а вміти відрізнити, яке з «виявлень» є справжнім.