Уязвимость WordPress CVE-2026-119977: взлом сайта во время обновления и как от этого защититься

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

Ниже — как она работает, кого затрагивает и что сделать, чтобы закрыться.

Коротко об уязвимости

• Что это: состояние гонки (race condition, класс TOCTOU) в процессе полного обновления ядра WordPress.
• Оценка опасности: CVSS 8.1 (высокая).
• Затронутые версии: WordPress с 4.7 по 7.1.3 включительно.
• Что нужно атакующему: только доступ к сайту по HTTP. Авторизация и действия администратора не требуются.
• Эксплуатация: 3 ноября 2026 года CISA внесла уязвимость в каталог активно эксплуатируемых (KEV). Wordfence зафиксировал более 18 500 запросов к уязвимым путям за первые 21 час после раскрытия деталей.

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

При полном обновлении ядра WordPress действует так:

1. Скачивает архив с новой версией.
2. Распаковывает его во временную папку внутри wp-content/upgrade/.
3. Копирует файлы поверх рабочего сайта.
4. Удаляет временную папку.

Проблема в том, что временная папка лежит по предсказуемому пути и доступна из браузера. А внутри неё — полная копия WordPress, включая установщик setup-config.php.

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

Окно атаки — секунды, пока длится обновление. Поэтому провести атаку на практике непросто, но массовые сканеры перебирают уязвимые пути постоянно и рассчитывают как раз на совпадение по времени.

В версии 7.1.4 имя временной папки сделали случайным, добавили защиту от прямого доступа и запретили перенос конфигурации из временной копии.

Хронология

Исправленные версии

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

Версии 4.6 и старше исправления не получили. Такие сайты нужно обновить до актуальной версии или вывести из эксплуатации.

Шаг 1. Проверьте версию WordPress

В админке: Консоль → Обновления. Не полагайтесь на автообновление — оно могло не сработать: быть отключено, упасть из-за прав на файлы или быть переопределено плагином.

Через WP-CLI:

wp core version

Если на сервере несколько сайтов, найти все установки WordPress и их версии можно так:

find /var/www -path '*/wp-includes/version.php' -exec grep -H "wp_version =" {} \;

Замените /var/www на каталог, где лежат ваши сайты.

Шаг 2. Закройте доступ к wp-content/upgrade/ (для VPS и выделенных серверов)

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

nginx

Добавьте в блок server вашего сайта:

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

Проверьте конфигурацию и перезагрузите nginx:

nginx -t && systemctl reload nginx

Apache и LiteSpeed

Добавьте в .htaccess в корне сайта, выше стандартного блока # BEGIN WordPress:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-content/upgrade/ - [F,L]
</IfModule>

Если у вас есть доступ к конфигурации виртуального хоста Apache, надёжнее закрыть каталог там:

<Directory "/var/www/example.com/wp-content/upgrade">
    Require all denied
</Directory>

Замените путь на свой и перезагрузите Apache:

apachectl configtest && systemctl reload apache2

На AlmaLinux, Rocky и других системах на базе RHEL служба называется httpd.

Проверьте, что запрет работает

curl -I https://example.com/wp-content/upgrade/

В ответе должен быть код 403.

Шаг 3. Сделайте резервную копию

Перед обновлением сохраните файлы сайта и базу данных. Через WP-CLI:

wp db export ~/backup-$(date +%F).sql
tar -czf ~/site-files-$(date +%F).tar.gz -C /var/www/example.com .

Если у вас VPS, можно дополнительно сделать снимок сервера в панели управления.

Шаг 4. Обновите WordPress

Через админку или WP-CLI

Если вы закрыли доступ к wp-content/upgrade/ (шаг 2), обновляйтесь штатно — из админки или через WP-CLI:

wp core update
wp core update-db
wp core version

Последняя команда должна показать 7.1.4 или исправленную версию вашей ветки.

Вручную, без окна атаки

Если закрыть доступ к каталогу на уровне веб-сервера нельзя (например, нет прав на конфигурацию), безопаснее обновиться вручную. Архив распаковывается вне корня сайта, а файлы копируются поверх, не затрагивая wp-config.php и wp-content:

cd /tmp
wget https://wordpress.org/latest.tar.gz
tar -xzf latest.tar.gz
rsync -a --exclude 'wp-content' --exclude 'wp-config.php' /tmp/wordpress/ /var/www/example.com/
rm -rf /tmp/wordpress /tmp/latest.tar.gz

Затем верните владельца файлов (пользователь веб-сервера может отличаться, например nginx или apache) и обновите базу данных:

chown -R www-data:www-data /var/www/example.com
wp core update-db

Вместо последней команды можно открыть в браузере https://example.com/wp-admin/upgrade.php.

Не забудьте плагины и темы

wp plugin update --all
wp theme update --all

Шаг 5. Проверьте сайт на следы взлома

Если сайт обновлялся с уязвимой версии после 28 октября, стоит убедиться, что атакой никто не воспользовался.

Запросы к временным установщикам в логах:

# nginx
grep -E "wp-content/upgrade/.*\.php" /var/log/nginx/access.log*

# Apache
grep -E "wp-content/upgrade/.*\.php" /var/log/apache2/access.log*

Особенно подозрительны запросы с кодом ответа 200.

Подмена wp-config.php: проверьте дату изменения файла и параметры подключения к базе данных.

ls -l /var/www/example.com/wp-config.php
grep -E "DB_(NAME|USER|HOST)" /var/www/example.com/wp-config.php

Целостность файлов ядра:

wp core verify-checksums

Посторонние PHP-файлы и администраторы:

find /var/www/example.com/wp-content/upgrade /var/www/example.com/wp-content/uploads -name "*.php"
find /var/www/example.com -name "*.php" -mtime -10
wp user list --role=administrator

Если нашли подменённый wp-config.php, незнакомых администраторов или посторонние PHP-файлы — считайте сайт скомпрометированным. Восстановите его из резервной копии, сделанной до 28 октября, обновите WordPress и смените все пароли: администраторов, базы данных, FTP и SSH.

Если сайт обслуживает подрядчик

Перешлите ему эту статью и попросите подтвердить, что сайт обновлён до исправленной версии и проверен на следы взлома.

Если нужна помощь

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