Средний интервал между раскрытием уязвимости и ее практической эксплуатацией в 2026 году сократился примерно до 8 часов. Для команд ИБ это означает неприятную математику: пока change window еще только согласуют, атакующие уже проверяют, сработает ли свежая CVE в реальной инфраструктуре. На этом фоне проверка эксплуатируемости превращается из nice-to-have в рабочий инструмент приоритизации для SOC, DevSecOps и IT-руководителей.
Об этом сообщает BleepingComputer со ссылкой на Picus Security, которая в спонсорском материале описала подход к оценке риска без готового публичного эксплойта. Логика простая: если злоумышленники научились собирать цепочки атаки быстрее, чем компания успевает ставить патчи, смотреть только на CVSS уже недостаточно. Вопрос смещается с «насколько страшна уязвимость на бумаге» к более приземленному «можно ли реально пройти по этой цепочке именно у нас».
Главная цифра в материале Picus выглядит жестко: если раньше между публикацией уязвимости и ее weaponization мог пройти не один месяц, то теперь речь идет буквально о часах. Компания ссылается на свой показатель Zero Day Clock: в 2026 году среднее время якобы держится около 8 часов, тогда как двумя годами ранее речь шла примерно о 53 днях. Даже если конкретное значение будет плавать по мере поступления новых данных, сама динамика для рынка понятна: защитники живут в неделях, атакующие уже живут в часах.
Отсюда и следующий неприятный вывод: «патчить быстрее» звучит разумно, но на практике это не кнопка. В материале приводятся данные Verizon DBIR 2026 по более чем 13 тысячам организаций: медианное время исправления уязвимостей, которые уже эксплуатируются в реальном мире, выросло до 43 дней против 32 дней годом ранее. Доля организаций, полностью закрывающих такие дыры, снизилась с 38% до 26%. А лучшие команды, по оценке Picus, в первую неделю успевают закрыть лишь 30-40% таких уязвимостей, и этот показатель годами почти не двигается. Если у атаки фора в несколько часов, а у remediation цикл в несколько недель, дырка между ними становится не метафорой, а окном для взлома.
Picus подталкивает рынок к более прагматичной модели: не пытаться доказать риск только фактом успешного запуска эксплойта, а проверять отдельные звенья цепочки атаки. Такой подход компания называет проверкой эксплуатируемости через TTP-цепочки. Идея в том, чтобы разложить конкретную CVE на обязательные шаги атакующего: получение исполнения, обход защиты, повышение привилегий, доступ к учетным данным, движение к целевому активу. Дальше каждый шаг проверяется отдельно на фоне уже развернутых средств защиты: EDR, групповых политик, защиты LSASS, allow-listing, сетевых правил. Если хотя бы одно критическое звено ломается, вся цепочка на конкретном активе не взлетает, даже если уязвимость сама по себе выглядит как «девятка» или «десятка» по CVSS.
В этом есть важная практическая разница с автоматизированным пентестом, который Picus тоже упоминает. Автопентест хорош там, где безопасно запускать реальные exploit chains и где у исследователей уже есть рабочий эксплойт. Но именно здесь начинаются ограничения. Во-первых, далеко не для каждой свежей CVE быстро появляется публичный и безопасный для теста эксплойт. Во-вторых, самые чувствительные системы, от критичных бизнес-сервисов до изолированных сегментов, часто как раз нельзя «простреливать» ради проверки гипотезы. В-третьих, в первый день после disclosure защитники еще только встраивают новую логику в инструменты, а злоумышленники уже пробуют маршрут. По оценке Picus, live exploitation в типичной компании покрывает лишь 10-15% общей картины риска; остальное приходится оценивать косвенно, но все равно на основе технических данных, а не интуиции.
В качестве примера Picus разбирает CVE-2025-29824, уязвимость use-after-free в Windows CLFS, которая может привести к повышению привилегий до SYSTEM и, как утверждается в материале, использовалась в реальных атаках Storm-2460 и RansomEXX. Вместо того чтобы ждать сертифицированный эксплойт или стрелять им по критичному узлу, компания предлагает проверить последовательность техник: запуск через certutil и MSBuild, сбор системной информации для обхода KASLR, эксплуатацию самой ошибки в CLFS, модификацию токена, инъекцию в dllhost и последующую попытку дампа LSASS. Если, например, application allow-listing режет вызов MSBuild, а защита LSASS не дает снять учетные данные, получается не абстрактная «низкая вероятность», а вполне защитимая перед аудитом позиция: да, CVE есть, но на этом активе цепочка не сходится.
Для разработчиков и DevSecOps из этого следует довольно приземленный вывод. Триаж по CVSS, EPSS и спискам KEV никуда не исчезает, но сам по себе он уже плохо отвечает на вопрос, что фиксить в первую очередь в сложной инфраструктуре. Когда поток CVE идет десятками тысяч в год, а обновления все равно упираются в тестирование, совместимость и доступность сервиса, бизнесу нужен не еще один красный дашборд, а доказательство, какие уязвимости действительно достижимы с учетом уже включенных контролей. Для CISO и IT-директора это еще и способ объяснить приоритеты не только инженерам, но и руководству: почему один патч ставится немедленно, второй уходит в mitigation, а третий пока остается под мониторингом.
Похоже, рынок ИБ постепенно уходит от старой роскоши, когда после disclosure оставалось время спокойно разложить все по папкам. Если окно до эксплуатации действительно сжалось до считаных часов, победят не те, кто громче всех обещает «пропатчить все срочно», а те, кто научится быстро и технически доказуемо отвечать на более неудобный вопрос: эта уязвимость опасна вообще для всех или конкретно для нас. Подробности исходного материала можно посмотреть в BleepingComputer .
The post Уязвимости эксплуатируют быстрее, чем их успевают патчить appeared first on iTech News.