WordPress 7.1.3: что исправили и почему обновление нельзя откладывать

WordPress 7.1.3 вышел 6 октября 2026 года как maintenance and security release. В нём закрыты семь проблем безопасности и четыре обычные ошибки. Для security-релиза формулировка WordPress.org однозначная: сайты рекомендуется обновить немедленно. На 8 октября 7.1.3 остаётся последней опубликованной версией WordPress.

Но «обновить немедленно» не означает «нажать кнопку на production и надеяться, что всё прошло». Для рабочего сайта с собственной темой, плагинами, формами, комментариями и интеграциями правильная реакция на такой релиз — сократить окно риска, но не отказаться от резервной копии, staging и короткой проверки критических сценариев.

В этот раз обновление особенно интересно тем, что исправления находятся в совершенно разных частях ядра: комментарии и административный интерфейс, HTTP API, экспорт WXR, REST API и права авторов, доступ к комментариям закрытых материалов, oEmbed и динамические хуки статусов записей. Это не одна уязвимость с одним сценарием, поэтому оценивать 7.1.3 только по принципу «у нас комментарии отключены — значит можно не спешить» неправильно.

Почему WordPress 7.1.3 относится к обновлениям, которые не стоит откладывать

Предыдущий WordPress 7.1.2 security update решал отдельную version-specific security-задачу. Версия 7.1.3 — самостоятельный релиз с другим набором исправлений. Поэтому наличие 7.1.2 нельзя рассматривать как достаточную защиту от проблем, закрытых 6 октября.

WordPress.org перечисляет семь security fixes. Публичная release note не присваивает им CVSS, не сообщает о массовой эксплуатации и не утверждает, что какая-либо из этих проблем автоматически приводит к удалённому выполнению кода. Поэтому превращать список исправлений в «семь критических RCE» было бы неправильно. Из опубликованных данных следует более практичный вывод: затронуто сразу несколько поверхностей WordPress, а сам проект рекомендует оперативное обновление.

Для владельца production-сайта это означает две вещи. Во-первых, откладывать установку патча на недели ради «проверки сообществом» здесь нет смысла. Во-вторых, скорость обновления не отменяет контролируемый процесс: рабочая резервная копия, staging или эквивалентная тестовая среда, smoke test и только затем production.

Какие проблемы безопасности исправлены в WordPress 7.1.3

Stored XSS на странице управления комментариями

Первое официально указанное исправление касается stored XSS в административном интерфейсе Comments и связано с ожидающими модерации комментариями. Сам по себе термин stored XSS важен: проблемное содержимое сохраняется, а опасное поведение может проявиться позднее, когда с ним взаимодействует другой пользователь или административный интерфейс.

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

DoS в WP_Http::make_absolute_url()

Вторая проблема находилась в WP_Http::make_absolute_url() — методе HTTP API, который участвует в обработке и нормализации URL. Core Trac показывает конкретное защитное изменение: цикл нормализации относительного пути теперь отслеживает, произошло ли очередное преобразование, и прекращает работу, если строка больше не изменяется. Это предотвращает ситуацию, при которой обработка определённого пути может продолжаться без прогресса.

Для обычного администратора важно не название метода, а поверхность риска. WordPress и расширения регулярно работают с URL и HTTP-запросами, поэтому отсутствие на сайте публичной формы комментариев не исключает актуальность этого исправления.

Second-order SQL injection в WXR export

Третье исправление относится к экспорту WordPress в WXR. Здесь используется формулировка second-order SQL injection. В отличие от примитивного сценария, где вредоносное значение сразу попадает в SQL-запрос, second-order означает, что потенциально опасное значение сначала оказывается сохранено или проходит через другой этап системы, а проблемным становится позднее при повторном использовании.

В исправлении Core идентификаторы записей, включая значения, полученные из метаданных, приводятся к целым числам до формирования SQL-условия; дополнительная нормализация выполняется непосредственно перед использованием идентификаторов в запросе. Это хорошая иллюстрация принципа defense in depth: ранее сохранённым данным нельзя автоматически доверять только потому, что они уже находятся внутри базы.

Это не повод самостоятельно проверять production SQL-пейлоадами. Для администратора правильное действие — установить исправленную версию и после обновления, если экспорт используется в рабочих процессах, выполнить обычный тест WXR export на staging или на безопасном тестовом наборе данных.

Проверка прав при изменении sticky posts

