Блог

CVE-2026-3300: WordPress-плагин Everest Forms Pro выполняет чужой PHP-код

CVE-2026-3300_WordPress-plugin_Everest
CVE / Linux / Wordpress / Безопасность

CVE-2026-3300: WordPress-плагин Everest Forms Pro выполняет чужой PHP-код

Ваш сайт принимает заявки через форму обратной связи. Кто-то заполняет поле «Имя» — и на сервере выполняется произвольный PHP-код. Не потому что взломали базу данных, не потому что угадали пароль. Просто потому что в поле формы можно было вписать что угодно, а плагин передавал это напрямую в PHP-функцию eval().

Именно так работает CVE-2026-3300 — критическая уязвимость в плагине Everest Forms Pro для WordPress, CVSS 9.8. Уязвимы все версии до 1.9.12 включительно. Патч вышел 18 марта 2026 года — версия 1.9.13. Активная эксплуатация началась 13 апреля. По данным Wordfence, к началу июня файрвол заблокировал более 29 300 попыток эксплойта, из них свыше 17 900 — только 16 мая. Атаки продолжаются.

ЧТО ТАКОЕ EVEREST FORMS PRO

Everest Forms Pro — коммерческий плагин от WPEverest, надстройка над бесплатным Everest Forms. Его ставят тогда, когда стандартной формы уже не хватает: нужна многошаговая анкета с условными полями, форма записи с выбором времени, расчёт стоимости прямо в форме без перехода в корзину. Типичные пользователи — небольшие интернет-магазины, сервисные компании, агентства, которым нужна форма заказа с динамическим ценообразованием. Около 4 000 активных установок по данным Wordfence — цифра скромная, но это не защита: ботнеты не выбирают цели по популярности плагина, они сканируют всё подряд.

Уязвимой оказалась конкретная функциональность Pro-версии — Complex Calculation. Это аддон, который позволяет строить математические формулы из значений полей прямо в форме: количество товара умножить на цену, применить скидку по промокоду, посчитать итог с учётом доставки. Всё это происходит на сервере при отправке формы — PHP вычисляет результат и возвращает его клиенту. Именно здесь, между пользовательским вводом и серверным вычислением, оказалась дыра размером с грузовик.

КАК РАБОТАЕТ УЯЗВИМОСТЬ

Когда пользователь отправляет форму с включённой функцией Complex Calculation, значения из полей попадают в функцию process_filter() плагина. Там они конкатенируются в строку PHP-кода, которая затем передаётся в eval(). Идея понятна: нужно динамически вычислить формулу из пользовательского ввода. Проблема в том, что ввод перед этим проходит только через sanitize_text_field().

Эта функция WordPress предназначена для очистки текста от HTML-тегов и лишних пробелов — она убирает <script> и похожие конструкции. Но одинарные кавычки и другие символы, критичные для PHP-синтаксиса, она не трогает. В контексте генерации PHP-кода это катастрофа: «безопасный» с точки зрения HTML ввод может быть полноценной PHP-инъекцией. Разработчики Everest Forms Pro перепутали контекст — они применили инструмент для HTML-очистки там, где нужна была PHP-эскейпинг.

В итоге атакующий вписывает в любое строковое поле формы (текст, email, URL, select, radio) специально сформированный payload с PHP-кодом. Форма должна использовать Complex Calculation — это обязательное условие. Никакой аутентификации не требуется: любой посетитель сайта может отправить форму. Сервер получает запрос, process_filter() собирает строку из пользовательских значений, eval() выполняет результат как PHP-код с привилегиями пользователя, под которым работает веб-сервер.

РЕАЛЬНАЯ ЦЕПОЧКА АТАКИ

