Пару недель назад мы разбирали окно реакции: тезис о том, что время от публикации уязвимости до её первой массовой эксплуатации в 2026-м измеряется часами, а не днями, а по отдельным кейсам минутами. Тогда мы разбирали PaperCut и Marimo. Теперь у нас есть свежий, почти лабораторно чистый пример того же самого, только в мире, который касается почти каждого владельца сайта: критическая уязвимость в ядре WordPress, которую начали эксплуатировать в тот же день, когда вышел патч.
Речь про CVE-2026-87902 (9.2 по CVSS), неаутентифицированное удалённое выполнение кода. WordPress выпустил исправление 22 сентября. Первая попытка эксплуатации зафиксирована в тот же день в 11:49 UTC. Это не «через неделю после раскрытия», это в тот же рабочий день. Ровно та картина, которую мы описывали: у защитника больше нет форы в сутки, у него в лучшем случае часы.
Что за уязвимость
Баг сидит в том, как WordPress резолвит шаблоны страниц. Согласно бюллетеню, неаутентифицированный атакующий может заставить функцию get_page_template() подключить произвольный читаемый локальный .php-файл вне директорий активной темы. Простыми словами: функция, задача которой подгружать шаблоны самой темы, уводится в сторону и подгружает произвольный PHP-файл, уже лежащий на сервере. Это local file inclusion (LFI) на уровне ядра, доступный без логина.
Что удерживает CVE-2026-87902 от статуса тотальной катастрофы, так это два предусловия, которые должны совпасть одновременно:
- Условие темы: активная дочерняя или родительская тема должна содержать директорию верхнего уровня, имя которой начинается на
page-(например,page-templates). Встречается часто, но не поголовно, и именно это гейтит уязвимость. - Условие сервера: на сервере должен существовать читаемый веб-сервером локальный
.php-файл, который атакующий выберет целью. В подавляющем большинстве случаев этоpearcmd.php.
LFI, который может подключить только файлы, уже лежащие на сервере, сам по себе ограничен. Загрузить через него собственный код напрямую нельзя. Вся эскалация целиком зависит от того, на что его направить, и здесь на сцену выходит pearcmd.php.
Трюк с pearcmd.php: как inclusion превращается в выполнение кода
Вот часть, которую новостные заметки проскакивают, а она и есть вся суть. pearcmd.php — это консольный помощник, идущий в комплекте с PEAR, старым пакетным менеджером PHP, и лежит он по предсказуемому пути на множестве серверов: /usr/local/lib/php/pearcmd.php. На массе PHP-инсталляций он присутствует по умолчанию и читается веб-сервером, то есть является ровно тем «выбранным локальным .php», которого требует второе предусловие.
Причина, по которой атакующие обожают pearcmd.php, — это давняя особенность. Когда PHP-файл подключается через веб-запрос, а настройка register_argc_argv включена, строка запроса парсится в argv, как если бы это были аргументы командной строки. pearcmd.php читает эти аргументы и действует по ним, в том числе выполняет операцию записи конфига, которая позволяет записать контролируемое атакующим содержимое по выбранному атакующим пути. Итоговая цепочка: через LFI в WordPress подключить pearcmd.php, скормить ему строку запроса, ведущую себя как флаги командной строки PEAR, и заставить записать нужный PHP-файл в доступную на запись директорию вроде /tmp или /var/tmp. Записанный файл — это веб-шелл. LFI плюс pearcmd.php равно произвольная запись файла равно RCE.
Это тот же самый гаджет, которым годами злоупотребляют против бесчисленных LFI-багов, и именно поэтому эксплуатация появилась за часы: вторая половина цепочки уже лежала в тулките у каждого атакующего. Ровно то, о чём была наша статья про окно реакции: новой магии нет, эксплуатируются те же примитивы, что и пять лет назад, изменились только скорость и охват.
Наблюдаемые атаки совпадают с этим один в один. Запросы включают /usr/local/lib/php/pearcmd.php, пишут файл в /tmp/, а в одном из вариантов подтягивают PHP-скрипт загрузки, размещённый на GitHub (raw.githubusercontent[.]com/MrG3P5/web-shell/refs/heads/main/uploader.php), чтобы получить на машине полноценную возможность заливать файлы.
Активная эксплуатация: кто и сколько
Это не теория и не что-то медленное. Несколько компаний наблюдают атаки в реальном времени:
- Previdian зафиксировала 68 попыток эксплуатации против своей honeypot-сети начиная с 23 сентября. Вредоносные запросы шли с IP в Нью-Джерси (
104.194.9[.]227) и с адреса в Индонезии. - Patchstack подтвердила эскалацию, отметив, что трафик перешёл от безобидной разведки по файлам ядра к активной эксплуатации, в которой атакующие подключают pearcmd.php и пишут PHP-файлы на диск.
Основатель Previdian Ryan Dewhurst высказал мысль, которую стоит повторить, потому что это светлая сторона: поскольку в WordPress автообновления включены по умолчанию, вероятный исход — это масса попыток массовой эксплуатации при относительно небольшом числе реальных компрометаций. Под удар попадут те, кто отключил автообновления, работает на устаревших версиях или имеет ту самую структуру темы, которую требует баг. Вот та популяция, за которую стоит переживать. И это тоже прямая иллюстрация нашего тезиса: веерная атака бьёт по всем сразу, а достаётся немногим невезучим, у кого периметр открыт и не обновляется.
Обновляемся: исправленные версии
WordPress выпустил фиксы для всех поддерживаемых веток. Обновляйтесь как минимум до пропатченной сборки на своей линии:
- 7.1.2 (текущая ветка)
- 7.0.6
- 6.9.9
- 6.8.10
Если автообновления включены и их не отключали, вы, скорее всего, уже пропатчены, но проверьте версию, а не полагайтесь на предположение. Если вы обслуживаете сайты клиентов, проверьте каждый: тот единственный сайт на замороженной старой версии и есть тот, который зашеллят.
Как проверить, задели ли вас
Патч останавливает будущие попытки. Он не удаляет веб-шелл, который атакующий залил до обновления. Учитывая, как быстро стартовала эксплуатация, любой сайт, который был на уязвимой версии в промежутке с 22 по 24 сентября, заслуживает проверки. Ищите конкретные артефакты.
Подозрительные PHP-файлы
Проверьте /tmp, /var/tmp и корень сайта на записанный атакующим PHP. Наблюдаемые в кампании имена файлов:
wp-pear-rce-flag.phppoc87902.phpluci_<random>.phpzeta_<random>.php
Любой необъяснимый .php-файл во временной директории — это сильный сигнал: легитимные приложения крайне редко кладут исполняемый PHP в /tmp.
IP-адреса атакующих
Грепните журналы доступа на эти адреса-источники, связанные с вредоносной активностью:
104.194.9[.]227(Нью-Джерси, США)43.250.53[.]42180.251.159[.]243195.178.110[.]247107.189.14[.]8745.61.184[.]17092.246.130[.]76
Паттерны запросов в логах
Ищите запросы, ссылающиеся на pearcmd.php, запросы, содержащие /usr/local/lib/php/, или любой запрос с PEAR-подобными аргументами в строке запроса против пути page-шаблона. Исходящие обращения к raw.githubusercontent[.]com/MrG3P5/ тоже индикатор стадии со скриптом загрузки.
Если что-то из этого нашлось, считайте сайт скомпрометированным: снимите его с боя или изолируйте, сохраните логи, удалите залитые файлы, ищите закрепление (неожиданные админ-пользователи, изменённые файлы ядра, записи cron, инъекции в wp-config.php или файлах темы), ротируйте все учётные данные и соли, восстанавливайтесь из заведомо чистого бэкапа, снятого до окна компрометации, если он есть. Здесь работает реагирование на инциденты: в атаке, где всё решают часы, весь последующий разбор строится на журналах, и нет логов значит нечего разбирать.
Харденинг сверх патча
Два изменения на уровне сервера гасят весь этот класс атак, а не только конкретную CVE:
- Отключите
register_argc_argvдля веб-SAPI PHP, если нет конкретной причины его держать. С выключенной настройкой трюк с pearcmd.php теряет механизм, на котором держится: парсинг строки запроса в аргументы. - Удалите или ограничьте pearcmd.php, если PEAR не используется. Если
/usr/local/lib/php/pearcmd.phpне нужен, его удаление или снятие права на чтение у веб-сервера убирает гаджет, на который опирается второе предусловие.
Ни то, ни другое не заменяет патч, но оба — это дешёвая защита в глубину, которая нейтрализовала бы RCE-половину этой цепочки независимо от бага WordPress. И оба относятся к более широкой мысли из статьи про окно реакции: убрать из интернета и с сервера то, чему там не место, до того, как об этом напомнит чужой сканер.
Наш взгляд
CVE-2026-87902 — это чистая иллюстрация того, как разворачиваются современные атаки на WordPress, и того, о чём мы писали про окно реакции. Баг подключения файлов в ядре, безобидный сам по себе, сваривается с десятилетним PHP-гаджетом, который у каждого атакующего уже в кармане, и результат в виде неаутентифицированного RCE распыляется по интернету за часы после выхода патча. Никакого нового эксплойта, о котором не знал мир, никаких сверхтехнологий. Обычная дыра и обычный гаджет. Изменилась только скорость, с которой это доезжает до вашего периметра.
Автообновления по умолчанию спасут большинство сайтов. Проиграют непропатченные, замороженные и те, за которыми никто не следит. Если ваши сайты смотрят в интернет, честный вопрос к себе тот же, что и в прошлой статье: за сколько часов вы реально закроете дыру после того, как о ней объявят? Если ответ «за пару дней, наверное», у вас проблема, потому что у атакующего на весь цикл уходят часы. Проверить это на практике и получить не гипотезу, а факт помогает регулярное сканирование уязвимостей, честный тест внешнего периметра и, если речь про сайты, комплексная защита сайта от взлома.
Обновитесь до 7.1.2, 7.0.6, 6.9.9 или 6.8.10 прямо сейчас, проверьте временные директории и логи по индикаторам выше, и если PEAR на вашем сервере мёртвый груз, уберите pearcmd.php с доски навсегда.