Уязвимость WordPress CVE-2026-87902: как проверить сайт

22 сентября 2026 года вышел WordPress 7.1.2 с исправлением критической уязвимости CVE-2026-87902. При определённом сочетании темы и настроек PHP она позволяет атаковать сайт без входа в аккаунт.

Ниже — условия уязвимости, порядок проверки и действия владельца сайта. Устанавливай актуальное исправленное обновление своей ветки: версия 7.1.2 — релиз, в котором закрыли именно эту ошибку, а не рекомендация остановиться на нём.

Какие версии затронула CVE-2026-87902

Уязвимость получила номер CVE-2026-87902 и оценку 9.2 из 10 по CVSS — критическая.
Тип — подключение локального файла (local file inclusion) через обход каталогов. При подходящей настройке сервера это превращается в выполнение произвольного кода.
Авторизация не нужна: достаточно отправить на сайт специально собранный запрос.
Затронуты все версии с 4.7.0 по 7.1.1 — почти десять лет релизов.
Исправление выпущено для всех веток: 7.1.2, 7.0.6, 6.9.9, 6.8.10 и далее вниз, вплоть до 4.7.37.

Исправление доступно и для старых веток. Это позволяет закрыть конкретную уязвимость без немедленного перехода на новую основную версию. Совместимость обновления всё равно нужно проверить на копии сайта.

При каких условиях возможна атака

При выборе шаблона страницы WordPress использует параметр pagename. В уязвимом варианте путь, построенный из этого параметра, не проходил необходимую проверку. Это позволяло при определённых условиях подключить PHP-файл за пределами активной темы.

Есть два ограничения. Имя файла начинается с page-, поэтому в активной теме должна быть папка верхнего уровня с таким началом, например page-templates. И подключить можно только файл с расширением .php.

Возможность подключить локальный файл уже опасна. Для описанной исследователями цепочки выполнения кода дополнительно важны два условия:

на сервере есть pearcmd.php — утилита пакетного менеджера PEAR;
в PHP включена настройка register_argc_argv, и строка запроса попадает в скрипт как аргументы командной строки.

Через pearcmd.php можно записать на диск файл с любым PHP-кодом. По данным Patchstack, register_argc_argv по умолчанию включена в официальных Docker-образах PHP и в cPanel на PHP ниже 8.5, так что это не экзотика.

В 7.1.2 исправили не только эту строку. Кандидат из pagename теперь проходит validate_file(), а вдобавок появилась общая проверка _wp_is_template_path_allowed(): любой найденный шаблон должен лежать внутри папки темы. Команда безопасности закрыла целый класс ошибок, а не один путь.

Что известно о попытках эксплуатации

22 сентября, 11:49 UTC — первые запросы на файрволе Patchstack, в день выхода исправления. Атакующие собрали их по изменениям в коде патча.
Первые сутки — разведка: подключают безобидные файлы ядра, чтобы понять, уязвим ли сайт.
23 сентября — проверяют, доступен ли pearcmd.php, и записывают PHP-файлы в /tmp и /var/tmp. Часть файлов — метки «здесь уязвимо», часть выполняет команды на сервере.
Появился публичный шаблон для сканера Nuclei. Теперь сайты может проверять кто угодно, запросы идут с сотен адресов, поэтому блокировка отдельных IP не заменяет исправление уязвимости.

Как проверить WordPress, тему и PHP

1. Версия WordPress

Админка → «Консоль» → «Обновления». Номер версии также виден внизу любой страницы админки. Через SSH:

wp core version

Исправление этой уязвимости есть в 7.1.2 и соответствующих исправленных релизах старых веток. Сверь установленную версию с доступным обновлением в админке. Автоматические обновления могли сработать, но это нужно проверить.

Обновление закрывает уязвимость, однако не удаляет следы возможного взлома. Если сайт был доступен на уязвимой версии, проверь журналы и файлы.

2. Папки page-* в теме

Из корня сайта:

