WordPress 7.1.4 закрыл дыру: сайт сам выдавал временные файлы обновления в сеть

Коротко: CVE-2026-119977 (CVSS 8.1) — уязвимость в механизме самообновления ядра WordPress. При установке полного пакета файлы распаковываются в папку с предсказуемым именем внутри wp-content/upgrade/, включая файл-установщик wp-config-sample.php вместо боевого wp-config.php — из-за этого мастер установки не видит, что сайт уже настроен, и на несколько секунд остаётся доступен из сети без авторизации. Патч — версия 7.1.4 и бэкпорты для всех веток вплоть до 4.7, вышли 28 октября 2026 года. Эксплуатация началась уже в первые минуты после публикации патча.

Что произошло

28 октября 2026 года команда WordPress выпустила версию 7.1.4 — внеплановое обновление безопасности. CVE-2026-119977 получила оценку CVSS 8.1 по шкале Wordfence (CNA, Certified Numbering Authority для WordPress-экосистемы) — это высокий уровень серьёзности для уязвимости, не требующей авторизации.

Патч бэкпортирован во все поддерживаемые ветки — вплоть до версии 4.7.0, выпущенной ещё в 2016 году. Вместе с 7.1.4 вышли исправленные сборки для остальных веток, включая 7.0.8 и 6.9.11.

Уязвимость обнаружил исследователь Умут Байрам (Umut Bayram) из Picus Security и сообщил о ней ответственно — то есть до публикации деталей команда WordPress уже успела подготовить патч. Тем не менее это не помешало массовой эксплуатации: по данным Wordfence, первое срабатывание защитного правила против атак на CVE-2026-119977 произошло всего через девять минут после публикации патча 28 октября, а за первые 21 час было зафиксировано более 18 500 запросов, нацеленных на путь установщика setup-config.php во временной папке обновления.

Механизм: гонка за временными файлами установщика

Проблема — в том, как ядро WordPress обрабатывает полный пакет обновления. Уязвимость соединяет три слабых места в одной цепочке:

• Предсказуемый путь. При установке полного пакета файлы распаковываются в папку, имя которой вычисляется из имени самого файла пакета обновления — например, wp-content/upgrade/wordpress-7.1.4. Атакующему не нужно ничего угадывать: путь можно вычислить заранее.
• Незащищённый установщик. В распакованном дереве лежит wp-config-sample.php, а не боевой wp-config.php — поэтому мастер установки WordPress не видит привычной защиты «конфиг уже существует, установка не требуется» и охотно принимает запросы на настройку сайта заново.
• Копирование без очистки. До версии 7.1.4 шаг копирования переносил файлы из временной папки в корень сайта, пропуская только каталоги wp-content и wp-includes/version.php — то есть поддельный wp-config.php, записанный атакующим через установщик, мог закрепиться на сайте.

Разногласие в оценке серьёзности

Любопытная деталь этой истории — расхождение в оценке. Собственный консультативный бюллетень проекта WordPress изначально оценил уязвимость как низкую по серьёзности — из-за того, что окно эксплуатации длится всего несколько секунд и совпадение всех условий маловероятно в теории. Wordfence как независимый CNA присвоил CVE-2026-119977 оценку 8.1 High — отражая не вероятность попадания в узкое окно, а тяжесть последствий, если атакующему всё же повезёт. Обе стороны сходятся в одном: путь к выполнению кода без авторизации реален, расходятся только в том, как взвешивать временные ограничения против потенциального ущерба.

Похожий спор о «теоретическом» и «практическом» риске уже звучал вокруг уязвимости CVE-2026-87902 в функции get_page_template() — там тоже требовалось совпадение нескольких условий, но это не помешало началу атак в день выхода патча.

Кого касается и что уже происходит

Формально в зоне риска — все версии WordPress с 4.7.0 по 7.1.3 включительно, то есть практически любая инсталляция, которую ещё не обновили. Практическая эксплуатация возможна только в момент выполнения самого обновления ядра — то есть риск максимален для сайтов с включёнными автоматическими обновлениями в момент их установки, а также для администраторов, которые вручную запускают обновление через панель или WP-CLI и не следят за процессом.

По данным аналитиков, атакующие используют автоматизированные сканеры, которые массово опрашивают типовые пути wp-content/upgrade/ на тысячах сайтов одновременно — расчёт на то, что хотя бы часть из них в этот момент как раз обновляется. Это тот же принцип, что и в атаках на временные файлы при распаковке архивов в целом: не угадать конкретную жертву, а дождаться момента, когда защита временно снята.

Что делать прямо сейчас

Единственное надёжное решение — обновить WordPress до версии 7.1.4 или до соответствующего бэкпорта своей ветки.

• Панель администратора: «Консоль → Обновления» → «Обновить сейчас».
• WP-CLI: wp core update
• Managed hosting: уточните у провайдера — многие уже применили патч в фоне через автообновления безопасности.

Дополнительная мера для администраторов серверов, если обновление ещё не применено: временно заблокировать веб-доступ к каталогу wp-content/upgrade/ на уровне веб-сервера (для nginx — правило return 403 на этот путь, для Apache — RedirectMatch 403). Это не устраняет саму уязвимость, но разрывает цепочку атаки до момента обновления. Стоит также проверить журналы сервера на обращения к файлам вида setup-config.php внутри wp-content/upgrade/ — это типичный след попыток эксплуатации CVE-2026-119977.

Источники

• Ostorlab — WordPress Core Upgrade-Window RCE, Fixed in 7.1.4 (CVE-2026-119977)
• CyberPress — Hackers Actively Target WordPress RCE Flaw That Allows Unauthenticated Remote Code Execution
• SecurityLab.ru — WordPress взломали на уровне механизма обновления