В отчёте ARKTIS и GSOC компании «Газинформсервис» за III квартал 2026 года говорится о резком увеличении числа опубликованных уязвимостей и сокращении времени, доступного защитникам для установки обновлений. По данным публикации SecPost, в NVD за квартал появилось около 36,9 тыс. CVE против 20,6 тыс. кварталом ранее. Ключевое значение имеет не только объём новых записей, но и скорость появления рабочего кода для атак: публичный PoC у части уязвимостей становится доступен в день публикации или до неё.

Рост CVE меняет порядок работы с обновлениями.

Авторы исследования сообщают о 546 новых CVE, для которых появился публичный PoC. Из 543 уязвимостей с известной датой публикации такого кода у 176 он вышел не позднее раскрытия самой проблемы. Это примерно треть выборки. Формулировка об «окне в один день» не означает, что каждая уязвимость будет атакована немедленно, однако она описывает практическую ситуацию для команды защиты: привычный цикл «узнать о CVE — оценить — согласовать изменение — установить патч» может оказаться длиннее доступного времени.

Тренд подтверждается и внешним контекстом. Во II квартале 2026 года, как сообщала «Лаборатория Касперского», исследователи всё чаще раскрывали описания эксплойтов до выхода исправлений. Такая последовательность даёт преимущество тем, кто готов быстро адаптировать опубликованный код к конкретной цели, тогда как разработчики и владельцы инфраструктуры ещё только планируют обновление.

Для разработки и эксплуатации из этого следует, что управление патчами нельзя строить исключительно как периодическую процедуру. Нужны точный инвентарь внешних сервисов, понятная связь между CVE и конкретными версиями ПО, а также заранее подготовленные сценарии срочного обновления или временной изоляции компонента. Без этих данных даже качественный мониторинг новостей об уязвимостях не превращается в быстрое действие.

CVSS не равен вероятности эксплуатации.

Отчёт показывает ограничение CVSS как единственного критерия приоритизации. В приведённой выборке из 192 CVE с критической оценкой CVSS не менее 9,0 в каталог KEV, который включает известные эксплуатируемые уязвимости, вошли 17. Одновременно 14 из 46 уязвимостей из KEV не имели критического балла CVSS. Эти цифры не отменяют оценку тяжести, но показывают, что она отвечает прежде всего на вопрос о потенциальном воздействии ошибки, а не о том, будет ли она применяться в реальных атаках.

Приоритет для исправления стоит определять по сочетанию факторов: доступен ли PoC, виден ли уязвимый сервис из интернета, присутствует ли он в используемой инфраструктуре, есть ли сведения об эксплуатации и насколько далеко атакующий может продвинуться после компрометации. Такой подход особенно полезен, когда количество новых CVE растёт быстрее, чем возможности команды проверить и установить все обновления.

Отдельной проблемой остаются давно известные ошибки на периметре. Как следует из материала Computerra, девять из 16 позиций в наиболее частых атаках на периметр заказчиков относятся к CVE 2021 года и более ранним. Это означает, что поток новых уязвимостей не вытесняет старые: злоумышленники продолжают выбирать известные пути, если исправления для них так и не были установлены.

AI/ML-инфраструктура становится отдельной зоной контроля.

В выборке из пяти популярных продуктов для AI/ML-инфраструктуры — LangFlow, n8n, Open WebUI, LiteLLM и Ollama — исследователи обнаружили 204 уязвимости; 56% из них получили высокую или критическую оценку. Об этом говорится в материале «Газинформсервиса» на Хабре. Речь идёт не только о самих моделях: риски возникают на уровне шлюзов к провайдерам, оркестрации процессов, хранения ключей, интеграций и доступа агентов к внутренним инструментам.

Для AI-продукта компрометация такого вспомогательного компонента может означать утечку ключей доступа к моделям и облачным API, доступ к внутренним сервисам либо запуск несанкционированных действий от имени агента. Поэтому AI/ML-сервисы следует учитывать в общей карте активов наравне с API-шлюзами, системами CI/CD и административными панелями, а не воспринимать их как изолированный экспериментальный контур.

В качестве практических мер авторы отчёта предлагают проверить версии Apache, ColdFusion, Grafana, Confluence и SharePoint на периметре, а для AI/ML-компонентов применять сегментацию, ограничивать исходящие соединения через Egress allowlist и жёстко контролировать права агентов и инструментов. Эти рекомендации приведены в публикации ComNews. Похожая логика действует и для цепочек поставок: в разборе изменений защиты WordPress эксперт «Газинформсервиса» указывал, что задержка между раскрытием исправления и его применением создаёт атакуемый промежуток.

Главный вывод отчёта — скорость реагирования становится самостоятельным параметром киберустойчивости. Компании не смогут устранить все CVE сразу, но могут сократить риск за счёт актуального учёта активов, приоритизации по фактической эксплуатируемости, изоляции критичных сервисов и заранее проверенных процедур экстренных изменений.