ls -d wp-content/themes/*/page-*/

Слеш в конце оставляет только папки: файлы вроде page-contacts.php не в счёт. Важна активная тема, а если она дочерняя — ещё и родительская. Пустой результат значит, что этот путь атаки на твоём сайте не срабатывает. Обновиться всё равно нужно.

3. Настройка register_argc_argv

Проверять нужно PHP, который обслуживает сайт. CLI и веб-сервер могут использовать разные ini-файлы и настройки; результат команды php -r сам по себе не подтверждает конфигурацию PHP-FPM или Apache.

Проверь конфигурацию используемого веб-обработчика PHP, включая дополнительные ini-файлы и настройки пула PHP-FPM. Команда php --ini показывает конфигурацию CLI и подходит лишь как отправная точка.
При необходимости проверь ini_get( 'register_argc_argv' ) через временную диагностическую страницу с ограниченным доступом. Сразу после проверки удали её.

4. Следы атаки

Если сайт какое-то время работал на уязвимой версии, проверь журнал доступа веб-сервера. Обход каталогов приходит закодированным, а pagename почти всегда идёт вместе с page_id:

grep -iE 'pagename=[^ &]*(%2e|%252e|%2f|%252f)' access.log

POST-запросы так не найти: параметры из тела запроса в журнал не пишутся, а по наблюдениям Patchstack POST уже обогнал GET. Поэтому проверь и временные папки сервера (в Docker — внутри контейнера с PHP):

ls -la /tmp /var/tmp | grep -E 'poc87902|wp-pear-rce-flag|luci_|zeta_'

Это примеры имён из наблюдений Patchstack, а не полный список. Отсутствие таких файлов не доказывает, что атаки не было.

При подозрении на взлом сохрани журналы и копию файлов, ограничь доступ к сайту и проведи проверку. После удаления вредоносного кода или восстановления из чистой копии смени учётные данные и ключи с доверенного устройства. Проверь администраторов, mu-плагины и изменённые файлы.

Временные меры до обновления WordPress

Выключи register_argc_argv для веб-сервера: строка register_argc_argv = Off в php.ini или в отдельном файле в conf.d, затем перезапуск PHP. Сайту на WordPress эта настройка не нужна, WP-CLI она не затрагивает.
Если в теме есть папка page-…, а обновление откладывается — включи правило файрвола (Wordfence, Patchstack или хостинга) против этой уязвимости.

Это снижает риск, но не заменяет обновление. После обновления register_argc_argv всё равно лучше оставить выключенной: связка с pearcmd.php превращает в полный взлом и будущие уязвимости такого типа, в том числе в плагинах.

Если после обновления сайт перестал открываться, разбор — в статье «На сайте возникла критическая ошибка» в WordPress.

Результат проверки этого сайта 5 октября

Этот сайт работает на WordPress в Docker. При проверке 5 октября 2026 года были зафиксированы следующие результаты:

WordPress уже 7.1.2 — обновился автоматически.
Папок page-* в теме нет, только файл page-portfolio.php. Условие с такой папкой при проверке не выполнялось.
А вот серверная часть цепочки была на месте: pearcmd.php был найден. Основного php.ini не было; по проверенным конфигурационным файлам отключение register_argc_argv не было задано. Стандартный образ, никто специально не настраивал.

Вывод для себя: «обновился — и всё» не совсем так. Версию WordPress обновляют автоматически, а настройки PHP в образе годами остаются такими, какими были из коробки.

Источники

WordPress 7.1.2 Release — WordPress.org, 22.09.2026
WordPress 7.1.2 Security Release: Unauthenticated LFI to RCE — Patchstack
CVE-2026-87902: Attackers Started Probing WordPress Sites Hours After the Patch — Patchstack
PSA: Critical Unauthenticated Path Traversal Vulnerability Patched in WordPress Core — Wordfence

Не уверен, что твой сайт в порядке, или боишься что-то сломать обновлением — напиши мне, проверю.