Одна из свежих уязвимостей WordPress затрагивает версии с 4.7 по 7.1.3 и опасна не только до, но и во время установки исправления. Исследователь Umut Bayram из Picus Security выяснил: в момент обновления сайт может на короткое время снова стать доступным для выполнения кода на сервере.

Для владельцев WordPress-сайтов это неприятная ловушка: патч ставят как раз для защиты, но сам процесс установки может создать окно для атаки. На фоне активной эксплуатации уязвимости CISA уже внесла ее в каталог известных проблем, которые используют в реальных атаках.

История инцидента

Речь идет об уязвимости CVE-2026-119977. WordPress выпустил исправление в версии 7.1.4 и в сопутствующих обновлениях для старых веток, но сам механизм установки патча оказался неидеальным.

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

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

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

Что пошло не так в защите

Ключевая ошибка — в доверии к механике обновления. WordPress рассчитывает, что служебная папка недоступна извне, но на практике так бывает не всегда. Если веб-сервер видит wp-content/upgrade, атакующий получает шанс подсмотреть временный каталог и дотянуться до установщика.

На сайтах на ветке 5.9 и новее старый код еще и называет папку по имени загруженного файла. Это делает имя предсказуемым в последний раз — как раз на том обновлении, которое ставит исправление.

Есть и еще один важный нюанс. WordPress частично закрывает саму уязвимость уже в процессе установки патча: он копирует файлы на место с помощью нового кода. Но уязвимый механизм распаковки все еще работает до самого конца процедуры.

Иначе говоря, патч исправляет проблему, но не отменяет риск на переходном этапе. Поэтому рассчитывать только на кнопку «обновить» нельзя.

Уроки для читателя

Первый вывод простой: служебные каталоги нельзя оставлять открытыми наружу без необходимости. Это касается не только WordPress, но и любой системы, где обновления пишут временные файлы рядом с рабочими.

Второй вывод — обновление нужно готовить заранее. Если у вас сайт на WordPress, сначала закройте доступ к wp-content/upgrade, а уже потом запускайте установку. Для Nginx подойдут правила уровня deny all, для Apache — Require all denied внутри блока каталога.

Если править конфиг нельзя и остается только .htaccess, его можно разместить в корне сайта с правилом на возврат 403 для wp-content/upgrade. Но не кладите .htaccess внутрь самой папки обновления: старый updater все равно удалит ее содержимое.

После этого проверьте, что запрос к /wp-content/upgrade/ действительно возвращает 403. Только затем переходите на 7.1.4 или на исправленную версию вашей ветки.

Отдельно стоит помнить про автоматические обновления. Они тоже используют тот же механизм, а значит требуют той же защиты. И если сайт работает на старой ветке, лучше не тянуть: для WordPress 4.6 и старше исправления уже не выпускают.

Если вам нужно быстро освежить базовую гигиену защиты аккаунтов и админок, посмотрите наш разбор про сброс паролей и 2FA после подозрительной активности. Там та же логика: сначала закрываем точки входа, потом разбираем последствия.

Практические выводы и чек-лист

Ниже — короткий список действий, который поможет снизить риск во время обновления WordPress. Это не теория, а последовательность, которую можно пройти прямо сейчас.

  • Проверьте версию WordPress. Если у вас 4.7–7.1.3, обновление нужно планировать без задержек.
  • Закройте внешний доступ к wp-content/upgrade на уровне веб-сервера.
  • Убедитесь, что запрос к /wp-content/upgrade/ возвращает 403.
  • Обновите сайт до 7.1.4 или до исправленной версии вашей ветки.
  • Если админка развернута в офисе или вы ведете сайт из поездок, заранее подготовьте защищенный канал для работы вне офиса и не ставьте обновления через случайные сети.
  • Проверьте логи на странные запросы к PHP-файлам в wp-content/upgrade.
  • Посмотрите, не появились ли неизвестные администраторы, лишние плагины или чужие PHP-файлы.
  • Для старых сайтов без поддержки запланируйте миграцию на актуальную версию WordPress.

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

Поделиться: