WordPress выпустил обновление 7.1.2, закрывающее критическую уязвимость CVE-2026-87902. Дыра позволяет неаутентифицированному атакующему выполнить произвольный код на сервере (RCE). Сообщения об атаках появились почти сразу после публикации патча.
Уязвимость обнаружил и сообщил в компанию швейцарский исследователь безопасности Robert Ressl. Исправление вошло в релиз 7.1.2 и было перенесено (backport) вплоть до версии 4.7 — под удар попадают и старые ветки WordPress.
Что именно ломается
В официальном сообщении о релизе 7.1.2 сказано: при определённых условиях неаутентифицированный атакующий может заставить механизм разрешения шаблонов страниц (page template resolution) подключить выбранный читаемый локальный PHP-файл за пределами каталогов активной темы. Если выполнены нужные предварительные условия и для серверного окружения, и для активной темы, это приводит к удалённому выполнению кода.
Диапазон уязвимых версий — с 4.7.0 по 7.1.1. WordPress призвал обновить сайты немедленно.
Как выглядит атака
Noah Kenney, главный консультант Digital 520, описал главный риск так: получив исполнение PHP, атакующий читает wp-config.php, добывает учётные данные базы данных и ключи аутентификации, создаёт администраторские учётные записи, правит платёжные формы и формы сбора лидов, перенаправляет посетителей и устанавливает постоянный код.
Менее очевиден способ доставки. pearcmd.php — легитимный инструмент управления PHP-пакетами, но его конфигурационные команды можно использовать, чтобы записать на диск произвольное содержимое. Текущие атаки применяют его для размещения вредоносного PHP в /tmp, после чего уязвимость WordPress загружает и исполняет этот файл. Команда безопасности, которая следит за изменениями только в каталоге WordPress, может вообще не заметить первую стадию.
Патч вышел — эксплуатация началась в тот же день
Скорость, с которой начались атаки, IDC и другие аналитики считают самым тревожным в этой истории. Philip Harris, директор по исследованиям IDC, назвал случай «учебниковым примером новой реальности рисков»: критическими багами пользуются в течение часов после раскрытия, а большинство предприятий не патчат достаточно быстро. Он ссылается на отчёты компании Patchstack, зафиксировавшей эксплуатацию вскоре после публикации патча.
Хронология по данным Patchstack: первые запросы были разведкой по безобидным файлам ядра, затем атакующие начали включать pearcmd.php и записывать PHP-файлы на диск; инструменты публичного сканирования под эту CVE уже распространяются. Harris уточняет: разведка началась в течение пяти часов после патча, полная эксплуатация — примерно за сутки, объём трафика за день вырос примерно в десять раз, когда атакующие перешли от сканирования к доставке полезной нагрузки.
Aman Mahapatra, директор по стратегии консалтинговой фирмы Tribeca Softech, предлагает смотреть не на оценку CVSS 9.2, а на разрыв между патчем и эксплуатацией — здесь он практически нулевой. WordPress выпустил 7.1.2 22 сентября, и Patchstack заблокировал первую попытку эксплуатации в 11:49 UTC того же дня, причём полезные нагрузки совпадали с тем кодированием, которое патч и был написан исправлять. По его словам, атакующие не находили эту ошибку — они читали исправление.
Автообновления: включить нельзя проверить
Одна из реакций на такую скорость — автоматизировать обновления, но это не обязательно хороший вариант. Часть корпоративных CISO опасается избыточной автоматизации патчей: они хотят проверять и утверждать любые изменения в системе.
Ressl в интервью отметил другую проблему: многие предприятия не проверяют, что обновление действительно установилось. «Включённые автообновления — это не то же самое, что подтверждённая установка патча», — сказал он. Его рекомендация — быстрый, но протестированный раскат с проверкой на всех открытых наружу установках, включая staging-сайты.
Mahapatra добавляет, что для крупных предприятий проблема острее. WordPress применяет минорные security-релизы автоматически по умолчанию, поэтому средний блог-хобби уже, скорее всего, пропатчен. Корпоративные же сайты регулярно отключают автообновления ради change control — и организации с самой зрелой governance оказываются наиболее уязвимыми, потому что их собственный процесс держит исправление в очереди, пока атакующие сканируют.
Nidhi Luthra, исполнительный советник Acceligence, формулирует вывод коротко: security-релиз может почти сразу стать дорожной картой для атакующего, поэтому экстренное патчение интернет-доступных систем требует реакции в пределах часов. Общий фон — пять критических уязвимостей в плагинах и темах WordPress, которые закрывали ранее, — показывает, что экосистема платформы остаётся излюбленной целью.
Забытые сайты WordPress остаются без патча
Mahapatra указывает на ещё одну, возможно, более крупную проблему: многие корпоративные развёртывания WordPress живут ниже радаров. Это не типичный shadow IT — их санкционировали в своё время, — но ИТ-руководство о них часто не знает.
В организациях, по его словам, «подверженность существенно больше, чем предполагает большинство компаний, потому что большинство предприятий не считают себя WordPress-организациями, а являются ими почти все». Риск сидит в веб-хозяйстве, которое ИТ никогда не инвентаризировали: маркетинговые микросайты, лендинги кампаний, региональные страницы по странам, страницы для инвесторов, сделанные внешним агентством, и сайты компаний, купленных три года назад, до которых ни у кого не дошли руки. Диапазон уязвимых версий — с 4.7.0 по 7.1.1, почти десять лет установок, и забытые сайты как раз и сидят на старых ветках.
Особенно заметно это в финансовом секторе, говорит Mahapatra. Когда он проходит обзоры внешней поверхности атаки с CISO банков, всплывающие WordPress-инстансы почти никогда не оказываются корпоративным сайтом — это сайты маркетинга, дочерней компании или контракта с агентством, срок которого истёк, и ни один из них не значится в CMDB, по которой команда безопасности патчит.
Похожая логика работала и в истории с критической RCE в WordPress 7.0.4 через PNG с PostScript внутри: там тоже важно было не просто обновиться, а проверить, что обновление действительно встало на всех установках. А на серверах, где рядом с WordPress живёт панель управления, стоит держать в уме и уязвимость в парковке доменов cPanel, дающую root-доступ.
Частые вопросы
Кого касается уязвимость CVE-2026-87902?
Все сайты на WordPress версий с 4.7.0 по 7.1.1. Патч перенесён вплоть до 4.7, поэтому старые установки тоже уязвимы, а не только свежие релизы.
Что именно позволяет сделать дыра?
Неаутентифицированный атакующий при определённых условиях заставляет механизм разрешения шаблонов страниц подключить выбранный локальный PHP-файл вне каталогов активной темы. Если условия серверного окружения и активной темы совпадают, это даёт удалённое выполнение кода.
Уже есть эксплуатация в дикой природе?
Да. Patchstack зафиксировала разведку в течение пяти часов после выхода 7.1.2 и полную эксплуатацию примерно за сутки, с ростом объёма трафика примерно в десять раз за день. Первую попытку эксплуатации заблокировали в 11:49 UTC 22 сентября.
Как быстро нужно обновиться?
Немедленно. По оценке участников обсуждения, экстренное патчение интернет-доступных систем требует реакции в пределах часов, а не недель.
Достаточно ли включить автообновления?
Нет. Автообновления WordPress применяются по умолчанию только к минорным security-релизам, а корпоративные сайты часто их отключают ради change control. Кроме того, включённые автообновления не означают, что патч действительно установился, — установку нужно проверять.
Как проверить, что патч встал?
Проверьте фактическую версию WordPress на каждом сайте и убедитесь, что она 7.1.2 или новее. Отдельно проверьте staging-сайты и все открытые наружу установки, как рекомендует исследователь Robert Ressl.
Почему атака началась так быстро?
Потому что патч фактически описывает исправляемое поведение, и атакующие читают исправление, а не ищут ошибку самостоятельно. Mahapatra прямо говорит: публикация патча теперь функционально равна публикации руководства по эксплуатации.
На что смотреть, если сайтов много?
На те, которых нет в инвентаризации: микросайты маркетинга, лендинги кампаний, региональные страницы, сайты внешних агентств и приобретённых компаний. Именно они чаще всего остаются на старых ветках и не попадают в CMDB, по которой патчит команда безопасности.
Что может сделать атакующий после получения исполнения PHP?
Прочитать wp-config.php, получить учётные данные базы данных и ключи аутентификации, создать администраторские аккаунты, изменить платёжные формы и формы сбора лидов, перенаправить посетителей и установить постоянный код.
Как атакующие доставляют полезную нагрузку?
Через pearcmd.php — легитимный инструмент управления PHP-пакетами. Его конфигурационные команды позволяют записать произвольное содержимое на диск: вредоносный PHP размещается в /tmp, а затем уязвимость WordPress загружает и исполняет этот файл.
Почему мониторинг каталога WordPress может не помочь?
Потому что первая стадия атаки происходит вне каталога WordPress — файл пишется в /tmp. Команда, которая следит за изменениями только в каталоге WordPress, может пропустить эту стадию целиком.
Есть ли оценка серьёзности?
Да, уязвимости приписывают оценку CVSS 9.2. Но, как отмечают эксперты, важнее не сама оценка, а почти нулевой разрыв между выходом патча и началом эксплуатации.
Источник: csoonline.com