Почему уязвимостей все больше и как защитить сайт

Июль 2026 года поставил рекорд: почти 10 тыс. опубликованных уязвимостей за месяц, и искали их уже не только люди, но и нейросети. Что этот поток значит для обычного сайта и как выстроить защиту без круглосуточного дежурства.

Рекорд, которого не было 20 лет

Уязвимости в программах теперь ищут не только исследователи и злоумышленники. Их ищут нейросети, и делают это быстрее людей. Результат уже в статистике: за июль 2026 года опубликовано почти 10 тыс. уязвимостей (CVE) — месячный рекорд за всю историю наблюдений. Критических и высокоопасных среди них в 3,5 раза больше, чем на предыдущем пике (оценка аналитиков Epoch AI, август 2026).

Масштаб хорошо виден на примере вендоров. Microsoft в июльский «вторник патчей» закрыла 570 уязвимостей — втрое больше предыдущего, тоже рекордного пакета. Oracle за тот же месяц выпустила 1235 исправлений. За первые 6 месяцев 2026 года Microsoft устранила больше дефектов, чем за любой полный год за 20 лет наблюдений.

Программы не стали хуже. Дыры в них были всегда. Изменилось другое: их научились находить массово.

Откуда волна: уязвимости ищет ИИ

Главная причина роста — автоматизация поиска. В июле 2026 года Microsoft официально подтвердила, что ее ИИ-система MDASH (Multi-Model Agentic Scanning Harness) анализирует критические компоненты Windows, и предупредила клиентов: объем обновлений будет только расти. Свои системы ИИ-поиска уязвимостей используют Anthropic и другие крупные разработчики. Adobe и Cisco уже объявили, что станут выпускать патчи чаще.

Второй фактор скучнее и спокойнее: часть «рекорда» — это наведение порядка в учете, а не новые дыры. Показательный случай: 19–20 июля команда безопасности ядра Linux опубликовала около 440 CVE за 48 часов. Выглядит как катастрофа, но почти все эти ошибки уже были исправлены — проект просто присвоил официальные номера старым патчам, чтобы дистрибутивам было проще отслеживать исправления.

И еще одна деталь, которую легко упустить. Рост числа найденных уязвимостей пока не означает такого же роста атак: находить дыры ИИ уже умеет, массово эксплуатировать — в заметно меньшей степени. Но окно между публикацией уязвимости и появлением рабочего эксплойта сокращается, поэтому стратегия «до нас не дойдет» перестает работать.

При чем тут ваш сайт

Новости про Patch Tuesday звучат как история про корпорации: где серверы Microsoft, а где сайт компании на виртуальном хостинге. Связь прямая. Сайт — это стопка программ: операционная система сервера, веб-сервер, PHP, база данных, CMS, ее модули и десятки сторонних библиотек. Каждый слой получает свою долю из этих 10 тыс. CVE в месяц.

Типичное возражение владельца: «Мой сайт маленький, кому он нужен». Никому — и именно поэтому он в зоне риска. Массовые атаки не выбирают жертву: сканер обходит миллионы сайтов подряд и ищет один конкретный необновленный компонент. Нашел — сайт начинает рассылать спам, раздавать вирусы или отдает базу клиентов. Известность жертвы не играет роли, играет роль только версия установленного софта.

Для сайтов на 1С-Битрикс ситуация не лучше и не хуже средней: платформа регулярно закрывает дыры, но обновления не устанавливаются сами. Какие уязвимости Битрикса стоит закрыть в первую очередь, мы разбирали отдельно, а про то, зачем вообще обновлять Битрикс, есть отдельная статья.

Где живут уязвимости сайта

Чтобы защита не превращалась в хаотичное латание, полезно понимать, из каких слоев состоит сайт и кто отвечает за каждый из них.

Главный вывод из таблицы: у большинства сайтов нет одного человека, который отвечает за все. Хостер обновляет систему, но не тронет CMS. Разработчик сдал проект и ушел. В итоге модули годами живут в версии времен запуска сайта — и это самая частая точка входа при взломе.

Защита по расписанию, а не по тревоге

Реагировать на каждую новость про уязвимости невозможно, да и не нужно. Работает другой подход — регулярный процесс, который идет независимо от новостей.

1. Инвентаризация. Составьте список: версия CMS, установленные модули, версия PHP, сторонние библиотеки. Пока списка нет, вы не знаете, что именно у вас может быть уязвимо. Один раз — час работы, дальше только поддержание.
2. Обновления по графику. Ядро CMS и модули — минимум раз в месяц, серверное ПО — по мере выхода патчей у хостера. Критические обновления безопасности — вне графика, в течение нескольких дней.
3. Подписка на уведомления вендоров. У 1С-Битрикс, у хостера и у разработчиков ключевых модулей есть рассылки и каналы с оповещениями о критических дырах. Это бесплатный мониторинг, им просто нужно начать пользоваться.
4. Резервные копии до каждого обновления. Копия файлов и базы с проверкой восстановления. Обновление изредка ломает сайт, и откат должен занимать минуты, а не сутки.
5. Меньше поверхности — меньше риска. Удалите неиспользуемые модули, темы и тестовые скрипты. Выключенный, но не удаленный плагин остается уязвимым.
6. Контроль доступа. Двухфакторная авторизация в админке, отдельные учетные записи для подрядчиков, отзыв доступов после окончания работ.
7. Периодический аудит. Раз в полгода-год смотреть на сайт целиком: версии, права на файлы, забытые поддомены, подозрительные файлы. Что проверять — есть в нашем чек-листе технического аудита.

Весь процесс занимает несколько часов в месяц. Это дешевле одного восстановления после взлома — по деньгам, по времени и по нервам.

3 ошибки, из-за которых сайты ломают

• Откладывать обновления «до после сезона». Логика понятна: не трогай то, что работает. Но уязвимость в опубликованном патче — это фактически инструкция для атакующего: вендор сам показал, где дыра. Чем дольше пауза между выходом патча и установкой, тем выше шанс, что сканеры доберутся до вас раньше.
• Обновлять только ядро CMS. Взламывают чаще через модули и плагины: их пишут маленькие команды, дыры в них закрываются медленнее, а установлены они почти на каждом сайте.
• Не иметь плана на случай взлома. Если сайт все же сломали, счет идет на часы: изоляция, восстановление из копии, смена всех паролей, поиск точки входа. Когда бэкапов нет, а доступы раскиданы по почтам бывших подрядчиков, простой растягивается на недели.

Если следить за обновлениями некому

Поток уязвимостей в ближайшие годы не уменьшится: индустрия прямо говорит, что ИИ-поиск дефектов — это новая норма. Значит, вопрос не в том, появятся ли дыры в компонентах вашего сайта, а в том, кто и когда их закроет.

Мы в Design Lab закрываем эту работу в рамках поддержки сайта: инвентаризация, обновления по регламенту с резервными копиями, мониторинг уведомлений безопасности и восстановление, если что-то пошло не так. Если у сайта давно не было ревизии — начните с аудита: он покажет, какие версии устарели и где вы уязвимы прямо сейчас.