невзлом

Срочно · WordPress

CVE-2026-119977 — последнее окно при установке патча, deny upgrade

· CVE-2026-119977

Это обновление к выпуску: WordPress 7.1.4 — RCE в окне полного обновления ядра (CVE-2026-119977)

← Простая версия для всех

Суть

Гонка TOCTOU при обновлении ядра: временная копия с установщиком веб-доступна; без аутентификации возможна RCE в окне. CISA KEV — да (dateAdded 2026-11-03, dueDate 2026-11-06, knownRansomwareCampaignUse Unknown, forensic triage Yes / BOD 26-04). CVSS 3.1 — 8.1 (CNA Wordfence).

Новое для операторов (вторично, по данным исследователя, 06.11.2026; ссылку не ставим): пакет с фиксом на уязвимом сайте распаковывается ещё непатченным updater. После 7.1.4 / бэкпорта последующие обновления — со случайным именем staging. Partial package не гарантирует безопасность (возможен complete). wp core update — тот же updater и каталог (исправляем формулировку выпуска 04.11).

Затронуто и исправлено

ВеткаИсправлено с
7.17.1.4
7.07.0.8
6.96.9.11
6.86.8.12
6.76.7.11
6.66.6.11
6.56.5.14
6.46.4.14
6.3–6.06.3.14 / 6.2.15 / 6.1.16 / 6.0.18
5.9–5.05.9.20 … 5.0.31 (см. HelpHub)
4.9–4.74.9.35 / 4.8.34 / 4.7.39

4.6− — без security-фиксов. Пример: 7.1.3 уязвима, 7.1.4 исправлена.

Эксплуатация

  • CISA: evidence of active exploitation (KEV).
  • Вторичные отчёты: попытки ловить момент обновления; число успешных — неизвестно.
  • Публичный PoC: не утверждаем; ссылок нет.

Как проверить

wp core version
wp core verify-checksums

Без CLI: «Консоль → Обновления» + 403 на upgrade + нет чужих администраторов.

  • Запрос к /wp-content/upgrade/ и PHP-имени под ним снаружи → 403 (CDN и origin отдельно).
  • Пользователи administrator; must-use; checksums ядра.

Как исправить

На ещё непатченном сайте — порядок:

  1. Сразу закрыть HTTP к каталогу обновлений (не ждать бэкап/тикет часами): у WP минорные/security в той же ветке часто уходят фоном; автообновление открывает то же окно. Пока нет 403 — не жмите Dashboard Update и по возможности временно отключите автообновление (AUTOMATIC_UPDATER_DISABLED / WP_AUTO_UPDATE_CORE / панель хостинга). Если патч уже ушёл сам — срочного окна нет; нужен triage админов/webroot.
  2. Копия файлов и БД вне webroot.
  3. Deny (WordPress пишет с ФС — обновления не ломаются):
# nginx, внутри server { ... } — без обязательного / в конце URI
location ^~ /wp-content/upgrade { deny all; }
# Apache vhost — свой filesystem path
<Directory "/var/www/html/wp-content/upgrade">
    Require all denied
</Directory>
# .htaccess в корне WP, ВЫШЕ # BEGIN WordPress (shared без root)
RedirectMatch 403 ^/wp-content/upgrade

Не кладите .htaccess внутрь wp-content/upgrade/ — непатченный unpack чистит каталог. Подсайт / кастомный WP_CONTENT_DIR — deny на фактический URL. Shared: нет прав на vhost и AllowOverride Off — только тикет хостингу; если снаружи не 403 — не запускайте upgrader, только ручная замена вне webroot или managed.

  1. Патч своей ветки (пример для 7.0: --version=7.0.8; не копируйте угловые скобки):
wp core update --version=7.0.8
wp core update-db
wp core version
wp core verify-checksums

⚠️ --version=7.1.4 на ветке 6.x уведёт major — для CVE достаточно бэкпорта своей линии.

Без веб-upgrader: официальный zip, распаковка вне webroot; заменить каталоги wp-admin и wp-includes, корневые PHP ядра — поверх; не трогать wp-config.php и wp-content; затем /wp-admin/upgrade.php или wp core update-db.

Docker / Composer / Bedrock / флот:

  • Ядро из образа/артефакта без upgrader на живом томе — поднять pin/тег → выкат → wp core version (безопасно относительно этого окна).
  • Update внутри тома со старым деревом — снова deny + updater или ручная замена.
  • Пачка сайтов: сначала deny/конфиг на всех → патч ветки → выборочный triage.

Критерий закрытия: версия ≥ таблицы и повторный 403 на upgrade.

Если обновить нельзя

Deny — временная мера, не замена патча. Для 4.6− — переход на поддерживаемую ветку. WAF-плагины не заменяют патч.

Признаки взлома и что делать

Неизвестные администраторы; PHP в uploads / вне плагинов; изменённые checksums; неожиданные must-use/cron. Изоляция при подтверждении → доказательства → чистая установка/проверенная копия после патча → смена секретов → аудит плагинов. Одного wp core update после компрометации недостаточно.

Источники