Ещё одно исправление касается пользователей с ролью Author и изменения состояния sticky post через REST API. В Core усилена проверка capabilities: для изменения sticky-состояния теперь должны выполняться обе необходимые проверки прав, а при обновлении дополнительно учитывается, действительно ли запрошенное состояние отличается от текущего.

Смысл этого изменения шире конкретной кнопки «Закрепить». WordPress исправляет границу полномочий между ролями. Если сайт использует авторов, редакционные workflow, REST API, headless-компоненты или внешние панели публикации, этот участок заслуживает отдельного smoke test после обновления.

Раскрытие комментариев у private и unpublished posts без авторизации

Следующий fix закрывает возможность неавторизованного раскрытия комментариев, относящихся к private или ещё не опубликованным материалам. Изменение в WP_Query не позволяет выдавать комментарии для записей, которые пользователь не может просматривать.

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

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

XSS через Imgur embeds

WordPress также закрыл XSS, связанный с Imgur embeds. Исправление в Core не пытается «подлечить» конкретный HTML на стороне WordPress: встроенная поддержка Imgur как oEmbed-провайдера удалена. Это видно и в backport-изменениях Core Trac.

После обновления владельцу сайта не требуется удалять все обычные изображения или ссылки на Imgur. Но если проект активно использовал автоматические Imgur oEmbed-вставки, стоит проверить старые публикации и редакционный процесс: способ обработки таких URL после 7.1.3 изменён.

Forgeable parameters в динамическом хуке {status}_{type}

Седьмое исправление относится к динамическим хукам статуса и типа записи. В Core ограничена генерация таких status transition hooks зарегистрированными статусами и зарегистрированными post types, что устраняет возможность нежелательного совпадения имени action при подставных параметрах. В backport-описании WordPress прямо формулирует это как запуск динамических status transition hooks только для зарегистрированных значений.

Этот fix особенно важен разработчикам плагинов и собственных интеграций, которые подписываются на динамические события публикации. После обновления не нужно менять корректно зарегистрированные post types и statuses, но нестандартный код, рассчитывающий на произвольные значения, разумно проверить на staging.

Четыре bug fixes тоже входят в релиз, но причина срочности — security-часть

Официальная release note указывает не только семь security fixes, но и четыре bug fixes. Одно из подтверждённых maintenance-исправлений в milestone 7.1.3 касается Site Icon в admin toolbar: Core усилил ограничения размеров изображения, чтобы CSS темы или плагина не мог неожиданно развернуть иконку до исходного размера.

При этом смешивать maintenance и security не стоит. Обычный UI-баг может быть неприятным, но именно security-набор объясняет рекомендацию WordPress обновляться без промедления.

Как безопасно обновить production-сайт до WordPress 7.1.3

Для обычного сайта WordPress рекомендует стандартный one-click update через Dashboard → Updates. WP-CLI предоставляет тот же базовый сценарий для серверного управления через wp core update. Но наличие штатного механизма обновления не означает, что production нужно менять без точки восстановления. Официальная документация WordPress прямо рекомендует сделать backup перед обновлением, а документация для debugging советует перед изменениями иметь staging или подходящую резервную копию.

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

Проверяемая резервная копия — это не запись в панели «backup completed». Должно быть понятно, где находятся файлы и база, к какой дате относится копия и существует ли реальный путь восстановления. Для крупных проектов полезно заранее знать не только способ restore, но и ожидаемое время возврата сервиса.

На staging имеет смысл повторить именно production-конфигурацию: активную тему, критические плагины, PHP-версию, объектный кеш и ключевые интеграции. Security-релиз Core не должен превращаться в повод одновременно обновить десяток плагинов, поменять PHP и переработать конфигурацию кеша — иначе при регрессии будет сложнее определить источник.

После успешной staging-проверки production обновляется штатным механизмом. Если используется WP-CLI, wp core update обновляет Core до более новой версии, а wp core version позволяет отдельно проверить фактически установленную версию. Само сообщение об успешном завершении команды — ещё не весь post-update test.

Что проверить сразу после обновления

Первый критерий очевиден: фактическая версия Core должна быть 7.1.3. Если сайт настроен на automatic background updates, письмо или запись об автоматическом обновлении полезны как сигнал, но не заменяют фактическую проверку версии. WordPress действительно поддерживает фоновые minor/security updates на подходящих конфигурациях, однако итоговое состояние конкретного сайта нужно подтверждать отдельно.

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

Для сайта с комментариями отдельно проверяются отправка тестового комментария, его появление в очереди и экран модерации. Это особенно уместно для 7.1.3 из-за исправления stored XSS в Comments admin и изменений доступа к комментариям закрытых материалов.

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

