WordPress под огнём: разбор уязвимостей 2026 и практический аудит безопасности

На прошлой неделе я разбирал очередной взломанный сайт клиента — WordPress-инсталляция с 40 плагинами, из которых 12 не обновлялись полгода. Сайт не просто был заражён — он служил спам-рассыльщиком уже три недели, пока клиент не заметил, что письма из формы обратной связи перестали доходить. Хостер молчал, Яндекс.Вебмастер молчал, антивирус на сервере молчал.

Знакомая картина, да?

Я открыл свежую статистику Wordfence и чуть не поперхнулся кофе: за первую неделю июня 2026 года — 160 уязвимостей в плагинах WordPress. За вторую — ещё 102. За весь 2025 год в экосистеме WordPress обнаружено 11 334 новые уязвимости — это на 42% больше, чем годом ранее. И 46% из них были не закрыты на момент публикации.

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

Что вообще происходит: свежие уязвимости

Прежде чем нырять в рекомендации, посмотрим, что конкретно ломали в последние месяцы. Реальные плагины, которые стоят на тысячах сайтов.

Gravity SMTP (CVE-2026-4020). Уязвимость в популярном плагине для email-отправки. Злоумышленники через неё получали доступ к API-ключам, OAuth-токенам и системным данным. Ваш плагин для почты сам сливает ключи от интеграции с почтовым сервисом. Exploit появился в открытом доступе, атака активно используется.

Everest Forms Pro (CVE-2026-3300). CVSS 9.8 из 10. Это практически максимум. Уязвимость позволяет полный захват сайта, патча на момент обнаружения не было. Около 4000 сайтов под прямой угрозой.

Массовые патчи в марте 2026. Elementor (10 млн установок), Yoast SEO (10 млн), WPForms — все закрыли серьёзные уязвимости в одном месяце. Когда четыре самых популярных плагина одновременно латются — это сигнал, что автоматизированные сканеры уже вовсю ищут дыры.

И вот что самое неприятное: медианное время от публикации эксплойта до массовой эксплуатации составляет 5 часов. Пять часов. Если вы не обновили плагин в день выхода патча, вы уже уязвимы.

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

Есть соблазн сказать: «Ну стоит же Wordfence, что ещё надо». Я тоже так думал, пока не посмотрел данные: классические защиты хостинга блокируют только 26% атак. Три из четырёх проходят мимо базового фильтра.

Причин несколько:

Уязвимости появляются быстрее, чем патчатся. В июне 2026 года каждую неделю публикуется 100–160 новых уязвимостей. Ни одна команда не успевает закрыть всё вручную. Автоматические обновления помогают, но ломают совместимость — и вот вы уже отключили auto-updates, потому что после одного из них упала вёрстка.

Вектор атаки сместился на плагины, а не на ядро. Сам WordPress 7.0 Armstrong — достаточно безопасный продукт. Но экосистема из 60 000+ плагинов в каталоге — это поле для атак. Плагины пишут разработчики разного уровня, ревью в каталоге формальное, и уязвимости типов SQL-инъекций и privilege escalation находятся регулярно.

Боты стали умнее. Раньше боты тупо сканировали /wp-admin/ и пробовали дефолтные пароли. Сейчас они используют свежие CVE в течение часов после публикации, эксплуатируют chain-уязвимости (ядро → плагин → тема) и маскируются под легитимный трафик.

Пошаговый аудит: что я делаю на клиентских сайтах

Окей, достаточно страшилок. Вот мой чеклист — то, что я прогоняю на каждом клиентском сайте при аудите безопасности.

Шаг 1. Инвентаризация — что у вас вообще стоит

Первое, что я делаю — составляю полную карту: ядро, тема, все плагины с версиями. Без этого остальной аудит бессмысленен.

# Быстрый способ получить список через WP-CLI
wp plugin list --format=csv --fields=name,status,version,update_type
wp theme list --format=csv
wp core version

Я сохраняю это в таблицу и сравниваю с актуальными версиями в каталоге. Сразу видно: какие плагины отстали на мажорную версию, какие заброшены автором, какие надо заменять.

Правило: если плагин не обновлялся автором больше 12 месяцев — он технический долг. Неважно, работает ли он. Уязвимость в нём будет найдена, и её никто не закроет.

