Google заявила о первом zero-day exploit с признаками AI-assisted разработки

Проверено 12 мая 2026 года. Google заявила о первом zero-day exploit с признаками AI-assisted разработки. 11 мая Google Threat Intelligence Group написала, что впервые увидела zero-day exploit, который, по ее оценке, был найден и доработан с помощью модели ИИ. Самая важная часть этой новости не в громком слове zero-day и не в попытке объявить наступление полностью автономных атак. Важнее то, что одна из крупнейших команд threat intelligence публично говорит: в exploit code появились достаточно сильные сигналы, чтобы отделить обычный скрипт злоумышленника от AI-assisted exploit development.

Google описывает этот кейс как подготовку к массовой эксплуатации. Речь шла о Python-скрипте, который позволял обойти двухфакторную аутентификацию в популярном open-source инструменте веб-администрирования. По словам GTIG, компанию-вендора успели предупредить, а саму активность удалось сорвать до реального ущерба. Если оценка Google верна, граница снова сдвинулась: LLM уже полезны не только защитникам и авторам PoC по опубликованным CVE, но и криминальным группам, которым нужно быстрее находить и доводить до эксплуатации логические ошибки.

Что именно заявила Google

В исходном посте Google формулирует заявление аккуратно. GTIG не пишет, что модель сама выбрала цель, нашла баг и автономно провела атаку. Формула другая: компания believes, что zero-day exploit был разработан с помощью AI, и говорит о высокой уверенности, что злоумышленник использовал модель для поиска и доведения уязвимости до рабочего exploit. Это важная разница. Она отделяет сильную техническую оценку от недоказанного тезиса про «ИИ уже сам взламывает интернет».

Есть и другие ограничения. Google не раскрывает название уязвимого продукта, не называет группу и не публикует сам exploit. AP отдельно пишет, что компания не считает источником этого кода ни Gemini, ни Claude Mythos. Для новости этого достаточно, чтобы зафиксировать новый тип публичного отчета, но недостаточно, чтобы делать широкие выводы о том, какая именно модель оказалась за кадром и насколько автоматизирована была вся цепочка работы.

Какие сигналы GTIG считает признаками AI-assisted разработки

Самый интересный кусок в посте Google — не сам факт инцидента, а набор признаков, по которым GTIG делает вывод об AI-assisted происхождении exploit code. Компания перечисляет несколько маркеров: избыток образовательных docstring, галлюцинированный CVSS score, слишком «учебниковый» Python-стиль, детализированные help-меню и аккуратно оформленный ANSI color class. По отдельности такие следы еще не доказывают ничего. Вместе они дают профиль кода, который очень похож не на короткий криминальный вспомогательный скрипт, а на артефакт, прошедший через LLM.

Еще важнее тип самой ошибки. Google пишет, что это не memory corruption и не типичный input sanitization bug. Уязвимость относится к классу high-level semantic logic flaws: разработчик жестко зашил доверительное исключение в логику, а exploit использовал это против механизма 2FA. GTIG прямо подчеркивает, что такие противоречия между намерением разработчика и фактическим поведением системы frontier LLM умеют замечать лучше традиционных сканеров, которые в первую очередь ищут крэши, небезопасные вызовы и синтаксические аномалии.

Но есть нюанс, который нельзя потерять в пересказе. Этот bypass требовал валидные пользовательские учетные данные. То есть речь не идет о магическом «удаленном взломе одной подсказкой». Картина более приземленная и оттого тревожная: модель помогает ускорить переход от находки логической ошибки к рабочему exploit, который потом можно встроить в операцию с массовым охватом.

Почему это не доказательство полностью автономной атаки

Если читать исходный пост внимательно, Google сама оставляет важные оговорки. Во-первых, это оценка на основе структуры и содержания exploit code, а не телеметрия из чужой модели. Во-вторых, GTIG пишет о likely leveraged an AI model, а не о полностью autonomous attack chain. В-третьих, без названия продукта, публичного образца exploit-кода и атрибуции конкретной группы рынок еще долго будет спорить о том, где именно кончается «человеческий криминальный тулчейн с LLM на подхвате» и начинается новый класс автоматизации атак.

Но именно в этом и ценность кейса. До сих пор разговор об AI в offensive security часто жил между двумя крайностями: либо «это просто ускоренный поиск по документации», либо «модели завтра начнут сами писать zero-day и ломать все подряд». История Google сдвигает дискуссию в более полезную точку. Речь не о полной автономии, а о том, что LLM уже помогают там, где раньше у атакующих было больше ручной работы: понять логику приложения, заметить доверительные исключения, быстро оформить exploit и подготовить его к масштабированию.

Что это меняет для defensive AI

Для защитников отсюда следует неприятный, но практический вывод: окно между поиском, доведением до эксплуатации и массовым использованием уязвимости будет сжиматься именно в тех классах багов, где проблема спрятана не в памяти, а в бизнес-логике и авторизационных исключениях. Это хорошо стыкуется с тем, что уже показывали другие материалы Toolarium: LLM все увереннее проходят путь от поиска уязвимости до воспроизводимого exploitation workflow, а рынок параллельно строит защитные ограничения вокруг самых чувствительных моделей с сильными кибервозможностями.

Этим же объясняется и ответ вендоров. OpenAI 7 мая вывела GPT-5.5-Cyber в limited preview и отдельно подчеркнула, что для большинства защитных сценариев стартовой точкой остается GPT-5.5 с Trusted Access for Cyber, а более permissive режимы должны идти вместе с усиленной верификацией и account-level controls. На той же логике построены и более широкие развилки рынка, которые мы уже разбирали в материале про AI-кибермодели и в тексте о том, как Anthropic разводит defender-продукт и более чувствительные dual-use capability tiers.

Иными словами, новый сигнал от Google не доказывает, что offensive AI уже вышел из-под контроля. Он доказывает другое: крупнейшие игроки начинают видеть в реальных инцидентах одинаковый паттерн. Те же модели, которые помогают защитникам быстрее искать логические баги и валидировать патчи, начинают с такой же скоростью помогать атакующим. А значит, спор о том, нужны ли отдельные trust-based режимы доступа и более быстрый защитный цикл, фактически закрыт.

Что важно запомнить

Главный вывод этой истории проще громких заголовков. Google не объявила, что ИИ уже сам пишет боевые zero-day эксплойты без участия человека. Но компания впервые публично заявила, что увидела zero-day exploit с достаточно явными признаками AI-assisted разработки и подготовки к mass exploitation. Для security-команд этого уже достаточно, чтобы пересматривать приоритеты: быстрее закрывать auth и logic flaws, внимательнее смотреть на pre-disclosure exploitation и не считать, что offensive AI ограничится генерацией фишинговых писем и скриптов на коленке.