Июль 2026 года поставил рекорд: почти 10 тыс. опубликованных уязвимостей за месяц, и искали их уже не только люди, но и нейросети. Технический директор Design Lab объясняет, что этот поток значит для обычного сайта и как выстроить защиту без круглосуточного дежурства.
Рекорд, которого не было двадцать лет
Уязвимости в программах теперь ищут не только исследователи и злоумышленники. Их ищут нейросети, и делают это быстрее людей. Результат уже в статистике: за июль 2026 года опубликовано почти 10 тыс. уязвимостей (CVE) — месячный рекорд за всю историю наблюдений. Критических и высокоопасных среди них в 3,5 раза больше, чем на предыдущем пике (оценка аналитиков Epoch AI, август 2026).
Масштаб хорошо виден на примере вендоров. Microsoft в июльский «вторник патчей» закрыла 570 уязвимостей — втрое больше предыдущего, тоже рекордного пакета. Oracle за тот же месяц выпустила 1235 исправлений. За первые шесть месяцев 2026 года Microsoft устранила больше дефектов, чем за любой полный год за двадцать лет наблюдений.
Программы не стали хуже. Дыры в них были всегда. Изменилось другое: их научились находить массово.
Откуда волна: уязвимости ищет ИИ
Главная причина роста — автоматизация поиска. В июле 2026 года Microsoft официально подтвердила, что её
Второй фактор скучнее и спокойнее: часть «рекорда» — это наведение порядка в учёте, а не новые дыры. Показательный случай:
И ещё одна деталь, которую легко упустить. Рост числа найденных уязвимостей пока не означает такого же роста атак: находить дыры ИИ уже умеет, массово эксплуатировать — в заметно меньшей степени. Но окно между публикацией уязвимости и появлением рабочего эксплойта сокращается, поэтому стратегия «до нас не дойдёт» перестаёт работать.
При чём тут ваш сайт
Новости про Patch Tuesday звучат как история про корпорации: где серверы Microsoft, а где сайт компании на виртуальном хостинге. Связь прямая. Сайт — это стопка программ: операционная система сервера,
Типичное возражение владельца: «Мой сайт маленький, кому он нужен». Никому — и именно поэтому он в зоне риска. Массовые атаки не выбирают жертву: сканер обходит миллионы сайтов подряд и ищет один конкретный необновлённый компонент. Нашёл — сайт начинает рассылать спам, раздавать вирусы или отдаёт базу клиентов. Известность жертвы не играет роли, играет роль только версия установленного софта.
Для сайтов на
Где живут уязвимости сайта
Чтобы защита не превращалась в хаотичное латание, полезно понимать, из каких слоёв состоит сайт и кто отвечает за каждый из них.
| Слой | Примеры | Кто обычно отвечает |
|---|---|---|
| Операционная система и серверное ПО | Linux, nginx, Apache, PHP, MySQL | Хостер или системный администратор |
| Ядро CMS | Подрядчик по поддержке сайта | |
| Модули и плагины | Готовые решения из маркетплейса, платёжные модули | Подрядчик по поддержке сайта |
| Сторонние | Слайдеры, галереи, старый jQuery | Разработчик сайта |
| Интеграции | Обмен с CRM, доставкой, оплатой | Разработчик интеграции |
Главный вывод из таблицы: у большинства сайтов нет одного человека, который отвечает за всё. Хостер обновляет систему, но не тронет CMS. Разработчик сдал проект и ушёл. В итоге модули годами живут в версии времён запуска сайта — и это самая частая точка входа при взломе.
Защита по расписанию, а не по тревоге
Реагировать на каждую новость про уязвимости невозможно, да и не нужно. Работает другой подход — регулярный процесс, который идёт независимо от новостей.
- Инвентаризация. Составьте список: версия CMS, установленные модули, версия PHP, сторонние библиотеки. Пока списка нет, вы не знаете, что именно у вас может быть уязвимо. Один раз — час работы, дальше только поддержание.
- Обновления по графику. Ядро CMS и модули — минимум раз в месяц, серверное ПО — по мере выхода патчей у хостера. Критические обновления безопасности — вне графика, в течение нескольких дней.
- Подписка на уведомления вендоров. У
1С-Битрикс , у хостера и у разработчиков ключевых модулей есть рассылки и каналы с оповещениями о критических дырах. Это бесплатный мониторинг, им просто нужно начать пользоваться. - Резервные копии до каждого обновления. Копия файлов и базы с проверкой восстановления. Обновление изредка ломает сайт, и откат должен занимать минуты, а не сутки.
- Меньше поверхности — меньше риска. Удалите неиспользуемые модули, темы и тестовые скрипты. Выключенный, но не удалённый плагин остаётся уязвимым.
- Контроль доступа. Двухфакторная авторизация в админке, отдельные учётные записи для подрядчиков, отзыв доступов после окончания работ.
- Периодический аудит. Раз в
полгода-год смотреть на сайт целиком: версии, права на файлы, забытые поддомены, подозрительные файлы. Что проверять — есть в нашемчек-листе технического аудита.
Весь процесс занимает несколько часов в месяц. Это дешевле одного восстановления после взлома — по деньгам, по времени и по нервам.
Три ошибки, из-за которых сайты ломают
- Откладывать обновления «до после сезона». Логика понятна: не трогай то, что работает. Но уязвимость в опубликованном патче — это фактически инструкция для атакующего: вендор сам показал, где дыра. Чем дольше пауза между выходом патча и установкой, тем выше шанс, что сканеры доберутся до вас раньше.
- Обновлять только ядро CMS. Взламывают чаще через модули и плагины: их пишут маленькие команды, дыры в них закрываются медленнее, а установлены они почти на каждом сайте.
- Не иметь плана на случай взлома. Если сайт всё же сломали, счёт идёт на часы: изоляция, восстановление из копии, смена всех паролей, поиск точки входа. Когда бэкапов нет, а доступы раскиданы по почтам бывших подрядчиков, простой растягивается на недели.
Если следить за обновлениями некому
Поток уязвимостей в ближайшие годы не уменьшится: индустрия прямо говорит, что
Мы в Design Lab закрываем эту работу в рамках поддержки: инвентаризация, обновления по регламенту с резервными копиями, мониторинг уведомлений безопасности и восстановление, если
