За первые пять месяцев 2026 года доля уязвимостей, по которым признаки эксплуатации или готовый PoC появлялись в первые сутки после раскрытия, достигла 38% против 12% за сопоставимый период 2025 года.
Основная проблема заключается в том, что превратить информацию об ошибке в готовую атаку стало почти так же просто, как её прочитать. Для злоумышленников опубликованное исправление стало техническим указателем: сравнив старую и новую версии кода, можно восстановить логику ошибки и собрать рабочий пример атаки быстрее, чем организация успевает согласовать обновление. Раньше бюллетень производителя, запись в базе CVE и выпущенное исправление давали специалистам по ИБ несколько недель, иногда месяцев на инвентаризацию активов, оценку применимости и планирование обновления. Теперь этот интервал часто укладывается в одну рабочую смену. Для злоумышленников исправление стало не только способом закрыть проблему со стороны производителя, но и технической подсказкой: по сравнению изменений в коде можно восстановить логику ошибки, определить уязвимый участок, сопоставить его с типовыми приемами эксплуатации и собрать рабочий пример быстрее, чем крупная организация успеет пройти полный цикл согласования изменений.
Дополнительное ускорение дали инструменты автоматизированного анализа кода и ассистенты на базе больших языковых моделей. Они не заменяют сильного специалиста по эксплуатации уязвимостей, но снимают значительную часть рутинной работы: помогают сравнивать версии, выделять изменения, связанные с безопасностью, подбирать входные данные, искать похожие ошибки в старых уведомлениях производителей и формировать черновики демонстрационного кода. В результате снизился порог входа для воспроизведения уже раскрытой уязвимости. По оценке экспертов, в 2026 году в 31% исследованных кейсов первые публичные примеры эксплуатации имели признаки ускоренной сборки на базе уже опубликованных исправлений, а в 18% случаев код атаки появлялся раньше, чем у крупных поставщиков средств сканирования и управления уязвимостями выходили стабильные проверки.
На стороне бизнеса ситуацию осложняют кадровый дефицит и неоднородность инфраструктуры. Даже зрелые команды не всегда могут быстро ответить на базовый вопрос, где именно используется уязвимый компонент. В одной организации он может находиться в коммерческом продукте, контейнерном образе, внутренней разработке, устаревшем сервисе на периметре сети или в системе подрядчика. К этому добавляется разрыв между публикацией CVE и появлением качественного правила обнаружения в сканерах: часть проверок выходит с задержкой, часть покрывает только отдельные версии продукта, часть требует проверки с учетными данными, которую компании не всегда включают из-за рисков для рабочих систем. Команды привыкли закрывать уязвимости в плановом режиме – раз в неделю, иногда реже. Это работало, пока атака готовилась месяцами. Сейчас тот же процесс просто не успевает: к моменту, когда задача попадает в спринт, окно уже закрыто, но не в пользу защитников.
Наиболее заметная концентрация риска в 2026 году наблюдается в отраслях, где сочетаются крупный внешний периметр, множество прикладных систем и жесткие ограничения на простои. По данным анализа обращений и расследований, на финансовый сектор пришлось 24% кейсов, связанных с эксплуатацией CVE в первые 72 часа после раскрытия, на промышленность и энергетику – 19%, на ИТ и телеком – 17%, на розничную торговлю и интернет-продажи – 14%, на транспорт и логистику – 10%, на государственные и окологосударственные организации – 9%, на медицину и фармацевтику – 7%. В финансах и интернет-торговле злоумышленников привлекает доступ к платежной инфраструктуре и персональным данным, в промышленности – длительные циклы обновления и зависимость от поставщиков, в телеком-сегменте – высокая плотность сетевых сервисов и большое число пограничных компонентов.
Данные сканеров стоит дополнять ведомостью состава программного обеспечения, анализом состава приложений, мониторингом данных о киберугрозах и проверкой доступности систем с внешнего периметра сразу после публикации значимых CVE. Для критичных систем нужен заранее согласованный порядок экстренного обновления, приоритизация по фактической доступности актива из сети и сценарии временного снижения риска: отключение уязвимой функции, ограничение доступа по спискам контроля, усиление правил межсетевого экрана веб-приложений, изоляция сегмента, перевод сервиса за дополнительный контроль аутентификации. Отдельного внимания требует ретроспективный поиск признаков компрометации: при появлении эксплойта через несколько часов после раскрытия исправление уязвимости уже не гарантирует, что злоумышленники не успели закрепиться в системе до установки обновления.