Шаг 2. Проверка через профессиональные сканеры

Бесплатного Wordfence Scan достаточно для базовой проверки, но для серьёзного аудита я использую связку:

WPScan — сканирует известные уязвимости в базе данных WordPress Vulnerability Database
Nuclei — шаблонный сканер с тысячами готовых проверок
PHP CodeSniffer с правилами WordPress Coding Standards — статический анализ кода кастомных тем и плагинов

# WPScan — быстрое сканирование сайта
wpscan --url https://example.ru --enumerate vp,vt,u \
  --api-token YOUR_TOKEN

# Nuclei — проверка на известные CVE
nuclei -u https://example.ru -t cves/ -severity high,critical

WPScan с API-токеном (бесплатный, нужно зарегистрироваться) даёт доступ к актуальной базе уязвимостей. Nuclei ловит то, что WPScan может пропустить — особенно в нестандартных конфигурациях.

Шаг 3. Жёсткая чистка плагинов

Это больная тема. Каждый клиент приходит с 30–50 плагинами, из которых 15 не используются, но «а вдруг понадобится». Нет — не понадобится.

Вот мой процесс:

Деактивирую всё, что не используется. Не удаляю — сначала деактивирую, наблюдаю неделю.
Проверяю зависимости. Иногда плагин нужен другому плагину (кэш-плагин зависит от оптимизации изображений). Разбираю цепочки.
Удаляю деактивированные. Код плагина доступен даже в деактивированном состоянии через прямые запросы к файлам PHP. Поэтому удаляю физически.
Заменяю монструозные плагины. Если стоит плагин «всё-в-одном» на 50 МБ ради одной функции — заменяю на специализированное решение.
Целевое количество плагинов: до 15. Всё, что выше — это увеличение поверхности атаки без обоснованной пользы.

Шаг 4. Защита admin-зоны

wp-admin — это самая атакуемая точка WordPress. Вот что я делаю:

Двухфакторная аутентификация. Обязательно. Не опционально. Использую плагин Two Factor (от разработчиков ядра WordPress) — он поддерживает TOTP, backup-коды и hardware-ключи.

Ограничение доступа по IP на уровне сервера:

# nginx — ограничение wp-admin по IP
location /wp-admin/ {
    allow 192.168.1.0/24;
    allow 10.0.0.5;
    deny all;
}

location /wp-login.php {
    allow 192.168.1.0/24;
    allow 10.0.0.5;
    deny all;
}

Если у клиента динамический IP — ставлю защиту через пароль на уровне HTTP (Basic Auth поверх обычного логина) + rate limiting на попытки входа.

Переименование wp-login.php. Спорно. Боты всё равно находят, но снижает шум в логах. Не первая приоритетность, но делаю.

Шаг 5. Файловые права и права на сервере

Классическая ошибка: chmod 777 на всю директорию WordPress «чтобы работало». Этого достаточно для full takeover.

Вот правильная схема:

# Директории — 755
find /var/www/wordpress -type d -exec chmod 755 {} \;

# Файлы — 644
find /var/www/wordpress -type f -exec chmod 644 {} \;

# wp-config.php — 600, только владелец
chmod 600 wp-config.php

# Владелец файлов — веб-сервер, не root
chown -R www-data:www-data /var/www/wordpress

Если хостинг не даёт SSH, тот же эффект через панель управления. Но я настоятельно рекомендую переезжать на хостинг с SSH-доступом.

Шаг 6. WAF и блокировка на уровне сервера

Web Application Firewall работает на уровне сервера, а не как плагин WordPress. Два варианта:

Cloudflare (бесплатный план). Включаете Proxy + Bot Fight Mode + Managed Rules для WordPress. Бесплатного плана достаточно для большинства сайтов. Дополнительно получаете CDN и защиту от DDoS.

ModSecurity на сервере. Если вы на VPS — ставлю ModSecurity с OWASP Core Rule Set:

# Установка на Ubuntu/Debian
apt install libapache2-mod-security2
a2enmod security2

# Включение OWASP CRS
cd /etc/modsecurity
git clone https://github.com/coreruleset/coreruleset.git
mv coreruleset/crs-setup.conf.example crs-setup.conf

ModSecurity блокирует SQL-инъекции, XSS, и аномальные запросы ещё до того, как они дойдут до WordPress.

