ИИ нашел баг в 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 решила эту проблему прозрачно: опубликовала методику и оставила финальное решение за людьми.