На прошлой неделе я разбирал очередной взломанный сайт клиента — 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:
-
-
- 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% реальных векторов атаки.
А как у вас обстоят дела с безопасностью сайтов? Есть любимые инструменты или ритуалы аудита? Поделитесь в комментариях — всегда интересно узнать, как другие подходят к этому вопросу.
