WordPress 7.1.4: что проверить перед срочным обновлением
28 октября WordPress выпустил 7.1.4 с исправлениями безопасности. Разбираем затронутые ветки, безопасный порядок обновления и критерии приёмки для сайта, магазина и интеграций.
В этой статье
Если у вас самостоятельная установка WordPress, сегодня стоит проверить фактическую версию ядра, сделать восстанавливаемую резервную копию и установить исправленный выпуск своей ветки. После обновления мало увидеть зелёную галочку: нужно подтвердить версию, открыть публичные страницы и админку, провести критический сценарий сайта и проверить журнал ошибок.
28 октября 2026 года WordPress выпустил 7.1.4 как обновление безопасности. В него вошли исправления слабого места в процессе обновления, которое могло привести к выполнению кода во время окна обновления, нескольких сохранённых XSS, отказа в обслуживании в Interactivity API, раскрытия части данных, а также обновление поставляемого набора корневых сертификатов в связи с отзывом eMudhra. Сохранённая XSS — это вредоносный фрагмент, который записывается на сайте и затем выполняется в браузере пользователя с подходящими правами.
Сам факт публикации уязвимостей не доказывает взлом конкретного сайта. Но откладывать обновление до появления инцидента — странный способ проверять, насколько точна формулировка «срочно».
Кого касается выпуск
В первую очередь — владельцев самостоятельных установок WordPress и команд, которые отвечают за их обновление. На управляемом хостинге обновление может выполнять провайдер, но это нужно подтвердить по фактической версии сайта и уведомлению провайдера. Автоматическое обновление тоже не равно приёмке: оно могло ещё не завершиться или остановиться из-за прав, места на диске либо несовместимости.
WordPress сообщил, что исправления перенесены в ветки, которые ещё получают обновления безопасности, вплоть до 4.7. При этом активно поддерживается только самая свежая версия. Поэтому старую ветку можно временно закрыть её выпуском безопасности, но долгосрочный план всё равно должен вести к актуальной версии после проверки совместимости.
Какая версия должна быть после обновления
7.1 → 7.1.4, текущий выпуск WordPress;
7.0 → 7.0.8 и 6.9 → 6.9.11: в обе ветки включены все 22 исправления;
6.8 → 6.8.12 и 6.7 → 6.7.11: по 20 исправлений;
6.6 → 6.6.11, 6.5 → 6.5.14 и 6.4 → 6.4.14: 19, 17 и 17 исправлений;
6.3 → 6.3.14, 6.2 → 6.2.15, 6.1 → 6.1.16 и 6.0 → 6.0.18: по 9 исправлений;
5.9 → 5.9.20: 9 исправлений;
5.8 → 5.8.19, 5.7 → 5.7.21, 5.6 → 5.6.23, 5.5 → 5.5.24, 5.4 → 5.4.25, 5.3 → 5.3.27, 5.2 → 5.2.30, 5.1 → 5.1.28 и 5.0 → 5.0.31: по 6 исправлений;
4.9 → 4.9.35, 4.8 → 4.8.34 и 4.7 → 4.7.39: 4, 2 и 2 исправления;
4.6 и старше: выпуска безопасности нет.
Число исправлений различается между ветками: нельзя утверждать, что любой старый выпуск получил все 22 изменения. Для веток 4.6 и старше исправлений в этом выпуске нет — такой сайт требует отдельного плана миграции, а не ещё одной попытки «подождать патч».
Безопасный порядок обновления
Зафиксируйте текущую версию ядра, активную тему, критические плагины, версию PHP и ответственного за окно работ. На управляемом хостинге уточните, обновляет ли провайдер именно ядро сайта.
Создайте резервную копию базы данных и файлов. Проверьте, что копия завершилась без ошибки, доступна не только внутри обновляемого сайта и для неё понятен порядок восстановления.
Для магазина или другого критичного сайта сначала повторите обновление на совместимом стенде. Проверьте тему, плагины, интеграции, планировщик и требования к PHP.
Установите исправленный выпуск своей ветки через штатный механизм WordPress. Не заменяйте отдельные файлы случайным архивом: это усложняет проверку целостности и откат.
Сразу после обновления подтвердите номер версии и выполните короткую приёмку. Если обновление не завершилось, остановитесь, сохраните журналы и возвращайте работоспособную версию по заранее проверенному плану.
Что проверить после обновления
главная страница, несколько внутренних страниц и загрузка статических файлов без ошибок 5xx;
вход в административную часть, открытие редактора и сохранение безопасного тестового изменения;
для магазина — карточка товара, корзина, оформление тестового заказа без реального списания и получение уведомления;
формы обратной связи, REST API, вебхуки и другие интеграции, которые зависят от авторизации или фоновых задач;
планировщик WordPress и системный cron, если он используется вместо встроенного запуска по посещениям;
журналы PHP и веб-сервера: нет новых фатальных ошибок, бесконечных повторных попыток выполнения одной и той же задачи и резкого роста ответов 4xx/5xx.
Критерий результата: сайт сообщает исправленную версию, публичные и административные сценарии выполняются, критическая интеграция отдаёт ожидаемый результат, а новые ошибки не появляются. Один доступный URL с кодом 200 подтверждает только этот ответ, не работу магазина целиком.
Если обновление уже прошло автоматически
Не запускайте повторное обновление только ради спокойствия. Сначала прочитайте фактическую версию, время завершения и журналы. Затем выполните ту же короткую приёмку. Если версия осталась прежней, ищите причину остановки: права на файлы, свободное место, зависший режим технического обслуживания WordPress, несовместимость расширения или политика управляемого хостинга.
Если есть признаки компрометации
Не считайте обновление расследованием. Сохраните журналы и снимок состояния, ограничьте доступ к затронутому сайту, проверьте неизвестных администраторов, изменения файлов и задания планировщика. Смену паролей и ключей выполняйте после сохранения доказательств и устранения точки входа, иначе можно потерять контекст и оставить причину на месте.
Первоисточники и границы
В официальном сообщении WordPress о выпуске 7.1.4 перечислены классы исправленных проблем и рекомендация обновить сайты сразу.
Страница WordPress 7.1.4 в документации содержит ветки, номера исправленных выпусков и количество перенесённых исправлений. Данные проверены 29 октября 2026 года; для конкретного сайта дополнительно важны его плагины, тема, PHP и модель хостинга.
If you have a self-managed WordPress installation, today is the day to verify the actual core version, create a recoverable backup, and install the patched release for your branch. After updating, simply seeing a green checkmark is not enough: you must confirm the version, open public pages and the admin panel, run a critical site scenario, and review the error log.
On October 28, 2026, WordPress released 7.1.4 as a security update. It includes fixes for a vulnerability in the update process that could lead to code execution during the update window, several stored XSS issues, denial of service in the Interactivity API, partial data disclosure, and an update to the bundled root certificate set following the revocation of eMudhra. Stored XSS is a malicious snippet that is written to a site and later executed in a user's browser with appropriate permissions.
The mere publication of vulnerabilities does not prove that a specific site was compromised. However, delaying an update until an incident occurs is a strange way to test the accuracy of the term 'urgent'.
Who this release affects
First and foremost, owners of self-managed WordPress installations and teams responsible for their updates. On managed hosting, the provider may perform updates, but this must be confirmed against the site's actual version and the provider's notification. Automatic updates are not equivalent to acceptance testing: the process may not have finished yet or may have stopped due to permissions, disk space, or incompatibility.
WordPress stated that the fixes were backported to branches still receiving security updates, down to version 4.7. However, only the latest version is actively supported. Therefore, an older branch can be temporarily secured with a security release, but the long-term plan must still lead to the current version after compatibility verification.
Which version should be targeted after the update
7.1 → 7.1.4, current WordPress release;
7.0 → 7.0.8 and 6.9 → 6.9.11: both branches include all 22 fixes;
6.8 → 6.8.12 and 6.7 → 6.7.11: 20 fixes each;
6.6 → 6.6.11, 6.5 → 6.5.14, and 6.4 → 6.4.14: 19, 17, and 17 fixes;
6.3 → 6.3.14, 6.2 → 6.2.15, 6.1 → 6.1.16, and 6.0 → 6.0.18: 9 fixes each;
5.9 → 5.9.20: 9 fixes;
5.8 → 5.8.19, 5.7 → 5.7.21, 5.6 → 5.6.23, 5.5 → 5.5.24, 5.4 → 5.4.25, 5.3 → 5.3.27, 5.2 → 5.2.30, 5.1 → 5.1.28, and 5.0 → 5.0.31: 6 fixes each;
4.9 → 4.9.35, 4.8 → 4.8.34, and 4.7 → 4.7.39: 4, 2, and 2 fixes;
4.6 and older: no security release.
The number of fixes varies between branches: it cannot be assumed that any old release received all 22 changes. Branches 4.6 and older have no fixes in this release; such sites require a separate migration plan, not another attempt to wait for a patch.
Safe update sequence
Record the current core version, active theme, critical plugins, PHP version, and the person responsible for the maintenance window. On managed hosting, confirm whether the provider updates the site core specifically.
Create a backup of the database and files. Verify that the backup completed without errors, is accessible outside the site being updated, and that the restoration procedure is clear.
For a store or other critical site, first repeat the update on a compatible staging environment. Check the theme, plugins, integrations, scheduler, and PHP requirements.
Install the fixed release of your branch via the standard WordPress mechanism. Do not replace individual files with a random archive: this complicates integrity verification and rollback.
Immediately after the update, confirm the version number and perform a brief acceptance test. If the update does not complete, stop, save the logs, and revert to the working version using a pre-verified plan.
What to verify after the update
the homepage, several internal pages, and loading of static files without 5xx errors;
access to the admin area, opening the editor, and saving a safe test change;
for a store: product card, cart, placing a test order without real payment deduction, and receiving a notification;
contact forms, REST API, webhooks, and other integrations that depend on authorization or background tasks;
the WordPress scheduler and system cron, if it is used instead of the built-in visitor-triggered execution;
PHP and web server logs: no new fatal errors, no infinite retry loops for the same task, and no sharp increase in 4xx/5xx responses.
Success criteria: the site reports the corrected version, public and administrative scenarios execute correctly, critical integrations return expected results, and no new errors appear. A single accessible URL returning a 200 status code confirms only that specific response, not the full functionality of the store.
If the update has already run automatically
Do not run a repeat update just for peace of mind. First, check the actual version, completion time, and logs. Then perform the same short acceptance test. If the version remains unchanged, look for the cause of the stop: file permissions, free space, a stuck WordPress maintenance mode, extension incompatibility, or a managed hosting policy.
If there are signs of compromise
Do not treat the update as an investigation. Save the logs and a state snapshot, restrict access to the affected site, check for unknown administrators, file changes, and cron jobs. Change passwords and keys only after preserving evidence and eliminating the entry point; otherwise, you may lose context and leave the cause in place.
Sources and boundaries
In the official WordPress 7.1.4 release announcement, the classes of fixed issues are listed along with a recommendation to update sites immediately.
The WordPress 7.1.4 documentation page contains branches, fixed release numbers, and the count of backported fixes. Data verified on October 29, 2026; for a specific site, its plugins, theme, PHP version, and hosting model are additionally critical.
Обсуждение 0
Делись опытом и задавай вопросы. Комментарии без ссылок появляются после проверки редактором.
Пока никто не написал. Начни обсуждение.