В прошлом месяце ко мне обратился клиент: «Гена, сайт перестал открываться, браузер орёт про фишинг, а Google пометил его как вредоносный». Захожу — классика. В админке три новых пользователя с ролью администратора, в корне лежит webshell, а в .htaccess прописаны редиректы на мошеннический лендинг. Причина? Плагин для форм обратной связи, который не обновляли два года. Уязвимость типа Arbitrary File Upload — и вот уже посторонний человек спокойно заливает PHP-файлы в uploads.
Эта история — не исключение. Она повторяется каждый день. И 2026 год бьёт рекорды по количеству уязвимостей в экосистеме WordPress. Давайте разберём картину угроз, а затем — пошаговый чек-лист аудита безопасности, который я использую в своей практике.
Картина угроз в 2026 году: почему прямо сейчас
Начну с цифр, потому что они отрезвляют.
78 уязвимостей за одну неделю. По данным Wordfence Intelligence, только за неделю 11–17 мая 2026 года было раскрыто 78 уязвимостей в 62 плагинах и 2 темах WordPress. Неделей ранее, 4–10 мая, — ещё 75 уязвимостей в 59 плагинах и 2 темах. Это не опечатка. Полторы сотни новых дыр за две недели.
Avada Builder — миллион сайтов под ударом. 21 марта 2026 года в Wordfence поступил отчёт об уязвимостях типа Arbitrary File Read и SQL Injection в плагине Avada Builder. Затронуто более 1 000 000 сайтов. Патчи вышли в апреле и мае, но сколько сайтов до сих пор не обновлены — вопрос. SQL Injection в конструкторе страниц означает, что злоумышленник может читать содержимое базы данных: логины, хеши паролей, данные пользователей, заказы WooCommerce.
Плагины обгоняют операционные системы. Согласно отчёту Sequretek Threat Intel Report 2026, уязвимости в плагинах WordPress теперь опережают уязвимости операционных систем по частоте эксплуатации. Раньше главными векторами атак были уязвимости в Windows/Linux и сетевых протоколах. Сегодня злоумышленнику проще найти дыру в плагине с 50 000 активных установок, чем искать zero-day в ядре ОС.
Социальная инженерия эволюционирует. Тот же отчёт Sequretek фиксирует сдвиг от классического фишинга к «когнитивной эксплуатации» — атакам, построенным на данных из социальных сетей. Злоумышленник изучает владельца сайта, находит слабые места и отправляет персонализированное письмо «от хостинг-провайдера» или «от поддержки WordPress».
Другие громкие CVE весны 2026:
– CVE-2026-3551 — Stored XSS в плагине Custom New User Notification. Позволяет внедрить скрипт, который срабатывает у любого администратора, зашедшего в админку.
– CVE-2026-1945 — Stored XSS в плагине WPBookit (бронирования). Похожий сценарий: злоумышленник оставляет вредоносный код в поле бронирования, администратор открывает заявку — скрипт исполняется.
– Уязвимость в плагинах членства — эксплуатация позволяет создавать учётные записи администратора через манипуляции с регистрацией.
Общий знаменатель: 90% взломов WordPress происходят через плагины, а не через ядро. Ядро WordPress образца 2026 года — один из самых защищённых компонентов экосистемы с открытым кодом. Но оно бессильно, когда вы ставите плагин от неизвестного разработчика, который не обновлялся год.
Методология аудита: как я подхожу к проверке
Прежде чем давать чек-лист, расскажу о логике, которую я применяю. Аудит безопасности сайта — это не разовая акция. Это процесс, который я разбиваю на три слоя:
Слой 1: Поверхностный (30 минут). То, что видно снаружи и из админки. Версии ядра, плагинов и PHP. Активные пользователи. Подозрительные файлы в директориях. Этот слой закрывает 70% типовых проблем.
Слой 2: Конфигурационный (1–2 часа). Серверная часть. Права доступа к файлам. wp-config.php. Заголовки безопасности. Отключение неиспользуемых функций (XML-RPC, REST API для неавторизованных). Этот слой делает взлом существенно сложнее даже при наличии уязвимости.
Слой 3: Мониторинговый (постоянный). Автоматическое сканирование, журналы изменений, оповещения о подозрительной активности. Без этого слоя вы узнаете о взломе только когда Google пришлёт уведомление — или когда клиенты начнут жаловаться.
В этом порядке и пойдём.
Чек-лист: 10 шагов аудита безопасности WordPress
1. Инвентаризация плагинов и тем
Первое, что я делаю — составляю реестр всего, что установлено. Это занимает 10 минут и даёт полную картину.
Что проверять:
– Список всех активных и неактивных плагинов
– Список всех установленных тем (даже неактивных!)
– Дата последнего обновления каждого компонента
– Источник: официальный репозиторий или сторонний разработчик
– Количество активных установок (косвенный показатель поддерживаемости)
Инструменты: WP-CLI — wp plugin list --format=table и wp theme list --format=table.
Красные флаги:
– Плагин не обновлялся более 12 месяцев
– Плагин от неизвестного разработчика без сайта и поддержки
– Плагин закрыт/удалён из репозитория WordPress.org
– Менее 1000 активных установок без активного комьюнити
– Плагин с известными CVE без патча
Что делать: Удалить неактивные плагины и темы. Для активных — проверить каждый на наличие известных уязвимостей через Wordfence Vulnerability Database или WPScan. Заменить плагины из «красной зоны» на аналоги с активной поддержкой.
Из практики: на среднестатистическом сайте у клиента я нахожу 3–5 неиспользуемых плагинов и как минимум одну неактивную тему, которая тянет за собой устаревшие библиотеки с известными уязвимостями. Удаление занимает минуту. Потенциальный ущерб от неудаления — компрометация сайта.
2. Обновление всего и вся
Это очевидно, но 80% сайтов, которые попадают ко мне на аудит, имеют отложенные обновления.
План действий:
1. Сделать полный бэкап (файлы + база данных) — это не обсуждается
2. Обновить ядро WordPress до последней версии
3. Обновить все плагины и темы
4. Проверить PHP — версия ниже 8.1 в 2026 году это дыра сама по себе (PHP 7.4 и 8.0 больше не получают обновлений безопасности)
5. Проверить версию MySQL/MariaDB
Автоматические обновления: Для ядра WordPress — включить автообновления минорных версий (major-обновления лучше ставить вручную, предварительно протестировав). Для плагинов — настроить выборочные автообновления для проверенных плагинов из официального репозитория.
Кейс Avada Builder — показательный. Патч вышел, но миллион сайтов остаются уязвимыми просто потому, что никто не нажал кнопку «Обновить». Автообновления решили бы эту проблему.
3. Аудит пользователей и паролей
Человеческий фактор — самое слабое звено. За годы практики я видел админки, где:
– 15 пользователей с ролью администратора (из них 5 — бывшие сотрудники)
– Логин admin с паролем admin123
– Пароль от админки совпадает с паролем от FTP и баз данных
– Нет двухфакторной аутентификации ни у кого
Чек-лист:
– Удалить неиспользуемые учётные записи
– Понизить роли: не каждому контент-менеджеру нужен администратор
– Сменить все пароли на уникальные (минимум 16 символов, менеджер паролей)
– Включить двухфакторную аутентификацию для всех администраторов и редакторов
– Запретить логин admin — это первые 3 попытки любого брутфорса
– Установить лимит попыток входа (плагин Limit Login Attempts Reloaded или аналогичный)
4. Сканирование на вредоносный код
Даже если сайт выглядит нормально, это не гарантирует отсутствия закладок. Современные вредоносы умеют прятаться: они не ломают сайт, а тихо собирают данные, рассылают спам или майнят криптовалюту.
Что проверять:
– Файлы в wp-content/uploads/ на наличие PHP-скриптов (там должны быть только медиафайлы)
– wp-config.php, .htaccess, index.php в корне — на предмет чужеродных вставок
– Папки wp-content/plugins/ и wp-content/themes/ — на неизвестные файлы
– Базу данных на предмет скрытых пользователей-администраторов
Инструменты:
– Wordfence (бесплатная версия) — сканирует файлы на сигнатуры вредоносного кода
– WP-CLI + grep: wp eval 'echo ABSPATH;' → затем grep -r "base64_decode\|eval(\|gzinflate\|shell_exec" /path/to/site/
– Sucuri SiteCheck (онлайн) — проверка сайта снаружи, сигнатуры вредоносного кода, статус в чёрных списках
Особое внимание: wp-content/uploads/. Если там лежат .php файлы — это почти гарантированный webshell.
5. Права доступа к файлам и директориям
Это серверный уровень, который часто упускают. Неправильные права доступа позволяют одному скомпрометированному плагину перезаписать файлы всего сайта.
Рекомендованные права:
– Директории: 755 (rwxr-xr-x)
– Файлы: 644 (rw-r–r–)
– wp-config.php: 600 или 640 (только для чтения владельцем)
– .htaccess: 644 (запись только владельцем)
Критические ограничения:
– Запретить выполнение PHP в wp-content/uploads/ через .htaccess или nginx-конфиг
– Отключить просмотр директорий (Options -Indexes)
– Запретить прямой доступ к wp-config.php
6. Блокировка неиспользуемых векторов атак
WordPress из коробки включает ряд функций, которые на большинстве сайтов не нужны, но активно эксплуатируются злоумышленниками.
XML-RPC (wp-xmlrpc.php): Используется для удалённой публикации и мобильных приложений. В 2026 году практически не нужен — REST API покрывает все задачи. Но остаётся вектором для брутфорса (метод system.multicall позволяет перебирать сотни паролей за один HTTP-запрос).
Решение: Отключить через .htaccess:
“apache`
Order Deny,Allow
Deny from all
Или через фильтр в functions.php:
REST API для неавторизованных: По умолчанию WordPress раскрывает список пользователей через REST API (/wp-json/wp/v2/users), что даёт злоумышленнику готовый список логинов для брутфорса.
Решение: Ограничить доступ к REST API для неавторизованных пользователей — плагин Disable REST API или кастомный сниппет.
Вывод информации о версии: WordPress по умолчанию добавляет мета-тег с версией в head. Это помогает злоумышленнику быстро определить уязвимую версию. Убирается через remove_action(‘wp_head’, ‘wp_generator’);
7. Заголовки безопасности (Security Headers)
HTTP-заголовки безопасности — это первый эшелон защиты от XSS, clickjacking, MIME-sniffing и других клиентских атак.
Минимальный набор для 2026 года:
– Content-Security-Policy (CSP): Ограничивает источники скриптов, стилей, изображений. Самый мощный и самый сложный в настройке заголовок. Для WordPress рекомендую строить через плагин HTTP Headers.
– X-Frame-Options: SAMEORIGIN — защита от clickjacking
– X-Content-Type-Options: nosniff — запрет MIME-type sniffing
– Strict-Transport-Security (HSTS): max-age=31536000 — принудительный HTTPS
– Referrer-Policy: strict-origin-when-cross-origin — контроль утечки реферера
– Permissions-Policy: ограничение доступа к API браузера (камера, микрофон, геолокация)
Проверить текущие заголовки можно через [securityheaders.com](https://securityheaders.com). Оценки выше «C» добиться непросто из-за внешних скриптов (Google Fonts, шрифты, аналитика), но стремиться надо к «B» как минимум.
8. SSL/TLS и безопасность передачи данных
В 2026 году сайт без HTTPS — это красный флаг не только для пользователей, но и для поисковых систем. Но наличие сертификата не равно безопасности.
Что проверять:
– Сертификат действителен и настроено автообновление (Let’s Encrypt + Certbot или встроенное решение хостинга)
– Редирект HTTP → HTTPS работает корректно
– Версия TLS: минимум 1.2, рекомендуется 1.3
– Отключены устаревшие и небезопасные протоколы (SSLv2, SSLv3, TLS 1.0, TLS 1.1)
– HSTS заголовок настроен (см. пункт 7)
Проверить: [SSL Labs](https://www.ssllabs.com/ssltest/) — оценка должна быть A или A+.
9. Резервное копирование и план восстановления
Безопасность — это не только предотвращение, но и способность восстановиться. Если сайт взломали, а бэкапа нет или он хранится на том же сервере — вы в ловушке.
Правило 3-2-1:
– 3 копии данных
– 2 разных носителя
– 1 копия вне основной инфраструктуры
Практические рекомендации:
– Ежедневные бэкапы базы данных (она меняется чаще всего)
– Еженедельные полные бэкапы (файлы + база)
– Хранить минимум 30 дней истории
– Бэкапы хранить ВНЕ сервера: облачное хранилище (S3, Яндекс.Облако, Google Drive), отдельный FTP
– Регулярно проверять восстановление из бэкапа
Плагины: UpdraftPlus, BackWPup, BlogVault. Для серьёзных проектов — бэкап на уровне сервера (JetBackup в cPanel, снапшоты VPS).
10. Настройка мониторинга и оповещений
Аудит проведён, уязвимости закрыты. Но это состояние «здесь и сейчас». Через неделю выйдет новый плагин с новой дырой. Нужен постоянный мониторинг.
Что мониторить:
– Изменения файлов (File Integrity Monitoring) — Wordfence, Sucuri, WP Security Audit Log
– Попытки входа (успешные и неуспешные) — алерты на новые IP, множественные неудачи
– Изменения в базе данных — новые пользователи, смена ролей, новые плагины
– Доступность сайта (UptimeRobot, HetrixTools) — DDoS или дефейс сразу заметите
– Уязвимости в установленных плагинах — Wordfence Central или WPScan (email-оповещения о новых CVE)
Инструментарий: что я использую в работе
После десятков аудитов у меня сложился набор инструментов, который покрывает все слои проверки:
Бесплатный минимум:
– Wordfence Free — сканер файлов + файрвол (базовые правила)
– WP-CLI — всё, что можно сделать из командной строки быстрее, чем из админки
– Sucuri SiteCheck — внешняя проверка онлайн
– securityheaders.com — оценка заголовков
– SSL Labs — проверка TLS
– UpdraftPlus — бэкапы
Платный уровень (для коммерческих сайтов):
– Wordfence Premium — real-time сигнатуры угроз, страновые блокировки
– Sucuri Platform — внешний файрвол + мониторинг + удаление вредоносов
– WPScan CLI — автоматизированное сканирование уязвимостей (API-ключ даёт доступ к базе CVE)
– Cloudflare Pro — WAF (Web Application Firewall) на уровне DNS, защита от DDoS
Серверный уровень (для VPS/выделенных серверов):
– fail2ban — блокировка IP после неудачных попыток входа по SSH и через wp-login.php
– ModSecurity — файрвол уровня веб-сервера с правилами OWASP
– rkhunter / chkrootkit — поиск руткитов на сервере
Hardening: что делать после аудита
Аудит — это диагностика. Hardening — это лечение. Вот действия, которые превращают результаты аудита в реальную защиту:
wp-config.php:
`php
// Отключение редактора файлов в админке
define('DISALLOW_FILE_EDIT', true);
// Отключение установки плагинов/тем из админки (для продакшена)
define(‘DISALLOW_FILE_MODS’, true);
// Принудительный HTTPS для админки и логина
define(‘FORCE_SSL_ADMIN’, true);
// Смена префикса таблиц (при установке, задним числом сложно)
$table_prefix = ‘wp_custom_’;
// Уникальные ключи и соли — сгенерировать через https://api.wordpress.org/secret-key/1.1/salt/
`
.htaccess (корень сайта):
`apache
# Запрет выполнения PHP в uploads
Require all denied
# Защита wp-config.php
Require all denied
# Запрет просмотра директорий
Options -Indexes
# Блокировка xmlrpc
Require all denied
`
Отключение ненужного через functions.php:
`php
// Отключить XML-RPC
add_filter('xmlrpc_enabled', '__return_false');
// Убрать версию WordPress из head
remove_action(‘wp_head’, ‘wp_generator’);
// Убрать версию из скриптов и стилей
function remove_version_from_assets($src) {
if (strpos($src, ‘ver=’)) {
$src = remove_query_arg(‘ver’, $src);
}
return $src;
}
add_filter(‘style_loader_src’, ‘remove_version_from_assets’, 9999);
add_filter(‘script_loader_src’, ‘remove_version_from_assets’, 9999);
“
Подытожим
Безопасность WordPress в 2026 году — это не про «поставил плагин и забыл». Картина угроз показывает, что злоумышленники целенаправленно работают с экосистемой плагинов. 78 уязвимостей в неделю, миллион сайтов под ударом из-за одного конструктора страниц, плагины как главный вектор атак.
Что я вынес из практики: самый опасный плагин — тот, про который вы забыли. Второй по опасности — тот, который вы поставили «на попробовать» полгода назад и не обновили ни разу. Третий —nulled-плагин, скачанный с варезного сайта, потому что «зачем платить 50 долларов».
Проведите аудит по чек-листу выше. Это займёт от 30 минут до пары часов в зависимости от размера сайта. Если найдёте что-то подозрительное — не откладывайте. Avada Builder показал, что от уязвимости до массовой эксплуатации проходит меньше времени, чем занимает чтение этой статьи.
А какой самый неожиданный вектор атаки встречали вы? Может, находили вредоносный код в неожиданном месте или сталкивались с особенно хитрым взломом? Расскажите в комментариях — интересно сравнить опыт.
Данные: Wordfence Intelligence Weekly Reports (май 2026), Sequretek Threat Intel Report 2026, NVD/CVE database, TechRadar Pro.
