На прошлой неделе я проснулся от уведомления Wordfence — один из клиентских сайтов получил 47 подозрительных запросов за ночь. Сначала думал, очередной сканер бродит. Но когда за три дня подряд три разных плагина получили CVE с рейтингом 9.8 — понял: это не случайность, это эпидемия. Июнь 2026 года уже побил рекорды по количеству критических уязвимостей в WordPress-плагинах. И если вы думаете, что вас это не коснётся — скорее всего, ваш сайт уже в списке целей.
Что происходит: хронология ада
Давайте просто перечислю, что произошло за последние три недели. Цифры говорят сами за себя.
6 июня — Everest Forms Pro (CVE-2026-3300). Критическая уязвимость с оценкой 9.8 из 10. Плагин для создания форм, который используется на тысячах коммерческих сайтов. Проблема — в функции Complex Calculation, которая принимает введённые пользователем данные и прогоняет их через eval(). Да, вы не ослышались. eval() на пользовательском вводе в 2026 году. Фильтр sanitize_text_field() не экранирует одинарные кавычки, что позволяет атакующему закрыть строку, внедрить произвольный PHP-код и выполнить его на сервере. Результат — злоумышленники создают учётные записи администраторов с логином diksimarina. Wordfence заблокировал более 29 300 попыток эксплуатации.
2 июня — Kirki Customizer (CVE-2026-8206). Плагин с более чем 500 000 активных установок. Уязвимость в REST API эндпоинте для сброса пароля. Плагин принимает произвольный email-адрес при запросе сброса — и отправляет ссылку на почту атакующего, а не владельца аккаунта. То есть любой, кто знает ваш логин, может получить ссылку на сброс пароля себе на почту. Никакой аутентификации не требуется. Уязвимость была в версиях 6.0.0–6.0.6, а патч вышел 18 мая — но 40% пользователей всё ещё на уязвимых версиях.
1 июня — малварь через Steam-профили. Почти 2000 WordPress-сайтов были заражены малварью, которая использует комментарии в Steam Community для скрытой передачи управляющих команд. Невидимые Unicode-символы в комментариях кодируют URL вредоносного скрипта. Сайт при каждой загрузке страницы обращается к Steam-профилю, извлекает скрытый payload и выполняет его. Ingenious и пугающе — потому что стандартные сканеры не ищут C2-трафик в Steam.
31 мая — WP Maps Pro. Уязвимость позволяет создавать учётные записи администраторов без аутентификации.
15 мая — Funnel Builder. Критическая уязвимость, через которую злоумышленники внедряют вредоносный JavaScript в страницы оформления заказа WooCommerce. Да, прямо в checkout — крадут данные кредитных карт.
15 мая — Avada Builder. Две уязвимости в плагине с миллионом установок: чтение произвольных файлов и извлечение данных из базы.
14 мая — Burst Statistics. Обход аутентификации, дающий admin-доступ.
И это ещё не всё. В мае также обнаружили, что плагин Quick Page/Post Redirect (70 000+ установок) содержал бэкдор, который был добавлен пять лет назад. Пять лет!
Считаете дальше? За один месяц — минимум 7 критических уязвимостей в популярных WordPress-плагинах, и большинство из них активно эксплуатируются в дикой природе.
Почему это происходит именно сейчас
Я вижу три основные причины этой волны.
Первая — рост автоматизации атак. Раньше злоумышленники искали уязвимости вручную или полуавтоматически. Сейчас AI-инструменты сканируют код плагинов на скорости, которой не было год назад. Находят паттерны вроде eval(), unserialize(), прямых SQL-запросов — и автоматически генерируют эксплойты.
Вторая — экономика WordPress-экосистемы. Плагинов в репозитории больше 60 000. Большинство пишутся командами из 1–3 человек, часто фрилансерами. Качество кода колеблется от отличного до «как это вообще работает». Когда плагин набирает популярность, он становится мишенью — но у разработчика нет ресурсов на полноценный security-аудит.
Третья — задержка обновлений. Everest Forms получили отчёт об уязвимости в феврале, патч выпустили в марте — а эксплуатация началась в апреле. Два месяца окон. Kirki — патч 18 мая, активная эксплуатация началась в первых числах июня. Почему? Потому что пользователи не обновляют плагины. По статистике, от выпуска патча до обновления 80% сайтов проходит от 2 недель до никогда.
Разбор технических паттернов — что искать в своём коде
Давайте разберём основные паттерны уязвимостей из этой волны. Если вы разрабатываете плагины или кастомные темы — проверьте свой код прямо сейчас.
1. eval() и динамическое выполнение кода
Everest Forms использовали eval() для вычисления формул в формах. Это классика — и это абсолютно недопустимо в коде, который принимает пользовательский ввод. Проблема не только в eval(), но и в assert(), preg_replace() с модификатором /e (хотя в PHP 8+ это убрали), create_function() и call_user_func() с непроверенными аргументами.
Что делать: Никогда не передавайте пользовательский ввод в функции динамического выполнения. Если вам нужно вычислять формулы — используйте парсер выражений с белым списком допустимых операций. Для WordPress есть библиотеки вроде symfony/expression-language с изолированной средой выполнения.
2. Небезопасные REST API эндпоинты
Kirki зарегистрировал REST API эндпоинт для сброса пароля без должной валидации. Проблема в том, что REST API WordPress — это мощный инструмент, который многие плагины используют неправильно. Частые ошибки: отсутствие permission_callback, слабая верификация email-адресов, отсутствие nonce-проверок.
Что проверять:
// ПЛОХО — нет permission_callback
register_rest_route('my-plugin/v1', '/reset-password', [
'methods' => 'POST',
'callback' => 'my_reset_handler',
]);
// ХОРОШО — с permission_callback и nonce
register_rest_route('my-plugin/v1', '/reset-password', [
'methods' => 'POST',
'callback' => 'my_reset_handler',
'permission_callback' => function() {
return wp_verify_nonce(
$_REQUEST['_wpnonce'] ?? '',
'wp_rest'
);
},
]);3. Слабая санитизация ввода
sanitize_text_field() — отличная функция, но она не экранирует одинарные кавычки. Для данных, которые попадают в SQL-запросы, нужна $wpdb->prepare(). Для данных в HTML — esc_html(), esc_attr(), esc_url(). Для данных в JavaScript — wp_json_encode(). Каждая функция санитизации предназначена для конкретного контекста.
4. Скрытые бэкдоры и supply chain
История с Quick Page/Post Redirect — это особенно страшный кейс. Бэкдор был добавлен пять лет назад и оставался незамеченным всё это время. Код был замаскирован под легитимную функциональность. Это значит, что установка «проверенного» плагина из репозитория WordPress.org больше не гарантирует безопасности.
Проверяйте код плагинов, которые используете. Особенно — файлы с base64_decode(), gzinflate(), str_rot13(), обратными вызовами из базы данных, динамическими include/require и внешними HTTP-запросами.
Практический чеклист: проверьте свой сайт прямо сейчас
Вот мой пошаговый план действий, который я реализовал на всех клиентских сайтах после этой волны. Рекомендую проделать то же самое.
Шаг 1. Обновите всё
Звучит банально, но это первое и самое важное. Проверьте:
- Ядро WordPress — обновлено ли до последней версии?
- Все плагины — особенно Everest Forms, Kirki, WP Maps Pro, Funnel Builder, Avada Builder, Burst Statistics, Quick Page/Post Redirect
- Темы — включая родительские темы, которые вы могли не обновлять
- PHP — минимум 8.1, лучше 8.2+
Если какой-то плагин не обновлялся больше 6 месяцев — серьёзно подумайте о замене. Если обновление невозможно из-за совместимости — это красный флаг.
Шаг 2. Проверьте учётные записи администраторов
Зайдите в «Пользователи» и просмотрите все аккаунты с ролью «Администратор». Ищите:
- Неизвестные аккаунты, особенно с логинами типа
diksimarina,admin1,support - Аккаунты с незнакомыми email-адресами
- Дата регистрации — если аккаунт создан недавно, а вы его не создавали, это проблема
Быстрый SQL-запрос для проверки:
SELECT user_login, user_email, user_registered
FROM wp_users u
JOIN wp_usermeta m ON u.ID = m.user_id
WHERE m.meta_key = 'wp_capabilities'
AND m.meta_value LIKE '%administrator%'
ORDER BY user_registered DESC;Шаг 3. Просмотрите логи доступа
Если у вас включён access log (а он должен быть включён), проверьте подозрительные паттерны:
- POST-запросы к
/wp-json/эндпоинтам с необычными параметрами - Множественные запросы к
wp-login.phpиxmlrpc.php - Запросы с IP-адресов
202.56.2[.]126и209.146.60[.]26(связаны с атакой на Everest Forms) - Обращения к Steam Community URLs
Шаг 4. Установите WAF, если ещё нет
Web Application Firewall — это ваш последний рубеж обороны, когда уязвимость ещё не пропатчена. Wordfence, Sucuri, Cloudflare WAF — любой из них заблокировал бы большинство атак из этой волны ещё до того, как они достигли вашего сайта.
Но WAF — не панацея. Kirki-атака, например, выглядела как обычный REST API запрос на сброс пароля. WAF её пропустит, если у вас нет кастомного правила. Именно поэтому обновления — это шаг 1.
Шаг 5. Настройте мониторинг целостности файлов
Если на ваш сайт загрузили малварь, вы должны узнать об этом немедленно, а не через месяц. Настройте мониторинг изменений в wp-content/:
- Wordfence Scanner с ежедневными проверками
- Серверный мониторинг через
AIDEилиOSSEC - Git-репозиторий для темы и кастомных плагинов (любые незакоммиченные изменения = подозрение)
Шаг 6. Проверьте подключения к внешним ресурсам
Steam-малварь научила нас новому: вредоносный код может общаться с абсолютно легитимными ресурсами. Проверьте все внешние подключения вашего сайта:
// Поиск в файлах темы и плагинов
grep -r "curl_exec\|wp_remote_get\|file_get_contents.*http"
wp-content/themes/ wp-content/plugins/
--include="*.php" -lИщите обращения к незнакомым доменам, особенно к hello-mywordl[.]info и любым Steam Community URLs.
Что делать, если ваш сайт уже взломан
Если вы обнаружили признаки компрометации — не паникуйте, но действуйте быстро.
1. Изолируйте сайт. Переведите его в режим обслуживания. Если возможно — заблокируйте доступ извне через .htaccess или nginx конфиг.
2. Сохраните логи. Скопируйте access logs, error logs, логи Wordfence — всё, что может понадобиться для анализа. Потом они могут быть перетёрты.
3. Оцените масштаб. Проверьте:
- Все пользовательские аккаунты (особенно админы)
wp-content/uploads/на наличие PHP-файловwp-content/plugins/иwp-content/themes/на модификации- Таблицу
wp_optionsна подозрительные записи (особенно_transient_записи) - Cron-задачи WordPress:
wp cron event list
4. Восстановите из бэкапа. Если у вас есть чистый бэкап от до даты взлома — это самый надёжный вариант. GoDaddy рекомендует именно это для Steam-малвари, потому что ручная очистка может не удалить все компоненты.
5. Если бэкапа нет — ручная очистка. Сравните файлы с эталонными версиями из репозитория WordPress.org. Удалите все неизвестные файлы. Сбросьте все пароли: база данных, FTP, admin-аккаунты, API-ключи. Перегенерируйте salt-ключи в wp-config.php.
6. Усиление после восстановления. Двухфакторная аутентификация для всех админов. Ограничение доступа к wp-admin по IP. Отключение XML-RPC, если не используется. Отключение регистрации пользователей, если не нужна. Отключение REST API для неавторизованных пользователей там, где это возможно.
Стратегический взгляд: как не повторять этот сценарий каждый квартал
Патч-татч-патч — это тактика. А нужна стратегия. Вот что я делаю на всех новых проектах и постепенно внедряю на старых.
Минимизация поверхности атаки. Каждый установленный плагин — это дополнительная точка отказа. Я регулярно провожу аудит плагинов: удаляю неиспользуемые, заменяйте тяжёлые многофункциональные на лёгкие специализированные. Если функционал можно реализовать 20 строками кода в functions.php — не нужен плагин.
Автоматизация обновлений. На не-критических сайтах я включаю автоматические обновления для минорных версий плагинов. Да, это может сломать что-то — но сломанный сайт ремонтируется за час, а взломанный может стоить клиенту бизнес.
// В wp-config.php
define( 'WP_AUTO_UPDATE_CORE', true );
// В functions.php — автообновление всех плагинов
add_filter( 'auto_update_plugin', '__return_true' );Регулярные бэкапы с проверкой восстановления. Бэкап, который никогда не восстанавливали — это не бэкап, это иллюзия. Настраивайте ежедневные бэкапы базы и еженедельные — файлов. Раз в месяц — тестовое восстановление на тестовом окружении.
Сегментация. WooCommerce-магазин не должен работать на том же окружении, что и блог с 20 плагинами. Разделяйте: разные инсталляции, разные базы данных, разные аккаунты хостинга. Если один сайт взломают — остальные не пострадают.
Код-ревью кастомных решений. Если вы пишете кастомные плагины или темы — найдите кого-то, кто сделает security review. Даже беглый просмотр третьим глазом находит вещи, которые вы пропустили. И да, я говорю это как человек, который тоже пропускает — потому что смотрит на свой код своими глазами.
Мой личный рейтинг рисков для лета 2026
Основываясь на текущей динамике, вот что я считаю самыми вероятными векторами атак в ближайшие месяцы:
- Плагины-конструкторы форм. Everest Forms, WPForms, Gravity Forms, Fluent Forms — все они обрабатывают пользовательский ввод и часто используют сложную логику вычислений. Каждая такая функция — потенциальный RCE. Риск: очень высокий.
- WooCommerce-расширения. Всё, что связано с платежами — лакомая цель. Funnel Builder — только начало. Ожидайте уязвимости в плагинах шлюзов оплаты, расчёта доставки, налогов. Риск: высокий.
- Page builders и темы. Kirki, Avada, и, вероятно, Elementor-расширения. Page builders — это сложный код с множеством точек входа. Риск: высокий.
- Supply chain атаки. Взлом аккаунтов разработчиков плагинов на WordPress.org с последующим внедрением вредоносного кода в обновления. Это уже происходило, и будет происходить снова. Риск: средний, но растущий.
- AI-генерированные эксплойты. Сканеры на базе LLM уже находят уязвимости, которые человек бы пропустил. Это снижает стоимость атаки и увеличивает скорость обнаружения уязвимостей. Риск: качественное изменение ландшафта угроз.
Итог и главный вывод
Волна уязвимостей лета 2026 — это не случайность. Это результат системных проблем WordPress-экосистемы: огромное количество плагинов с разным качеством кода, задержки с обновлениями у пользователей, и растущая автоматизация атак со стороны злоумышленников.
Хорошая новость: базовые меры безопасности работают. Обновления, WAF, мониторинг, бэкапы — это скучно, но это спасает. Плохая новость: «настроил и забыл» больше не работает. Безопасность — это процесс, а не состояние.
Я для себя вынес один главный урок из этой волны: если плагин выполняет eval() на пользовательском вводе — от него нужно избавляться. Неважно, насколько он удобен. Неважно, сколько стоит Pro-версия. Неважно, что он установлен на полмиллионе сайтов. Каждое использование eval() — это бомба с часовым механизмом.
А какой у вас опыт с безопасностью WordPress? Сталкивались с взломами? Какие инструменты используете для защиты? Поделитесь в комментариях — реальные кейсы всегда ценнее теоретических советов.