Атакующий сканирует WordPress-сайты в поисках установленного Everest Forms Pro — по характерным CSS-классам и атрибутам формы, которые плагин добавляет в HTML. Это автоматизированный процесс: специализированные боты обходят миллионы сайтов в поисках конкретных сигнатур плагинов. Найдя форму с Complex Calculation, бот отправляет POST-запрос с подготовленным payload в текстовом поле. Payload содержит PHP-код, который создаёт файл на сервере — веб-шелл. Весь этот процесс от обнаружения до размещения шелла занимает секунды.

После этого атакующий переходит к ручной работе. Через HTTP-запросы к веб-шеллу он читает wp-config.php — там лежат учётные данные базы данных. С паролем от БД он подключается к MySQL и создаёт нового администратора WordPress — именно этот паттерн Wordfence зафиксировал в атаках. Параллельно он просматривает файловую систему: другие конфигурационные файлы, SSH-ключи в домашних директориях, файлы .env, логи с паролями. Если на сервере несколько сайтов в одном PHP-FPM пуле — атакующий получает доступ ко всем их файлам, не только к атакованному. Это классический lateral movement: взломали один сайт, получили доступ к десяти.

Wordfence зафиксировал характерный маркер компрометации — строку diksimarina в логах и в созданных атакующим файлах. Основной трафик атак идёт с двух IP-адресов: 202.56.2.126 и 209.146.60.26. Wordfence публикует полный список IOC, но эти два наиболее активны. Смена IP для атакующего — дело минут, поэтому блокировка конкретных адресов полезна как временная мера, но не как основная защита.

ХРОНОЛОГИЯ

Февраль 2026 года: исследователь под псевдонимом h0xilo сообщил об уязвимости через программу Wordfence Bug Bounty. 18 марта WPEverest выпустил патч — версия 1.9.13. 30 марта Wordfence опубликовал CVE и технические детали. 13 апреля началась активная эксплуатация — через 26 дней после выхода патча.

Разрыв между патчем и эксплуатацией — 26 дней — типичная картина для WordPress-плагинов. Большинство сайтов не обновляются автоматически. Часть владельцев вообще не следит за обновлениями плагинов. За это время атакующие изучили патч, восстановили уязвимый код, написали эксплойт и начали массовое сканирование. 16 мая — пик атак: 17 900 попыток за один день. Это говорит о том, что кто-то добавил CVE-2026-3300 в свой автоматизированный инструментарий массового сканирования.

ПОЧЕМУ ЭТО ВАЖНО

4 000 установок — это не тысячи уязвимых серверов, как бывает с популярными плагинами вроде Contact Form 7 или Yoast SEO. Но WordPress-атаки редко бывают точечными: ботнеты сканируют интернет непрерывно и атакуют всё подряд, что попадается. Если ваш сайт использует Everest Forms Pro и не обновлён — он уже в списках атакующих независимо от того, насколько он «небольшой» или «нецелевой».

Важнее другое: RCE через форму — это полный захват сервера в смысле прав веб-процесса. Атакующий получает не просто доступ к базе данных через SQL-инъекцию, а возможность выполнять произвольный код. Это означает создание веб-шеллов, чтение любых файлов, доступных PHP, изменение кода сайта, кражу учётных данных из wp-config.php. Если на том же сервере крутятся другие сайты в том же PHP-FPM пуле — они тоже под угрозой. Это классический lateral movement внутри shared hosting окружения.

Есть ещё один неочевидный риск. Этот тип бага — пользовательский ввод в eval() — не уникален для Everest Forms Pro. WordPress-экосистема огромна: тысячи плагинов, многие из которых реализуют похожую динамическую логику. История с CVE-2026-3300 — хорошее напоминание о том, что любой плагин с «умными» формами, калькуляторами цен или динамическими полями потенциально делает что-то подобное. Как сисадмин вы не можете проверить код каждого плагина — но можете держать их в актуальном состоянии, следить за Wordfence Intelligence и настроить алерты на появление новых PHP-файлов в директории сайта. Это снижает окно уязвимости с «пока кто-то не взломал» до «пока не вышел патч».

ЧТО ДЕЛАТЬ

