Атаки на CVE-2026-87902 перешли из разведки в эксплуатацию: злоумышленники уже пытаются записывать PHP-файлы на серверы WordPress и запускать через них shell-команды. Для русскоязычных команд это неприятный, но очень практичный сигнал: если сайт на WordPress не обновлён до 7.1.2 или поддерживаемой ветки с бэкпортом исправления, проверять надо не только версию, но и логи, временные каталоги и конфигурацию PHP.
О новой фазе атак сообщает BleepingComputer со ссылкой на данные Patchstack. По наблюдениям компании, первые вредоносные запросы появились 22 сентября в 17:44 UTC — меньше чем через пять часов после выхода патча в WordPress 7.1.2. Сначала трафик выглядел как разведка: атакующие пытались понять, какие сайты уязвимы. Затем активность выросла примерно в десять раз, а запросы стали содержать уже не только проверку, но и попытку доставить полезную нагрузку.
Уязвимость CVE-2026-87902 нашёл исследователь Роберт Рессл. Команда безопасности WordPress оценила её как критическую: 9,2 балла из 10. По сути, это unauthenticated path traversal — ошибка обхода путей без авторизации. В определённых условиях она позволяет заставить механизм выбора шаблона страницы get_page_template() подключить локальный PHP-файл за пределами директорий активной темы. Звучит как внутренности WordPress, но последствия вполне внешние: при удачной комбинации настроек это может привести к удалённому выполнению кода.
Важная деталь: сама по себе уязвимость не превращает любой сайт в открытую консоль. Для RCE нужны условия. В активной родительской или дочерней теме должна быть верхнеуровневая директория с именем, начинающимся на page-, например page-templates. Атакующему также нужен локальный PHP-файл, который существует на сервере и доступен для чтения веб-серверу. В официальном описании WordPress приводится пример с pearcmd.php, если в PHP включена настройка register_argc_argv.
Этот нюанс особенно важен для инфраструктур, где WordPress живёт в контейнерах или на типовых хостинг-панелях. В advisory WordPress отдельно указано, что затронут официальный PHP-образ для Docker, а также дефолтная конфигурация cPanel при использовании PHP до версии 8.5. То есть речь не только о самописных странных сборках, которые кто-то однажды собрал ночью и забыл. Под риск попадают вполне массовые сценарии деплоя.
WordPress закрыл CVE-2026-87902 в версии 7.1.2. Из-за критичности исправления бэкпортировали во все ветки вплоть до 4.7. Релизы старше 4.6 патч не получат. Это тот случай, когда аргумент «у нас старый WordPress, но всё стабильно» начинает звучать как заявка на отдельный инцидентный канал в мессенджере. Если сайт по какой-то причине застрял на ветке до 4.7, нормального пути через обычное обновление безопасности уже нет.
По данным Patchstack, ранние запросы пытались подключать обычные файлы ядра WordPress. Похоже, атакующие использовали их как маркер: если сайт реагирует нужным образом, его можно развивать дальше. На следующем этапе исследователи увидели попытки использовать pearcmd для записи файлов на диск. Часть payload просто оставляла строку-флаг, показывающую, что хост эксплуатируем через CVE-2026-87902. Но были и более опасные варианты: короткие PHP-фрагменты, которые выполняют shell-команду при обращении к файлу.
Файлы, по наблюдениям исследователей, складывались в /tmp и /var/tmp. Среди имён встречались wp-pear-rce-flag.php, poc87902.php, luci_.php и zeta_.php. Рабочий пример запроса Patchstack не публиковала, но описала характерные признаки: двойное кодирование traversal-последовательностей в параметре pagename вместе с валидным page_id. Также названы IP-адреса, которые можно добавить в блоклист: 169.58.48.193, 169.58.48.195 и 2001:df1:e8c0::106b.
Для разработчиков и администраторов практический чек-лист короткий. Обновить WordPress до 7.1.2 или соответствующего исправленного релиза своей ветки. Проверить, нет ли подозрительных PHP-файлов во временных каталогах. Просмотреть access-логи на запросы с параметрами pagename и page_id, особенно если там видны закодированные переходы по каталогам. Отдельно проверить окружения на Docker и cPanel: именно типовая конфигурация часто оказывается тем местом, где атака из «теоретически возможно» превращается в «у нас уже лежит странный файл в /tmp».
Бизнесу эта история напоминает старую, но всё ещё недооценённую вещь: WordPress — не просто CMS для лендинга, а полноценная поверхность атаки, часто подключённая к CRM, аналитике, формам заявок и платёжным сценариям. Быстрое появление эксплуатации после релиза патча показывает, что окно между «исправление опубликовано» и «боты уже стучатся» снова измеряется часами. Следующий вопрос для команд не в том, обновлять ли WordPress, а в том, способны ли они заметить эксплуатацию быстрее, чем злоумышленник превратит временный PHP-файл в постоянную точку входа.