Обновлялись на прошлой неделе? Придется еще раз
17 сентября вышел WordPress 7.1.1 с 11 исправлениями безопасности. Если вы сразу обновили сайт, все сделали правильно. Но уже 22 сентября появился WordPress 7.1.2 - отдельное обновление безопасности с одним критическим исправлением.
Да, второй апдейт за пять дней раздражает. Особенно когда у вас магазин, запись клиентов, формы и еще десяток дел кроме WordPress. Но откладывать этот релиз до следующего планового окна не стоит: Patchstack увидел первые активные проверки 22 сентября в 17:44 UTC, менее чем через пять часов после выхода патча.
На тот момент это была разведка. Не доставка вредоносного кода, не подтвержденный запуск команд и не доказанный взлом. И все же пять часов - очень короткий запас.
Что именно сломано в CVE-2026-87902
CVE-2026-87902 получила оценку 9,2 по CVSS 4.0. Уязвимы версии WordPress от 4.7.0 до 7.1.1 включительно. WordPress 4.7 вышел 6 декабря 2016 года, так что проблемный участок кода прожил почти десять лет.
Технически это обход каталогов (path traversal) и включение локального PHP-файла (LFI) при выборе шаблона страницы. Для запроса не нужен аккаунт. Специально закодированный параметр может заставить WordPress выйти за пределы ожидаемой папки шаблонов и обратиться к другому локальному файлу на сервере.
Но есть важное условие. У активной темы должна быть папка верхнего уровня, имя которой начинается с page-. Частый вариант - page-templates. Если такой структуры нет, описанный практический путь к LFI не срабатывает, хотя сама версия WordPress входит в уязвимый диапазон.
И LFI еще не означает, что любой сайт можно мгновенно превратить в чужой сервер. Для полного RCE атакующему нужен подходящий локальный PHP-файл, который веб-процесс может прочитать. В документированном сценарии используется PEAR-файл pearcmd.php, а настройка PHP register_argc_argv должна быть включена. Наличие этой комбинации зависит от конфигурации сервера.
Поэтому формулировка «все сайты до 7.1.2 можно захватить одним запросом» неверна. Но критическая уязвимость, которой можно воспользоваться без авторизации, все равно требует срочного обновления. Проверка через сканер уязвимостей WordPress поможет быстро найти отставшие версии, а условия эксплуатации уже надо разбирать отдельно.
Публичные патчи теперь разбирают за часы
Замеченные запросы били не по странному загруженному скрипту, а по обычным PHP-файлам ядра WordPress. Их использовали как индикатор: по ответу сервера можно понять, ведет ли себя сайт как уязвимый. Такое сканирование ищет подходящие цели. Оно само по себе не доказывает компрометацию.
Точная кодировка запросов совпала с изменением в патче. Это веский признак того, что проверку собрали по опубликованным изменениям: сравнили старый и новый код, поняли смысл исправления и воспроизвели нужный запрос. Но отсюда нельзя делать модный вывод «атаку написал ИИ».
ИИ не создал баг, который сидел в ядре почти десять лет. И нет данных, что именно эти запросы сгенерировала языковая модель. Реальный вывод скучнее, зато полезнее: ИИ вместе с обычной автоматизацией может ускорять и удешевлять разбор изменений в патче, создание вариантов запроса и массовое сканирование. Это не доказывает, что ИИ использовали именно в этом случае.
Защитники могут делать то же самое со своей стороны. Автоматически собрать версии по всем сайтам, отметить отставшие, сгруппировать похожие строки логов, а человеку оставить проверку контекста и решение. Если сайтов много, регулярное обслуживание WordPress тут не роскошь: один список, один проход обновлений и понятная проверка после них.
Три недавних случая, три разных бага
Легко решить, что это продолжение одной длинной атаки на ядро. Нет. Июльская цепочка wp2shell без входа в WordPress была отдельной историей. В августе WordPress 7.0.4 закрыл другую возможность RCE через загрузку вредоносного файла, где атакующему требовалась учетная запись с ролью «Автор» (Author) или выше, а сервер должен был использовать Imagick и Ghostscript.
У CVE-2026-87902 другой механизм: разрешение шаблона страницы, path traversal и LFI без авторизации, плюс конкретные условия для перехода к RCE. Смешивать эти случаи не надо. Общий у них только практический вывод - критический баг ядра без логина нельзя спокойно складывать в список «сделаем в конце месяца».
Что сделать сегодня
Даже если автообновления включены, откройте панель и проверьте цифры. Фоновая задача могла упасть, права на файлы - помешать записи, а хостинг - придержать апдейт своей политикой. Галочка «автоматически» не гарантирует, что сейчас у вас действительно 7.1.2.
- Сделайте быстрый бэкап или снимок сайта у хостера.
- Обновите WordPress до версии 7.1.2 и после завершения снова проверьте номер версии.
- Протестируйте корзину, возврат на сайт после оплаты, формы, бронирование и вход в админку.
Если большой переход сегодня правда невозможен, установите выпуск с перенесенным исправлением для своей ветки: 7.0.6, 6.9.9, 6.8.10 и далее вплоть до 4.7.37. Свежая версия остается лучшим вариантом. Но пропатченная старая ветка безопаснее, чем открытая критическая дыра, пока вы решаете проблемы совместимости.
Не превращайте идеальный план тестирования в повод ждать неделю. Быстрый снимок сайта, апдейт и проверка ключевых функций обычно разумнее. Более спокойный процесс описан в нашем материале о том, как обновлять WordPress без лишних поломок.
Если сайт был доступен до обновления
Проверьте обращения к корню сайта и /index.php между публикацией патча и вашим обновлением - как в строке запроса, так и в теле POST. Ищите pagename с двойным кодированием %252e%252e вместе с page_id, который указывает на реальную страницу. Если доступны записи тел ответов или данные WAF, ищите неожиданный вывод OPML либо другого файла ядра по обычному адресу страницы.
- Запишите старую и новую версии WordPress, а также точное время апдейта.
- Сохраните логи веб-сервера, PHP, файрвола и хостинга, пока ротация их не стерла.
- Проверьте, есть ли у активной темы папка верхнего уровня
page-*. - Если видно успешное подключение файла, странный запуск PHP, новые файлы или администратора - переходите к полноценному разбору инцидента.
Один запрос с таким шаблоном - еще не взлом. Возможно, сканер просто постучал и сравнил ответ. На момент отчета исследователи видели разведку, но не зафиксировали ни загрузки вредоносного кода, ни успешного выполнения кода, ни подтвержденной компрометации. А вот успешное включение локального файла уже дает повод копать глубже.
Новое правило простое: критическое ядро патчим в тот же день
Публичный патч теперь одновременно служит инструкцией защитникам и картой для тех, кто сканирует интернет. Старый баг может тихо жить десять лет, а после раскрытия окно реакции сжимается до нескольких часов. Вот как выглядит гонка обновлений в эпоху ИИ: не магическая «атака нейросети», а более быстрый и дешевый анализ с автоматизацией по обе стороны. Это показывает скорость современной автоматизации, но не участие ИИ в этом случае.
Для критических ошибок ядра без авторизации правило должно быть скучным: бэкап, обновление, проверка версии и короткий тест бизнеса в тот же день. Если сайт успел побыть открытым, посмотрите логи и факты, не принимая проверочный запрос за успешный взлом.
Обновили WordPress на прошлой неделе? Хорошо. Теперь обновите еще раз.