В 2026 году обход патчей безопасности стал встречаться заметно чаще: 2,3% исправлений уязвимостей на GitHub потребовали нового advisory в течение 90 дней после релиза. С 2019 по 2025 год этот показатель держался около 0,2%. Для российских разработчиков, администраторов и команд ИБ вывод неприятный, но полезный: установка обновления всё чаще означает начало проверки, а не финал инцидента.
Такую динамику обнаружила компания Terra Security, анализировавшая опубликованные CVE и GitHub-advisory с признаками неудачных исправлений, сообщает The Register. Исследователи увидели повторяющийся сценарий: вендор выпускает патч, затем находится способ его обойти, после чего выходит второе исправление. На фоне распространения ИИ-инструментов для поиска уязвимостей этот цикл стал заметно короче: атакующим проще системно разбирать диффы, тестировать нестандартные входные данные и искать вариант, который разработчик не включил в защиту.
Важно, что речь не о банальных регрессиях, когда обновление ломает соседнюю функцию. В части случаев первая заплатка устраняет конкретный публичный пример эксплуатации, но оставляет сам механизм атаки. Если защита строится на списке запрещённых значений, злоумышленнику достаточно найти один неучтённый вариант кодировки, имени хоста, пути или ключа объекта. Разработчику же нужно предусмотреть их все. Это старая асимметрия безопасности, которую автоматизация делает ещё болезненнее.
Показательный кейс — две Windows-уязвимости 2026 года. По данным издания, связанные с российским государством кибершпионы использовали zero-day CVE-2026-21510 в Windows Shell как минимум за месяц до февральского патча Microsoft. Первое исправление оказалось неполным: оно оставило другую проблему — zero-click уязвимость принудительной аутентификации CVE-2026-32202. Её также обнаружили и эксплуатировали до того, как Microsoft выпустила исправление в апреле. История хорошо иллюстрирует риск точечного лечения: закрытый обход не всегда означает закрытый класс ошибок.
Уязвимости с последующим обходом исправления примерно в четыре раза чаще попадали в каталог CISA Known Exploited Vulnerabilities, чем другие баги у тех же поставщиков. Это не доказывает, что каждый слабый патч будет использован в реальной атаке, но показывает приоритет для защитников: если уязвимость уже эксплуатируется, её патч почти наверняка изучают не только синие команды и исследователи.
Наиболее проблемными классами Terra называет SSRF и prototype pollution. Среди CVE с неудачными исправлениями prototype pollution встречался примерно в 11 раз чаще, чем можно было бы ожидать по его доле среди всех CVE; для SSRF показатель составил 4,6 раза. Обе категории нередко пытаются закрыть блокировкой отдельных строк или шаблонов. Для SSRF это могут быть адреса, хосты и пути, для prototype pollution — опасные ключи объектов. Такой подход удобен для срочного релиза, но плохо выдерживает вариации форматов и контекстов обработки данных.
Отдельная зона риска — ядро Linux. Согласно записям CNA ядра на 8 октября, 3,2% kernel CVE были внесены исправлением другой CVE. В загруженных подсистемах, включая fs/smb и net/sched, доля достигает примерно 10%. Для компаний это аргумент против механического правила «критический патч — немедленно в production без дополнительных проверок». Откладывать обновления опасно, но и полагаться лишь на статус «исправлено» уже недостаточно.
Практика для команд разработки выглядит довольно приземлённо. Перед выпуском стоит проверять не только конкретный proof of concept, но и первопричину, соседние точки входа и альтернативные представления данных. Полезны тесты на двойное кодирование, редкие URL-формы, перенаправления, DNS-резолвинг, вложенные структуры объектов и различия между компонентами, которые по-разному нормализуют ввод. Для DevSecOps-команд особенно ценны регрессионные тесты, которые фиксируют весь класс атаки, а не один уже известный payload.
Администраторам и владельцам продуктов стоит добавить к процессу патч-менеджмента короткий контрольный список: затрагивает ли обновление корневую причину, распространяется ли защита на весь класс уязвимости и не создаёт ли она новый риск. После установки исправления для активно эксплуатируемой CVE имеет смысл усилить мониторинг, проверить журналы на прежние и близкие техники атак, а при возможности развернуть патч сначала на репрезентативном контуре.
Главный тренд здесь не в том, что патчи внезапно перестали работать. Скорее ИИ снижает цену анализа чужих исправлений и поиска их границ. Чем быстрее вендоры выпускают точечные заплатки под давлением эксплуатации, тем выше шанс, что следующая версия атаки появится раньше, чем организация успеет отчитаться о закрытой уязвимости. Обход патчей безопасности становится отдельной стадией жизненного цикла CVE — и процессы разработки, тестирования и реагирования придётся строить с учётом этого факта.