Патч WordPress может кратко открыть окно для эксплуатации CVE-2026-119977

Обновление WordPress до исправленной версии может на несколько секунд вновь открыть сайт для эксплуатации CVE-2026-119977. Уязвимость уже используется злоумышленниками, поэтому исследователь Picus Security Умут Байрам рекомендует до установки патча закрыть веб-доступ к каталогу wp-content/upgrade.

В чём состоит риск

Заявленный охват CVE-2026-119977 — WordPress версий с 4.7 по 7.1.3. Этот диапазон следует отличать от более старого механизма обновления, который, по оценке Байрама, существует с WordPress 2.7.

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

Если неаутентифицированный атакующий знает или может определить имя временного каталога и успевает обратиться к установщику до удаления распакованной копии, он может добиться выполнения кода на сервере. CISA на этой неделе добавило CVE-2026-119977 в каталог известных эксплуатируемых уязвимостей, не раскрыв деталей атак.

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

Однако пакет с исправлением первоначально распаковывается старым кодом обновления, уже установленным на сайте. На WordPress 5.9 и новее этот код присваивает временной папке имя, соответствующее загруженному файлу. Имя можно предсказать, а значит, остаётся последнее окно для атаки до полного применения исправления.

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

Тем не менее, как отмечает Байрам в техническом отчёте, злоумышленник, попавший в короткое окно обновления, всё ещё может настроить временную копию WordPress на собственной базе данных, войти в неё и выполнить PHP-код с правами веб-сервера до удаления этой копии. Это даёт возможность читать или изменять файлы действующего сайта WordPress.

Какие обновления создают окно атаки

Риск определяется не только фактом обновления, но и составом полученного пакета, а также кодом обновления, который уже установлен на сайте.

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

Проверка службы обновлений WordPress[.]org для нескольких версий показала, что при обновлении внутри одной ветки — например, с 7.1.3 до 7.1.4 — предлагался частичный пакет, в том числе для фонового автоматического обновления. При переходе между ветками, например с 7.0.7 на 7.1.4, предлагались только полные пакеты.

Наличие частичного пакета не означает, что сайт обязательно получит именно его. WordPress переключается на полный пакет, если файлы ядра не совпадают с официальными контрольными суммами или выполняется переустановка. В уточнении от 6 ноября Байрам указал, что определяющим фактором остаётся не тип пакета сам по себе, а наличие исправления в программе обновления, которая уже работает на сайте.

На WordPress 4.4–5.8 старый механизм добавляет к имени временной папки случайные символы. Это относится к историческому механизму обновления и затрудняет обнаружение каталога, если его имя не раскрывается иным способом, например через сообщение об ошибке.

После установки WordPress 7.1.4 или исправления для используемой ветки последующие обновления будут использовать случайное имя временного каталога, а wp-config.php из временной копии больше не сможет заменить рабочий конфигурационный файл.

Автоматические фоновые обновления не являются отдельным безопасным вариантом: они используют тот же модуль и ту же процедуру распаковки. Команда wp core update из WP-CLI также не устраняет риск, поскольку запускает тот же установщик и распаковывает пакет в тот же каталог.

При выборе SIEM-платформы можно отдельно изучить Security Capsule SIEM и сопоставить её с требованиями своей инфраструктуры.

Как обновиться безопаснее

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

Для Nginx предлагается добавить в конфигурацию:

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

Для Apache следует указать Require all denied внутри блока <Directory> для этого каталога в конфигурации виртуального хоста.

Если доступно редактирование только .htaccess, в корневой каталог WordPress, выше правил перенаправления WordPress, можно добавить:

RedirectMatch 403 ^/wp-content/upgrade/

Размещать .htaccess внутри wp-content/upgrade не следует. Старый механизм обновления очищает содержимое каталога перед распаковкой, поэтому этот файл будет удалён именно тогда, когда понадобится защита. После изменения конфигурации нужно убедиться, что запрос к /wp-content/upgrade/ возвращает HTTP 403, и лишь затем обновлять WordPress до 7.1.4 либо исправленной версии своей ветки.

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

WordPress 4.6 и более ранние версии не входят в заявленный диапазон CVE и исправлений, а также больше не получают обновлений безопасности. При этом Байрам связывает их с исторически существовавшим механизмом, который, по его оценке, появился в WordPress 2.7, выпущенном в 2008 году; такие сайты требуется перевести на поддерживаемую версию.

Поводы для расследования попыток эксплуатации

Wordfence, присвоившая уязвимости идентификатор CVE, сообщила о попытках атак через девять минут после развёртывания правила межсетевого экрана для защиты от CVE-2026-119977 в день выпуска. Два наиболее активных источника затем сканировали небольшие группы сайтов примерно 14,5 часа. По оценке компании, активность соответствует попыткам застать сайты в момент обновления.

Оценка CVE-2026-119977 составляет 8,1 из 10 по CVSS. В лабораторных испытаниях окно эксплуатации длилось лишь несколько секунд, хотя в предупреждении WordPress уязвимость отнесена к категории низкой серьёзности.

В начале этой недели в публичных репозиториях GitHub появился код, авторы которого называют его эксплойтом для этой уязвимости. Один из репозиториев заявляет, что код работает и против сайтов, где при обновлении полным пакетом по-прежнему используется предсказуемое имя каталога. Работоспособность этого кода пока не подтверждена.

Для сайтов, которые остались на уязвимых версиях после выхода обновления, Wordfence рекомендует проверить следующие признаки как поводы для расследования. Сами по себе они не подтверждают компрометацию и могут быть связаны со штатными или административными действиями:

• неожиданные обращения к PHP-файлам в wp-content/upgrade;
• неизвестные учётные записи администраторов;
• плагины, которые администраторы не устанавливали;
• PHP-файлы в wp-content/upgrade, не размещённые владельцем сайта.

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