WordPress CVE-2026-119977: обновите ядро до 7.1.4

В чём уязвимость и каких версий она касается

Запись NVD для CVE-2026-119977 (опубликована 31 октября 2026, обновлена 4 ноября, статус Analyzed) описывает её одним предложением: ядро WordPress уязвимо к удалённому выполнению кода в версиях с 4.7 по 7.1.3 из-за предсказуемых, доступных из веба каталогов подготовки, которые используются при полном обновлении ядра, что позволяет неаутентифицированным атакующим выполнить код на сервере во время обновления.

NVD оценивает уязвимость в 8,1 по CVSS 3.1: сетевой вектор, без привилегий и без участия пользователя, но высокая сложность атаки. Оценка сложности согласуется с описанием: атакующему нужно именно окно обновления, а не просто запрос к работающему сайту.

Исправление есть в WordPress 7.1.4, выпущенном 28 октября 2026. В анонсе релиз назван релизом безопасности с исправлениями нескольких проблем; в списке указана «слабость в процессе обновления WordPress, которая может привести к удалённому выполнению кода во время окна обновления», и рекомендуется обновиться немедленно. Также исправлены несколько хранимых XSS, хранимая проблема отказа в обслуживании в Interactivity API, ошибка, из-за которой неаутентифицированные пользователи могли увидеть неопубликованные наборы изменений кастомайзера, и обновлены встроенные корневые сертификаты после отзыва eMudhra. Так что даже для сайта, который вы считаете малорискованным, 7.1.4 это не необязательное обновление.

В анонсе также сказано, что исправления безопасности перенесены во все ветки, которые получают исправления безопасности, сейчас вплоть до 4.7, но «бэкпорты в работе и выйдут по мере готовности», а активно поддерживается только самая новая версия WordPress. Если вы на старой ветке и вам пока не предложили обновление, планируйте переход на 7.1.4.

Что CISA добавила 3 ноября и что там сказано

В JSON-ленте CISA KEV (версия каталога 2026.11.04) CVE-2026-119977 указана для «WordPress WordPress Core» как состояние гонки TOCTOU (time-of-check time-of-use) с dateAdded 2026-11-03 и dueDate 2026-11-06. В каталог KEV входят только уязвимости с надёжными данными об эксплуатации в реальных атаках, значит, эксплуатация подтверждена; что означает этот порог, объясняет термин KEV. Тип слабости в записи CWE-367, класс состояний гонки.

В записи есть ещё два поля, которые стоит читать как есть. Поле knownRansomwareCampaignUse равно «Unknown»: это значит, что использование в программах-вымогателях не зафиксировано, а не что оно исключено. И запись помечена forensicTriage: Yes, а в требуемом действии указаны BOD 26-04 CISA и её «Forensics Triage Requirements». Страницы CISA отклоняют автоматические запросы, поэтому прочитать это руководство мы не смогли; если нужны точные требования, откройте его на cisa.gov. Что эта пометка значит для обычного владельца сайта, по нашему прочтению: CISA ожидает, что вы будете искать признаки взлома, а не только поставите обновление. Поэтому в этой статье есть раздел с проверками.

Короткий срок важен только для федеральных агентств США, которые обязаны выполнять директиву. Для всех остальных это сигнал срочности: CISA считает, что это нужно исправить в течение нескольких дней.

Что окно обновления значит для вашего сайта

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

Отсюда три практических вывода, каждый из которых наше прочтение, а не утверждение источников:

• Автоматические фоновые обновления проходят тот же процесс. Сайт, который обновляет себя сам, входит в это окно, и никто за этим не следит. Для этой уязвимости исправление находится в версии, на которую вы переходите, поэтому важно уже быть на 7.1.4.
• Рискованный момент это обновление, поэтому безопасное состояние это уже стоять на 7.1.4. Если сайт всё ещё на 7.1.3 или старше, каждое следующее обновление, начинающееся с этой версии, запускает уязвимый процесс. Обновитесь сразу, не ждите тихого момента.
• Когда началась эксплуатация, мы не знаем. Источники этого не сообщают. Сайт, на котором на уязвимой версии когда-либо проходило обновление ядра, подпадает под проверки ниже.

Связанный материал: наш разбор уязвимостей PHP, раскрытых в том же месяце, PHP2Shell, которые затронули и серверы с WordPress. Один сканер из отчёта Arctic Wolf даже проверял, существует ли на цели файл wp-content/db.php.

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

Если можете, сначала сделайте резервную копию (снимок сервера или копию базы и файлов), потому что обновление ядра меняет файлы. Затем:

# версия и доступное обновление (WP-CLI, из каталога сайта)
wp core version
wp core check-update

# обновление ядра
wp core update
wp core version

Без WP-CLI используйте Консоль: Обновления, затем Обновить сейчас. Если обновлениями занимается хостинг, посмотрите версию в Консоли, в блоке «На виду», или внизу админки и спросите хостинг, какую версию он ставит.

Чтобы увидеть, какую версию официальный API релизов считает актуальной, без входа куда-либо:

curl -s https://api.wordpress.org/core/version-check/1.7/ | grep -o '"version":"[^"]*"' | head -1

5 ноября 2026 команда вернула 7.1.4. Если ваш wp core version ниже, вы не на исправленном релизе. Не ставьте WordPress из неофициального зеркала или «взломанного» пакета; используйте WordPress.org или встроенный механизм обновления.

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

Проверки только для чтения после обновления

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

# 1. файлы ядра против официальных контрольных сумм (из каталога сайта)
wp core verify-checksums

# 2. файлы плагинов против контрольных сумм wordpress.org (только плагины из wordpress.org)
wp plugin verify-checksums --all

# 3. учётные записи администраторов
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# 4. PHP-файлы там, где их быть не должно (в uploads лежат медиа, а не код)
find wp-content/uploads -type f -name "*.php" -ls

# 5. недавно изменённые PHP-файлы вне обычных обновлений плагинов и тем
find . -type f -name "*.php" -newermt 2026-10-28 -ls | head -50

Проверка 1 показывает файлы, отличающиеся от официального релиза или не входящие в него. Проверка 4 это классическое место веб-шелла: любой .php файл в каталоге uploads требует объяснения. Проверка 3 ловит самый частый приём закрепления, нового администратора.

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

Как снизить риск следующей ошибки в WordPress

• Включите автоматические обновления ядра и не отключайте. Исправление для этой уязвимости вышло 28 октября, а запись в каталоге CISA появилась 3 ноября. Сайт, который обновляется сам за день-два, был впереди этой кривой.
• Уберите то, чем не пользуетесь. Неиспользуемые плагины и темы это код, который можно атаковать. Удаляйте, а не просто отключайте.
• Не давайте PHP писать везде. Пользователь веб-сервера должен писать только в каталоги загрузок и кэша, а PHP не должен выполняться из uploads. Про учётные записи рассказывает руководство о минимальных привилегиях.
• Следите за изменёнными файлами. Контроль целостности файлов в корне сайта превращает тихий веб-шелл в оповещение.
• Сузьте админку. Двухфакторная аутентификация для администраторов и список разрешённых IP для wp-admin уменьшают то, что может сделать украденный пароль. Ограничение частоты и правила доступа описаны в материале лучшие практики безопасности nginx.
• Знайте свою поверхность атаки. Серверный слой под WordPress описывает чек-лист безопасности VPS.