Уязвимость в обновлении WordPress: что проверить на своём сайте

28 октября 2026 года вышел WordPress 7.1.4 — выпуск только с исправлениями безопасности. В списке 18 пунктов, а в разбивке по веткам фигурируют 22 уязвимости: разница в том, что часть пунктов объединяет несколько проблем.

Большинство из них — межсайтовый скриптинг, для которого нужны права автора или редактора. Но один пункт стоит особняком: состояние гонки в процессе обновления ядра, которое может привести к выполнению произвольного кода. Нашёл его исследователь Umut Bayram, правки затронули wp-admin/includes/update-core.php и class-wp-upgrader.php.

Как это работает

Когда WordPress обновляет сам себя, он скачивает архив новой версии и распаковывает его во временный каталог внутри wp-content/upgrade. В распакованной копии лежит и установщик — wp-admin/setup-config.php, тот самый мастер первоначальной настройки.

В этой копии нет файла wp-config.php, а значит, установщик считает, что сайт ещё не настроен, и готов провести установку заново. Если каталог upgrade доступен снаружи и в нём выполняется PHP, в короткое окно между распаковкой и завершением обновления к установщику можно обратиться и подсунуть ему свою базу данных. Дальше это выполнение кода на сервере.

Важная оговорка: эти подробности — из сторонних разборов, в том числе анализа Wordfence. На официальной странице выпуска механика не раскрывается, там сказано только про состояние гонки и возможное выполнение кода.

Насколько это опасно на самом деле

Оценки расходятся, и об этом честнее сказать прямо.

• Wordfence присвоил уязвимости 8,1 из 10 и идентификатор CVE-2026-119977.
• Сам WordPress числовую оценку не публикует вовсе — на странице выпуска её нет.
• Атака требует попасть в окно обновления, то есть нужна удача или постоянное сканирование. Поэтому сложность высокая, и это отражено в оценке.
• Сообщения о массовых попытках есть, о подтверждённых взломах — нет. В каталог активно эксплуатируемых уязвимостей CISA на конец октября она не внесена.

Вывод из этого простой: паниковать не нужно, обновиться нужно. Чем дольше сайт остаётся на старой версии, тем выше шанс, что очередное обновление он будет ставить уже под наблюдением сканеров.

Что сделать сегодня

Обновиться. Исправления выпущены не только для 7.1.4 — их бэкпортировали во все поддерживаемые ветки вплоть до 4.7:

Если у вас 4.6 или старше — это отдельный разговор: такие версии не получают исправлений вообще, и перечисленная уязвимость там будет не единственной.

Эта таблица и короткая выжимка «кого касается — как проверить — что сделать» лежат в справочнике уязвимостей: туда мы выписываем то, что касается массовых сайтов, и с ним же сверяется наш экспресс-аудит, когда определяет версию вашего сайта.

Закрыть каталог обновлений. Полезно независимо от версии: в wp-content/upgrade не должно быть ни веб-доступа, ни выполнения PHP. В nginx это выглядит так:

location ^~ /wp-content/upgrade/ { deny all; }

Для Apache — правило в .htaccess внутри каталога:

<Files "*.php">
    Require all denied
</Files>

Проверять нужно запросом, а не наличием строки в конфиге. На связке nginx с Apache статику отдаёт nginx мимо правил .htaccess, и запрет, прописанный только там, может не сработать.

Посмотреть журналы. Ищите обращения к setup-config.php и install.php за пределами обычного входа в админку, а также любые запросы внутрь /wp-content/upgrade/. Если такие есть, проверьте дальше: не появился ли свежий wp-config.php с незнакомыми параметрами базы и новые пользователи с правами администратора.

Почему дело не только в WordPress

Механика этой уязвимости — частный случай общего правила: в папках, куда система пишет файлы, нельзя выполнять PHP. Неважно, что это за система.

Мы разбирали сайт, который заражали повторно по этой причине: закладки вычищали, а положить новый файл в папку загрузок и выполнить его можно было снова. Там была другая платформа, но причина та же.

Что это значит практически: пока вы разбираетесь с обновлением, имеет смысл пройти по остальным папкам записи — загрузки, кеш, временные каталоги — и закрыть выполнение скриптов во всех.

Когда смена платформы действительно решает проблему

Скажем прямо: эта уязвимость — не повод переезжать. Она закрывается обновлением, которое занимает минуты, и так же будет закрываться следующая. Менять систему из-за одной записи в списке исправлений — дорого и бессмысленно.

Но есть ситуации, в которых разговор о переезде уместен, и они не про конкретную уязвимость:

• Сайт годами не обновляется, и обновить его страшно. Обычно это значит, что ядро обвешано правками или темой, которая ломается на новой версии. Пока так, каждый новый выпуск безопасности — это выбор между риском сломать сайт и риском его потерять.
• Нет подрядчика и регламента сопровождения. Безопасность — это не разовая настройка, а привычка смотреть за обновлениями. Если смотреть некому, платформа не спасёт никакая.
• Нужна связка с учётной системой и CRM. Каталог, цены и заказы из 1С, заявки в CRM, личный кабинет клиента — здесь дело уже не в безопасности, а в том, что на прежней платформе это делается костылями.
• Требования к импортозамещению или к работе с персональными данными. Когда сайт попадает в периметр, который проверяют, вопрос о платформе задают первым.

Если хотя бы два пункта про вас, перенос на 1С-Битрикс стоит хотя бы посчитать: с сохранением адресов страниц, мета-тегов и позиций в поиске. Если нет — обновите WordPress, закройте каталог обновлений и живите спокойно. Это честный ответ.