Если после апдейта появляется 500, blank page или внезапно перестаёт открываться редактор, не стоит первым делом откатывать Core вслепую. Сначала нужно посмотреть PHP/server logs и отделить проблему ядра от несовместимости темы, плагина или кешированного кода. Для отдельной диагностики такого сценария у меня есть разбор причин белого экрана после обновления.

WordPress рекомендует debug-инструменты прежде всего для staging и development, а не для постоянного вывода ошибок на production. WP_DEBUG_LOG может помочь собрать PHP notices, warnings и errors, при этом WP_DEBUG_DISPLAY позволяет не выводить их посетителю.

Если на сервере используется OPcache или дополнительный application cache, после замены Core-файлов нужно учитывать конкретную конфигурацию инфраструктуры. Сбрасывать всё подряд «на всякий случай» не требуется, но при признаках выполнения старого PHP-кода или смешивания старых и новых assets кеши становятся отдельной точкой проверки.

Что происходит с backports на старые версии WordPress

В первоначальном сообщении о 7.1.3 WordPress написал, что security fixes будут перенесены, где это необходимо, на все ветки, которые ещё получают такие исправления, — на момент релиза вплоть до 4.7. При этом проект отдельно напоминает: активно поддерживается только самая свежая версия WordPress.

На 8 октября backports уже видны в Release Archive: например, 6.9.10 и 4.7.38 датированы 6 октября 2026 года. Core Trac также фиксирует перенос исправлений на ветку 4.7. Важно выражение «where necessary»: набор изменений в старой ветке может отличаться, если конкретная уязвимая функциональность там отсутствует. Например, backport на 4.7 включает шесть соответствующих core-изменений, тогда как более новые ветки, где применимо исправление WXR export, получают и его.

Это не аргумент оставаться на старой версии годами. Backport security patch уменьшает конкретный риск, но не превращает старую ветку в полноценно поддерживаемый современный WordPress. Если проект может работать на актуальной версии, нормальная цель — 7.1.3, а не поиск минимально старого релиза, куда был перенесён отдельный fix.

Практический сценарий для сайта с custom theme и плагинами

Представим production-проект с собственной темой, несколькими бизнес-плагинами, комментариями, формами и staging.

Сначала фиксируем исходное состояние: текущую версию WordPress, набор активных плагинов, рабочий frontend и несколько критических пользовательских сценариев. Затем создаём или проверяем свежий backup базы и файлов. Если копия существует только как строка в панели хостинга, желательно убедиться, что у неё доступен restore или скачивание.

На staging устанавливаем 7.1.3 без одновременной модернизации остальных компонентов. Проверяем главную, типовой материал, административную часть, редактирование записи, комментарии, форму заявки и ключевую интеграцию. Если проект использует экспорт WordPress, выполняем тест WXR export. Если используются роли Author или внешняя публикация через REST API, проверяем редакционный workflow.

При нормальном результате обновляем production штатным способом. После завершения проверяем установленную версию и повторяем сокращённый smoke test. При необходимости сбрасываем только те кеши или OPcache, которые реально могут удерживать старый код.

Последний шаг — посмотреть серверные и PHP-логи относительно периода до и после обновления. Один старый warning не означает регрессию. Нас интересуют новые fatal errors, резкий рост повторяющихся ошибок и проблемы, появившиеся непосредственно после смены Core.

Когда обновление можно считать завершённым

Установка 7.1.3 завершена не тогда, когда исчезло уведомление Dashboard, а когда подтверждено новое рабочее состояние сайта.

Минимальные критерии такие: Core действительно работает на актуальной patched version; публичный frontend открывается штатно; wp-admin и редактор работают; комментарии и модерация не сломаны; критические формы и интеграции проходят smoke test; в логах не появился новый поток PHP fatal/error; резервная копия остаётся доступной для восстановления.

Если все эти проверки пройдены, security update можно считать закрытым как операционную задачу. Если нет — проблема уже не в вопросе «обновляться ли до 7.1.3», а в диагностике конкретной несовместимости, которую следует локализовать по логам и воспроизвести на staging.

Для WordPress 7.1.3 главный вывод простой: это не функциональный релиз, который можно поставить «когда будет время». Он закрывает семь разных security-проблем в нескольких частях Core, и сам WordPress рекомендует обновиться без откладывания. При этом безопасный production-процесс остаётся прежним: проверяемая точка восстановления, staging, короткие тесты, controlled update и проверка результата.