Первое — проверить версию плагина. В консоли WordPress это Плагины → Установленные плагины → найти Everest Forms Pro и посмотреть версию. Должна быть 1.9.13 или выше. Если меньше — обновить немедленно через стандартный механизм обновлений WordPress.

Проверить версию можно и из командной строки через WP-CLI:

wp plugin get everest-forms-pro --fields=name,version,status

Если плагин установлен и версия ниже 1.9.13 — обновить. Успешное обновление выглядит так: Success: Updated 1 of 1 plugins.

wp plugin update everest-forms-pro

Если плагин не используется активно — деактивировать и удалить. Неактивный плагин с уязвимым кодом на диске всё равно представляет риск при определённых конфигурациях сервера:

wp plugin deactivate everest-forms-pro
wp plugin delete everest-forms-pro

Второй шаг — проверить, не был ли сайт уже скомпрометирован. Атаки идут с апреля, и если плагин стоял непропатченным всё это время — нужно проверить логи и файловую систему. Ищем признаки компрометации в access-логах nginx — POST-запросы к формам с подозрительными payload:

grep -i "POST" /var/log/nginx/access.log | grep -i "everest\|evf_" | grep "202.56.2.126\|209.146.60.26"

Проверяем на появление новых PHP-файлов в директории сайта за последние два месяца — именно столько прошло с начала активной эксплуатации. Команда выведет список всех PHP-файлов, изменённых за этот период. Среди них будут легитимные файлы от плановых обновлений WordPress и плагинов — они находятся в wp-admin/, wp-includes/ и директориях плагинов внутри wp-content/plugins/. Подозрительно выглядят файлы в wp-content/uploads/ (туда PHP-файлы не должны попадать никогда), в корне сайта с нетипичными именами (случайные буквы, цифры), и любые файлы вне стандартной структуры WordPress:

find /var/www/html -name "*.php" -mtime -60

Ищем маркер компрометации diksimarina, который Wordfence обнаружил в атаках:

grep -r "diksimarina" /var/www/html/

Проверяем список администраторов WordPress на посторонние аккаунты:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Если найдены подозрительные PHP-файлы, неизвестные администраторы или следы diksimarina в файлах — сайт скомпрометирован. В этом случае восстановление из резервной копии до даты начала атак (до 13 апреля) надёжнее, чем попытка вычистить малварь вручную: атакующий мог разместить несколько backdoor в разных местах.

Блокировка атакующих IP на уровне nftables — дополнительная мера, которая снизит шум в логах. Команда работает при условии, что в вашей конфигурации nftables уже существует set с именем blocklist в таблице inet filter — как это настроено в курсе по nftables:

nft add element inet filter blocklist { 202.56.2.126, 209.146.60.26 }

Если перед WordPress стоит Cloudflare WAF, можно заблокировать запросы содержащие характерные PHP-паттерны в POST-теле через Custom Rule. Но надёжнее всего — обновить плагин: это закрывает вектор атаки полностью, а не просто блокирует конкретные IP, которые атакующий может легко сменить.

ВЫВОДЫ

CVE-2026-3300 — классический пример того, как одна неправильно применённая функция превращает форму обратной связи в точку полного захвата сервера. CVSS 9.8, unauthenticated RCE, активная эксплуатация с апреля, 29 300 заблокированных попыток. Патч существует с 18 марта — версия 1.9.13.

Если Everest Forms Pro стоит на вашем сервере: проверьте версию прямо сейчас. Если версия ниже 1.9.13 — обновите и проверьте логи начиная с 13 апреля. Если плагин не нужен — удалите.

Leave your thought here

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Select the fields to be shown. Others will be hidden. Drag and drop to rearrange the order.
  • Image
  • SKU
  • Rating
  • Цена
  • Stock
  • Availability
  • Add to cart
  • Description
  • Content
  • Weight
  • Dimensions
  • Additional information
Click outside to hide the comparison bar
Compare