Шаг 7. Резервное копирование — ваша последняя линия

Я видел сайты, где единственный backup хранился на том же сервере. Когда сервер скомпрометировали — бэкап удалили вместе с сайтом.

Правило 3-2-1:

1. - 3 копии данных
  - 2 разных типа хранилища
  - 1 копия offsite (в облаке, на отдельном сервере)

Плагин UpdraftPlus настроен на ежедневный бэкап в два облачных хранилища (например, Google Drive + Dropbox). Проверяю восстановление раз в квартал — бэкап, который не протестирован, не существует.

Автоматизация: что должно работать без вас

Ручной аудит — это отлично, но защиты хватает на пару месяцев. Потом появляются новые уязвимости, и всё начинается заново. Вот что я настраиваю для постоянной защиты:

Автоматические обновления ядра WordPress. Мелкие релизы (security patches) — включены по умолчанию с версии 5.6, но проверяю, что никто их не отключил.

// wp-config.php — включить автообновление ядра
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Автоматические обновления плагинов. С WordPress 5.5 это работает из коробки, но разработчики отключают из-за страха совместимости. Мой подход: включаю для всех плагинов, мониторю после крупных обновлений, откатываюсь через WP-CLI если что-то сломалось.

# Включить автообновление всех плагинов
wp plugin auto-updates enable --all

# Если после обновления что-то сломалось — быстрый откат
wp plugin deactivate problematic-plugin
wp plugin update problematic-plugin --version=2.3.1

Мониторинг изменений файлов. Плагин Wordfence или WP Security Audit Log присылает уведомление, если файлы в wp-content изменились без моего ведома. Это ранний индикатор compromise.

Uptime-мониторинг с проверкой содержимого. Не просто «сайт отвечает 200 OK», а проверка, что на странице нет iframe-инъекций или странных redirect-ов. UptimeRobot бесплатный план покрывает базовые нужды.

Что не работает: мифы о безопасности WordPress

За годы работы я слышал одно и то же. Разберём:

«У меня маленький сайт, кого его взламывать». Ботам всё равно, какой у вас трафик. Они сканируют весь интернет по диапазонам IP. Сайт из трёх страниц с десятью посетителями в день используется как спам-релей или прокси, трафик для этого не нужен.

«Wordfence установлен, я в безопасности». Wordfence — хороший сканер, но работает постфактум. Он найдёт заражённый файл после того, как атака уже прошла. Бесплатный WAF ограничен, и 87,8% атак проходят мимо стандартных защит.

«У меня сложный пароль, не подберут». Брутфорс — не основной вектор атаки в 2026 году. Эксплойты плагинов — вот что реально ломает сайты. Сложный пароль не спасёт от SQL-инъекции в форме обратной связи.

«HTTPS достаточно». SSL защищает данные в транзите, но не защищает от эксплуатации уязвимостей в коде. Сайт с валидным сертификатом может быть полностью скомпрометирован.

Чеклист: что сделать прямо сегодня

Если вы дочитали до сюда — вот выжимка. Сделайте это на этой неделе:

Обновите всё. Ядро, темы, плагины. Зайдите в /wp-admin/updates.php/ — там видно всё сразу.
Удалите неиспользуемые плагины. Не деактивируйте — удалите.
Включите двухфакторную аутентификацию для всех админ-аккаунтов.
Проверьте права на файлы — wp-config.php должен быть 600.
Настройте резервное копение по правилу 3-2-1, если ещё не настроено.
Поставьте Cloudflare перед сайтом — 10 минут настройки, бесплатно.
Прогоните WPScan и закройте найденные уязвимости.
Проверьте список пользователей с ролью Administrator. Должно быть минимально возможное количество.

Итог

WordPress в 2026 году — это экосистема с 11 000+ уязвимостей в год и медианным временем эксплуатации в 5 часов. Рассчитывать на то, что «пока не сломали — значит работает» — нельзя. Аудит безопасности — это не разовая акция, а процесс. Но если сделать первые 8 шагов из чеклиста выше, вы закроете 90% реальных векторов атаки.

А как у вас обстоят дела с безопасностью сайтов? Есть любимые инструменты или ритуалы аудита? Поделитесь в комментариях — всегда интересно узнать, как другие подходят к этому вопросу.