WordPress 7.1.3: 7 исправлений безопасности

WordPress 7.1.3 вышел 6 октября 2026 года как maintenance и security-релиз. В нём исправлены 7 проблем безопасности и ещё 4 обычные ошибки.

WordPress.org прямо рекомендует установить обновление сразу. Если на сайте включены автоматические фоновые обновления core, процесс может начаться автоматически.

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

Что исправлено в WordPress 7.1.3

В официальном списке безопасности указаны семь исправлений.

Stored XSS на странице администрирования комментариев, который можно было задействовать через ожидающие модерации комментарии.
DoS в методе WP_Http::make_absolute_url().
Second-order SQL injection в экспорте WordPress WXR.
Слабость, позволявшая пользователям с ролью Author закреплять записи.
Неавторизованное раскрытие комментариев к приватным и неопубликованным записям.
XSS через Imgur embeds.
Проблема с параметрами hook вида {status}_{type}, которая могла приводить к коллизии имени action.

WordPress отдельно поблагодарил исследователей Trail of Bits, Anthropic, Patchstack и других участников security community, которые сообщили о проблемах ответственно.

Почему это обновление лучше не откладывать

Это не функциональный релиз с новыми блоками или изменением интерфейса. Его основная ценность — закрытие уязвимостей.

После публикации security-релиза детали исправлений становятся публичнее, а различия между старой и новой версиями можно анализировать. Поэтому долго оставлять production на уязвимой версии не стоит.

Особенно это касается сайтов с:

открытыми комментариями;
несколькими авторами и редакторами;
экспортом и импортом контента;
WooCommerce;
личными кабинетами;
большим количеством плагинов, которые используют WordPress HTTP API и hooks.

Stored XSS через комментарии

Одна из закрытых проблем связана со страницей комментариев в админке. Уязвимость относится к stored XSS и могла использовать ожидающие модерации комментарии.

Stored XSS опасен тем, что вредоносное содержимое хранится в системе и может выполниться позже, когда администратор откроет соответствующий экран.

Для сайтов с публичной формой комментариев это дополнительная причина не откладывать обновление.

Second-order SQL injection в WXR

В релизе также закрыта second-order SQL injection, связанная с WXR export.

Second-order означает, что опасные данные могут сначала попасть в систему, а уязвимость проявляется позже, когда сохранённое значение используется в другом запросе или процессе.

Это отличается от простого сценария, где SQL injection происходит непосредственно в момент получения входного параметра.

Исправлена утечка комментариев приватных записей

Ещё одна проблема позволяла без авторизации получить комментарии, относящиеся к приватным или неопубликованным материалам.

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

Security fixes backportятся на старые ветки

WordPress сообщает, что необходимые security-исправления будут backportиться на ветки, которые ещё имеют право получать security updates — сейчас вплоть до WordPress 4.7.

При этом WordPress.org напоминает, что активно поддерживается именно последняя версия. Поэтому наличие backport не означает, что старый сайт стоит годами оставлять на устаревшем core.

Как безопасно обновить рабочий сайт

Чек-лист перед и после обновления

Проверить наличие свежего backup файлов и базы данных.
Зафиксировать текущие версии WordPress, темы и критичных плагинов.
Обновить WordPress core до 7.1.3.
Очистить серверный и page cache, если он используется.
Проверить frontend и мобильную версию.
Проверить вход в админку и редактирование материалов.
Для WooCommerce проверить карточку товара, корзину, checkout и письма заказа.
Проверить формы, API-интеграции и cron-задачи.
Посмотреть PHP/error logs после обновления.

Нужно ли сначала обновлять плагины

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

На активно поддерживаемом сайте security-релиз core обычно устанавливается оперативно, после чего проверяются критичные сценарии.

Если есть кастомная тема, старые плагины или нестандартные интеграции, разумно провести обновление через staging или хотя бы иметь рабочий rollback.