WordPress 7.1.4 вышел 28 октября 2026 года и закрывает 22 уязвимости. Среди них состояние гонки при обновлении ядра, которое может привести к удаленному выполнению кода, и больше десятка stored XSS. Сайт стоит обновить в тот же день: зайдите в Консоль, проверьте, что версия стала 7.1.4, а перед ручным обновлением снимите резервную копию.
Об этом сообщили разработчики в официальном анонсе WordPress 7.1.4, полный список исправлений опубликован на странице версии 7.1.4 в документации WordPress. Это уже четвертый выпуск безопасности в ветке 7.1 за два месяца: до него были 7.1.1, 7.1.2 и 7.1.3 с семью исправлениями. Для владельца сайта в Казахстане это значит простую вещь: если обновления ядра у вас ставит человек «раз в квартал», сайт сейчас открыт сразу для нескольких известных уязвимостей.
Что исправлено в WordPress 7.1.4
В WordPress 7.1.4 только исправления безопасности, новых функций и обычных багфиксов в нем нет. Большая часть уязвимостей относится к типу stored XSS. Stored XSS (хранимый межсайтовый скриптинг) — это уязвимость, при которой злоумышленник сохраняет на сайте вредоносный код, например внутри записи или настройки блока, и этот код выполняется в браузере каждого, кто откроет страницу, включая администратора.
Вторая важная категория — RCE. Удаленное выполнение кода (RCE) — это возможность запустить на сервере собственную программу без физического доступа к нему. Для бизнеса такая уязвимость означает полную потерю контроля над сайтом: подмена страниц, вредоносные редиректы, кража базы клиентов и заявок.
Ниже сводка по исправлениям из официального списка. Колонка «кто может воспользоваться» показывает минимальную роль пользователя на сайте, которая нужна атакующему.
| Что исправлено | Кто может воспользоваться | Чем грозит |
|---|---|---|
| Состояние гонки при обновлении ядра | Роль в анонсе не указана | Удаленное выполнение кода |
| Несколько stored XSS в привязках Interactivity API | Участник (Contributor) и выше | Выполнение скрипта в браузере администратора, отказ в обслуживании |
| Stored XSS в блоках Comments Pagination, Post Navigation Link, Categories | Участник и выше (для Categories роль не указана) | Выполнение скрипта на страницах сайта |
| Stored XSS в выборочном обновлении Customizer | Участник и выше | Выполнение скрипта в окне настройщика темы |
| Утечка неопубликованных изменений Customizer | Любой посетитель без входа | Посторонние видят изменения дизайна и текстов до запуска |
| Stored XSS на экране запросов на удаление персональных данных | Редактор и выше | Выполнение скрипта в админке |
| Stored XSS в Interactivity Router через загруженные текстовые файлы | Автор и выше | Выполнение скрипта на сайте |
| Доступ к заметкам к записям у ролей-модераторов комментариев | Пользовательские роли с правом модерации | Чтение, правка и удаление чужих заметок |
| Обновление корневых сертификатов из-за отзыва eMudhra | Не уязвимость, а плановая замена | Корректная проверка HTTPS-соединений |
Разработчики также закрыли несколько мест, которые сами по себе атакой не являются, но облегчают ее: неэкранированные имена пользователей на экранах мультисайта, небезопасные замены в блоках Image и Playlist, возможность перекрыть данные Script Module элементом с тем же ID.
Чем опасна уязвимость в процессе обновления ядра
Самая серьезная находка в 7.1.4 — состояние гонки во время обновления ядра, которое может закончиться удаленным выполнением кода. Состояние гонки — это ошибка, при которой результат зависит от того, какая из двух одновременно идущих операций завершится первой; атакующий старается вклиниться в этот промежуток.
Технических подробностей разработчики не опубликовали, и это обычная практика: детали раскрывают позже, когда большинство сайтов уже обновится. Поэтому гадать, при каких условиях хостинга уязвимость срабатывает, мы не будем. Важно другое: уязвимость сидит в механизме обновления, а значит, сайты, которые обновляются редко и вручную, дольше остаются на уязвимой версии.
По словам разработчиков, исправление перенесено во все ветки, которые еще получают обновления безопасности. Это значит, что «у нас старая версия, нас не коснется» здесь не работает: старые ветки тоже затронуты, просто для них выпущены свои номера версий.
Каким сайтам обновляться в первую очередь
Первыми под удар попадают сайты, где в админку заходит больше одного человека. Почти все XSS из списка требуют роль «Участник» или выше. Участник по описанию ролей и возможностей WordPress может писать и редактировать свои записи, но не публиковать их. Обычно такую роль выдают внештатным копирайтерам, стажерам, сотрудникам маркетинга, приглашенным экспертам блога.
Риск выше, если у вас:
- корпоративный блог, куда пишут несколько авторов, в том числе подрядчики;
- учетные записи бывших сотрудников и агентств, которые никто не удалил;
- интернет-магазин на WooCommerce с личными кабинетами и расширенными ролями;
- мультисайт, где на одной установке живут сайты нескольких филиалов или брендов;
- тема или плагины, которые используют Interactivity API (через него сделаны интерактивные блоки в новых темах).
Отдельно стоит упомянуть утечку неопубликованных изменений Customizer. Она доступна посетителю без входа на сайт. Если вы готовите в настройщике новую главную, акцию или смену цен и держите это в черновике до даты запуска, на старой версии посторонний человек может увидеть изменения раньше времени. Для одностраничника с одним администратором риск ниже, но обновляться все равно нужно: автоматический сканер не проверяет, сколько у вас авторов.
Обновится ли сайт сам
Скорее всего да, если на сайте не отключены автоматические обновления. Начиная с WordPress 3.7 младшие обновления и обновления безопасности ставятся в фоне, об этом прямо сказано в инструкции по обновлению WordPress. В анонсе 7.1.4 разработчики тоже пишут, что на сайтах с автообновлениями процесс начнется сам.
Но есть условия, при которых фоновое обновление не срабатывает:
- WordPress не может писать в свои файлы и при обновлении просит данные FTP. Тогда фоновое обновление невозможно, нужен ручной запуск;
- в
wp-config.phpразработчик когда-то прописал запрет автообновлений ядра, например константойWP_AUTO_UPDATE_COREсо значениемfalse; - автообновления отключены плагином безопасности, плагином обслуживания или панелью хостинга;
- на сайте выключен или не срабатывает встроенный планировщик WP-Cron, через который WordPress запускает фоновые задачи, включая проверку обновлений.
На проектах B2BPRO.KZ мы чаще всего видим вторую и третью ситуацию. Разработчик несколько лет назад отключил автообновления, чтобы правки в теме не сломались, сайт сдали, а про запрет забыли. Владелец уверен, что WordPress обновляется сам, и не знает, что сайт три версии назад остановился. Поэтому полагаться на автообновление без проверки не стоит: зайдите и посмотрите номер версии.
Как проверить версию и обновить WordPress
Проверка занимает пару минут, обновление при нормальном хостинге еще столько же. Порядок такой:
- Войдите в админку и откройте «Консоль» → «Обновления». Вверху страницы написано, какая версия установлена и есть ли новая.
- Если там уже 7.1.4, фоновое обновление сработало. Перейдите к проверке после обновления (раздел ниже).
- Если версия старше, сначала сделайте резервную копию файлов и базы данных. Многие хостинги делают ее из панели управления за пару кликов, это быстрее, чем через плагин.
- Нажмите «Обновить сейчас». Если WordPress попросил данные FTP, введите их или передайте задачу тому, кто обслуживает сайт.
- Если у сайта есть доступ по SSH и установлен WP-CLI, обновление можно сделать командой
wp core update, она описана в документации WP-CLI по обновлению ядра. Это удобно, когда сайтов несколько. - После обновления очистите кэш плагина кэширования и, если есть, кэш CDN, иначе посетители какое-то время будут видеть старые страницы.
- Снова откройте «Консоль» → «Обновления» и убедитесь, что версия поменялась.
Если обновление прервалось и сайт показывает сообщение об обслуживании, в корне сайта остался файл .maintenance. Документация WordPress рекомендует удалить его через FTP и при необходимости обновиться вручную.
Что делать, если сайт на старой ветке WordPress
Обновиться до последней версии в своей ветке, а затем запланировать переход на 7.1. Разработчики выпустили исправления для старых веток вплоть до 4.7, но прямо пишут, что активно поддерживается только самая свежая версия. Какие номера искать, видно из таблицы:
| Ветка | Исправленная версия | Сколько из 22 уязвимостей затрагивает ветку |
|---|---|---|
| 7.1 | 7.1.4 | 22 |
| 7.0 | 7.0.8 | 22 |
| 6.9 | 6.9.11 | 22 |
| 6.8 | 6.8.12 | 20 |
| 6.7 | 6.7.11 | 20 |
| 6.6 | 6.6.11 | 19 |
| 6.5 и 6.4 | 6.5.14 и 6.4.14 | 17 |
| 6.0-6.3 | 6.0.18, 6.1.16, 6.2.15, 6.3.14 | 9 |
| 5.0-5.8 | своя версия для каждой ветки | 6 |
| 4.6 и старше | исправлений нет | — |
Данные взяты со страницы версии 7.1.4 в официальной документации. Сайт на ветке 4.6 и ниже обновлений безопасности уже не получает. Если у вас такой, вопрос больше не в патче: сайт нужно переносить на актуальную версию, проверяя тему и плагины, а иногда честнее пересобрать его заново.
Переход между крупными версиями (например, с 6.4 на 7.1) лучше делать на копии сайта. Старые плагины и самописные темы часто ломаются именно на таких скачках, а не на младших обновлениях. Для многошагового обновления у WordPress есть расширенная инструкция по обновлению.
Что проверить после обновления
После обновления проверьте сайт глазами клиента и глазами администратора. Младшие обновления редко что-то ломают, но 7.1.4 меняет файлы блоков, Customizer и Interactivity API, а значит, темы и плагины, которые лезут в эти места, стоит прокликать.
- Откройте главную, страницы услуг и пару статей блога. Посмотрите, на месте ли меню, слайдеры, вкладки и другие интерактивные элементы.
- Отправьте тестовую заявку через каждую форму на сайте и убедитесь, что она пришла на почту или в CRM. Если формы связаны с Битрикс24 или другой CRM, проверьте, что лид создался.
- Если это магазин, пройдите путь до оформления заказа и до выбора способа оплаты.
- Зайдите в «Пользователи» и посмотрите список учетных записей. Удалите тех, кто у вас больше не работает, и понизьте роли тем, кому не нужен доступ выше «Участника».
- Откройте «Инструменты» → «Здоровье сайта». Там видно, работают ли фоновые обновления и нет ли критических проблем с конфигурацией.
- Если на сайте есть плагин безопасности с журналом, посмотрите, не было ли за последние дни новых администраторов, неожиданных правок файлов или подозрительных входов.
Типичные ошибки владельцев сайтов
Первая ошибка — считать, что обновление ядра закрывает все. 7.1.4 исправляет ядро WordPress. Уязвимости в плагинах и темах обновляются отдельно, через тот же экран «Обновления», и их на сайте компании обычно больше, чем проблем в самом ядре.
Вторая ошибка — забывать про PHP. Неделей раньше, 21 октября, вышло критическое обновление самого PHP: в бюллетене php.net описаны две уязвимости удаленного выполнения кода, исправленные в версиях 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Команда WordPress выпустила об этом отдельное предупреждение. Обновление WordPress PHP не меняет: версию интерпретатора обновляет хостинг или администратор сервера. Подробнее мы писали в статье о критических уязвимостях PHP от 21 октября.
Третья ошибка — обновлять без резервной копии «потому что младшее обновление». В большинстве случаев все пройдет гладко, но если обновление прервется на середине, без копии восстановление займет часы.
Четвертая — держать «вечные» учетные записи. Подрядчик, который два года назад писал статьи в блог, до сих пор имеет роль «Автор». После такого выпуска, где большая часть уязвимостей требует именно рабочей учетной записи, это прямой риск.
Пятая — не знать, кто отвечает за сайт. В небольших компаниях в Казахстане часто бывает так: сайт делала одна студия, хостинг оплачивает бухгалтерия, а пароль от админки есть у маркетолога, который уже уволился. Когда выходит срочное обновление, выясняется, что сделать его некому. Если сайт приносит заявки, за ним должен кто-то следить: собственный специалист или подрядчик по техподдержке сайта на WordPress.
Если сайт давно не обновлялся, сделан на устаревшей теме или собран из десятков плагинов, иногда дешевле не латать его каждый месяц, а переделать на современной основе. Мы занимаемся этим постоянно: разработка сайтов под ключ на WordPress и 1С-Битрикс включает перенос контента, настройку обновлений и передачу понятных инструкций, кто и как обслуживает сайт дальше.
Кто в компании должен отвечать за обновления сайта
За обновления должен отвечать один конкретный человек или подрядчик, и это надо записать. Если ответственного нет, срочные выпуски вроде 7.1.4 ставятся с опозданием в недели, а иногда не ставятся вообще. Удобно разделить зону ответственности так:
| Что обновляется | Кто обычно отвечает | Как часто проверять |
|---|---|---|
| Ядро WordPress | Администратор сайта или подрядчик по поддержке | Раз в неделю и в день выхода выпуска безопасности |
| Плагины и тема | Тот же специалист, с проверкой на копии сайта для крупных обновлений | Раз в неделю |
| Версия PHP и сервер | Хостинг-провайдер или системный администратор | При каждом бюллетене безопасности PHP |
| Учетные записи и роли | Руководитель маркетинга или владелец сайта | Раз в квартал и при увольнении сотрудника |
| Резервные копии | Хостинг и администратор сайта | Проверять восстановление хотя бы раз в квартал |
Это пример распределения, а не обязательная схема: в небольшой компании все пять строк может вести один подрядчик. Главное, чтобы у каждой строки было имя. Отдельно договоритесь, как вам сообщают о выполненном обновлении: короткое письмо или сообщение в рабочем чате с номером новой версии экономит время на проверку.
Еще один полезный пункт регламента — хранить доступы к хостингу, домену и админке в одном месте у компании, а не только у подрядчика. Когда выходит срочный патч, а подрядчик в отпуске, вы сможете передать задачу другому специалисту в тот же день.
Как часто теперь ждать таких обновлений
Если судить по осени 2026 года, примерно раз в две-три недели. Ветка 7.1 вышла в августе, и с тех пор разработчики выпустили четыре версии с исправлениями безопасности. Следующий крупный релиз, WordPress 7.2, запланирован на 8 декабря, и вместе с 7.1.4 уже вышла 7.2 Beta 3 с этими же исправлениями.
Практический вывод для компании простой: проверку обновлений нужно поставить в регламент, а не ждать новостей. Достаточно раз в неделю заходить на экран «Обновления» или получать письма о фоновых обновлениях, которые WordPress отправляет на почту администратора. Если такие письма перестали приходить, это повод проверить, не отключены ли автообновления.
Частые вопросы
Нужно ли обновлять WordPress до 7.1.4, если у меня маленький сайт-визитка?
Да, нужно. Часть уязвимостей требует рабочей учетной записи, но утечка изменений Customizer доступна любому посетителю, а уязвимость в процессе обновления касается всех сайтов. Атаки на WordPress обычно ведут автоматические сканеры, им неважно, насколько сайт маленький. Обновление занимает несколько минут, если перед ним есть свежая резервная копия.
Как узнать, обновился ли WordPress автоматически?
Откройте в админке «Консоль» → «Обновления»: вверху страницы указана текущая версия. Если там 7.1.4, фоновое обновление прошло. Еще один признак — письмо о фоновом обновлении на почту администратора сайта. Если версия старая, а писем давно не было, вероятно, автообновления отключены в настройках, плагином или константой в wp-config.php.
Можно ли сломать сайт обновлением до 7.1.4?
Риск небольшой, потому что в этом выпуске только исправления безопасности без новых функций. Но 7.1.4 меняет код блоков, Customizer и Interactivity API, поэтому темы и плагины, которые используют эти части, стоит проверить. Перед ручным обновлением сделайте резервную копию, после обновления пройдите формы заявок и корзину.
Что делать, если мой сайт на WordPress 5 или 6 и обновиться до 7.1 страшно?
Обновитесь до последней версии своей ветки: для 6.8 это 6.8.12, для 6.4 это 6.4.14, для 6.0 это 6.0.18. Так вы закроете уязвимости, которые затрагивают вашу ветку. Переход на 7.1 запланируйте отдельно и проведите на копии сайта, потому что при скачке через несколько крупных версий чаще ломаются старые темы и плагины.
Обновление WordPress заменяет обновление PHP на хостинге?
Нет, это разные вещи. WordPress обновляет свои файлы, а версию PHP меняет хостинг-провайдер или администратор сервера. После критического выпуска PHP от 21 октября 2026 года безопасными считаются версии 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Текущую версию PHP можно увидеть в разделе «Инструменты» → «Здоровье сайта» → «Информация».