После недавнего обновления WordPress до 7.1.1 может появиться новое предупреждение о безопасности. Для уязвимости в выборе шаблона страницы эта версия ещё не содержит исправления: в ветке 7.1 нужен выпуск 7.1.2. Владельцу сайта важно получить подтверждение установленной версии и проверки темы, а при признаках посторонних изменений — отдельно проверить целостность проекта.
Кому это актуально
Разбор нужен владельцу коммерческого сайта на WordPress, который хочет понять, закрыто ли предупреждение от 22 сентября 2026 года. Особенно полезен он, если тему дорабатывали под бизнес, используется дочерняя тема или обновлением занимается хостинг и результат виден только из письма.
В официальном сообщении «WordPress 7.1.2 Release» от 22 сентября исправление названо критическим. Оно касается выбора PHP-файла при загрузке шаблона страницы. Возможность удалённого выполнения кода зависит от сочетания условий в активной теме и серверном окружении. Само предупреждение не доказывает, что конкретный сайт уже взломан.
Какие риски закрывает
В официальном advisory WordPress, опубликованном в тот же день, указано: злоумышленнику не требуется учётная запись. Поэтому ограничение регистрации пользователей само по себе не подтверждает устранение этой ошибки.
Одно из условий связано с каталогом, имя которого начинается с page-, в корне активной родительской или дочерней темы. Имеет значение и наличие доступного для чтения локального PHP-файла вне каталогов темы; возможность выполнения кода зависит от окружения. Проверять сочетание условий должен разработчик, который понимает устройство проекта.
Для владельца здесь две разные задачи: установить исправление и выяснить, нет ли оснований для расследования уже произошедших изменений. Обновление закрывает известную ошибку, но не является проверкой отсутствия чужих файлов, пользователей или ранее внесённых правок.
Папка с подходящим именем — повод проверить условия, а не доказательство заражения. Не переименовывайте каталоги темы и не запускайте найденные в интернете проверки атаки на рабочем сайте.
Что проверить до любых правок
1. Какая версия действительно работает
В админке посмотрите установленную версию WordPress и дату последнего обновления. Сохраните эти сведения для своего подрядчика. Если сайтов несколько, составьте отдельную строку для каждого: письмо об обновлении одного сайта не подтверждает состояние остальных.
Для ветки 7.1 официальный выпуск с исправлением — 7.1.2. Для старых веток существуют отдельные исправленные версии: их следует сверить с таблицей Patched versions в официальном advisory. Наличие такого исправления не означает полноценную поддержку старой ветки в дальнейшем.
2. Какая тема активна
Запишите название и версию активной темы, а также наличие дочерней. Дочерняя тема хранит собственные изменения и использует родительскую, поэтому проверка должна учитывать обе. Названия достаточно для начала разговора; оно не заменяет просмотр фактического состава файлов, если тему меняли вручную.
Попросите разработчика письменно зафиксировать, проверены ли условия из advisory. Ответ «используем популярную тему» или «у нас закрыта регистрация» не содержит результата такой проверки.
3. Можно ли установить исправление с контролем результата
До изменения нужны резервная копия файлов и базы, понятный способ восстановления и список страниц на разных шаблонах. На тестовой копии следует отключить реальные платежи, рассылки и передачу заявок во внешние системы.
В проверку включите обычную страницу, страницу с отдельным шаблоном и важный для бизнеса сценарий: форму или оформление заказа. Не объединяйте срочное исправление с редизайном и заменой нескольких плагинов — иначе причину возможного сбоя будет труднее локализовать.
4. Есть ли наблюдаемые признаки посторонних изменений
Незнакомый администратор, чужой редирект или неожиданная правка страницы требуют отдельного разбора. Запишите время обнаружения и видимый симптом. Эти признаки сами по себе не устанавливают причину и не связывают инцидент именно с этой уязвимостью.
Если есть подозрение на компрометацию, согласуйте с ответственным специалистом сохранение журналов и копии состояния. Не удаляйте подозрительные файлы наугад: можно потерять следы и одновременно нарушить работу сайта.
Как подтвердить результат
Принимать работу стоит по двум группам доказательств.
- Исправление установлено. Подтверждена фактическая версия ядра на рабочем сайте и её соответствие официальному исправленному выпуску. Если есть несколько экземпляров сайта, проверен каждый.
- Рабочие сценарии сохранены. После выкладки открываются страницы на проверяемых шаблонах, доступна админка, согласованные проверки формы или заказа завершаются ожидаемым результатом. Проверки не должны создавать реальные списания и нежелательные уведомления.
Например, в отчёте может быть строка: «Страница услуги на отдельном шаблоне — до изменения открывалась, после изменения открывается; форма проверена в согласованном тестовом режиме». Это пример формата приёмки, а не результат работ на конкретном проекте.
Если сайт после обновления выдаёт ошибку, подрядчику нужен план восстановления работоспособности с сохранением исправления безопасности. Возврат к прежней уязвимой версии нельзя считать завершением задачи.
Что запросить у подрядчика
Достаточно короткого отчёта, в котором есть:
- Установленная версия до и после работ и время проверки рабочего сайта.
- Активная родительская и дочерняя темы, результат проверки условий advisory.
- Место хранения резервной копии и ответственный за восстановление.
- Список проверенных страниц и сценариев с результатом каждого.
- Отдельный вывод о признаках посторонних изменений: что проверено, что осталось неизвестным.
Пароли, содержимое конфигурации и полные журналы не нужны в обычной переписке с заявкой. Для технического разбора доступы и файлы передают по согласованному защищённому каналу.
Как это решает OpenStart
В рамках поддержки WordPress OpenStart проверяет ядро, тему, плагины, PHP, резервные копии и критичные сценарии. Для такого обращения первым шагом будет уточнение состояния проекта и состава проверки; объём обновления и возможного восстановления зависит от полученных данных.
Если у вас уже есть ответственный разработчик, рабочие копии и подтверждённый результат обновления, перечисленных критериев достаточно для приёмки без смены подрядчика. Отдельная помощь нужна, когда нет доступа к окружению, неизвестен состав доработок темы или появились признаки посторонних изменений.
Частые вопросы
Достаточно ли письма об автоматическом обновлении?
Письмо полезно как уведомление. Результат подтверждают фактическая версия рабочего сайта и проверка важных страниц. При нескольких установках их состояния могут различаться.
Нужно ли менять тему целиком?
Из описания уязвимости такой вывод не следует. Официальное исправление выпущено в ядре WordPress. Решение о замене темы требует отдельной причины, например невозможности её дальнейшего сопровождения.
Если подозрительных изменений нет, можно отложить обновление?
Отсутствие видимых симптомов не подтверждает безопасность. В сообщении о релизе WordPress рекомендует установить исправление немедленно. Организуйте контролируемое обновление с ответственным и проверкой результата.
Материал опирается на сообщение WordPress «WordPress 7.1.2 Release» и официальный advisory «Unauthenticated path traversal in page-template resolution leading to conditional RCE» от 22 сентября 2026 года.