Google Threat Intelligence Group (GTIG) опубликовала отчёт «Vulnerability Discovery and Exploitation Trends in the AI Era» о том, как ИИ влияет на поиск и эксплуатацию уязвимостей. За окно наблюдения с 1 января 2025 по 31 августа 2026 года объём раскрытий вырос вдвое: с 5045 CVE в месяц в январе 2026 до пика 10740 в августе 2026, а за первые восемь месяцев 2026 года в дикой природе эксплуатировались 141 уязвимость — больше, чем за весь 2025 год (127). Авторы отмечают, что ИИ меняет не столько объём находок, сколько их профиль: уязвимости, найденные с помощью ИИ, чаще оказываются опасными — 58% из них получают средний рейтинг GTIG против 28% у обычных находок, а RCE, то есть удалённое выполнение кода, составляет 50% последствий их эксплуатации против 26% в среднем.

image

Что произошло

Отчёт подготовили Robin Grunewald, Supriya Mazumdar и Kelli Vanderlee; он охватывает период с 1 января 2025 по 31 августа 2026 года. Внутри отчётного окна zero-day составили 62% всех уязвимостей, эксплуатировавшихся в дикой природе, с пиком в августе 2026 года: 22 zero-day против базовых 8–12 в месяц. Главной площадкой эксплуатации остаются периметровые устройства: на класс edge/security appliance, куда входят роутеры и шлюзы, приходится 14% эксплуатировавшихся уязвимостей, при этом более 65% эксплуатируемых уязвимостей в этом классе имеют высокий или критический рейтинг. В отчёте перечислены конкретные всплески: 75 high-risk уязвимостей у вендора TOTOLINK и 128 high-risk уязвимостей у Oracle и драйверов Linux в августе 2026 года.

Контекст

Методологически важнее любых цифр то, что GTIG впервые в систематической форме отделяет уязвимости, найденные с помощью ИИ, от обычных находок: атрибуция строится по лабораторным реестрам frontier-программ и тегам в advisories CISA и MITRE. Сам механизм влияния авторы формулируют как гипотезу: злоумышленники, скорее всего, используют LLM не столько для поиска принципиально новых уязвимостей, сколько для автоматизации анализа патчей, объявлений об уязвимостях и PoC-кода, чтобы быстро превращать известные n-day уязвимости — уже раскрытые, с выпущенным патчем, но не установленные повсеместно, — в рабочие эксплойты. Оценивать объём раскрытий на этом фоне нужно осторожно: валовый рост — плохая метрика опасности, потому что часть потока является артефактом автоматической раздачи идентификаторов, и по данным отчёта около 5000 CVE было сгенерировано из одного описания «Linux Kernel».

Почему это важно для индустрии

Для индустрии отчёт фиксирует смещение ценности от подсчёта CVE к быстрой приоритизации того, что реально эксплуатируют: покупатель уже спрашивает у поставщиков, какой из десяти тысяч месячных CVE важен именно для его инфраструктуры, и классические списки сканирования на этот вопрос отвечают всё хуже. Давление ложится прежде всего на вендоров периметровых устройств, чьи продукты чаще всего оказываются среди эксплуатируемых, и на команды безопасности, чьи SLA патчинга рассчитаны на более медленные циклы превращения advisory в эксплойт. На этом фоне открывается окно для продуктов класса «patch priority»: агентов, которые мониторят advisories CISA и MITRE и PoC-фиды, сопоставляют их с инвентарём заказчика и формируют приоритизированную очередь патчей; подобные MVP собираются уже сейчас без новой инфраструктуры, а августовский цикл 2026 года даёт для них готовые тестовые ориентиры. Ожидаемо вендоры сканеров и vulnerability management-платформ начнут встраивать сигналы «найдено с помощью ИИ» и скорость weaponization в логику приоритизации, а ключевой метрикой SOC-инструментов станет полнота покрытия реально эксплуатируемых в дикой природе уязвимостей.

Почему это важно для пользователей

Практический вывод для читателя противоположен заголовочному страху в стиле «CVE стало вдвое больше»: по данным GTIG, реально эксплуатируются лишь 0,23% раскрытых CVE, примерно одна из 431. Проверить стоит периметр: если в сети есть роутеры, шлюзы или корпоративные сервисы с публичными интерфейсами управления, именно они остаются главной мишенью, и high-risk n-day для них теперь нужно закрывать быстрее, чем раньше. Конкретные шаги: провести инвентаризацию периметровых устройств, пересмотреть очерёдность патчинга high и critical n-day, ориентируясь на актуальные всплески из отчёта, а уязвимости, отмеченные как найденные с помощью ИИ, трактовать как более приоритетные. Тем, кто ведёт собственный приём CVE-фида, полезно также проверить конвейер на дубли: часть идентификаторов генерируется автоматически, и поток может раздуваться искусственно.

Что пока неизвестно / ограничения

Главное ограничение — статус причинности: гипотеза о том, что LLM ускоряют превращение известных n-day в рабочие эксплойты, измерениями не проверена, потому что в отчёте нет базлайна времени от advisory до exploit до и после появления LLM, а прямой связи скачка раскрытий с LLM в данных нет. Атрибуция «найдено с помощью ИИ» опирается на видимые маркеры, то есть реестры frontier-программ и теги в advisories CISA и MITRE, поэтому систематически занижает полноту и смещает выборку в сторону крупных вендоров, которые такие программы ведут; из-за этого часть разброса рейтингов может объясняться профилем вендора, а не самим ИИ. Для долей вроде 58% среднего рейтинга или 50% RCE в данных не хватает размера подвыборки ИИ-найденных уязвимостей, и при малом числе наблюдений такие проценты крайне неустойчивы. Ожидаемо, что по мере расширения участия вендоров в frontier-программах подвыборка станет статистически устойчивой и приведённые цифры можно будет перепроверить.

Источники

Автор

Look at AI, редакция