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

WordPress 7.1.3 — это релиз безопасности, вышедший 6 октября 2026 года: он закрывает семь проблем, включая XSS в комментариях и SQL-инъекцию в экспорте WXR, и разработчики просят обновить сайты сразу. Для владельца сайта в Казахстане порядок простой: сделать резервную копию, открыть Консоль > Обновления, установить версию и проверить комментарии, экспорт и встраивания.

Обычно на такие релизы реагируют по-разному: одни обновляют в день выхода, другие откладывают на месяц, потому что «всё же работает». Вторая стратегия дорожает с каждым выпуском: у WordPress подряд вышли релизы безопасности 7.1.1, 7.1.2 и теперь 7.1.3, и каждый раз исправления касались реально существующих дыр. Ниже разобрано, что именно закрыли, кого это касается и как обновиться без сюрпризов. Первоисточник: страница релиза WordPress 7.1.3 на wordpress.org.

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

В релиз вошли исправления семи проблем безопасности, которые команде WordPress сообщили исследователи, и несколько обычных ошибок. На странице релиза безопасность описана списком благодарностей по каждой находке, и именно его мы пересказываем простым языком.

Проблема	Простыми словами
Сохранённый XSS на странице комментариев	Вредоносный код в комментарии, ожидающем модерации, может сработать в админке
Отказ в обслуживании в методе WP_Http::make_absolute_url()	Специально составленный адрес может перегрузить обработку запроса
SQL-инъекция второго порядка в экспорте WXR	Опасное значение, попавшее в базу, срабатывает позже, при выгрузке контента
Слабость, позволяющая автору закреплять записи	Пользователь с ролью «Автор» получает возможность, которой у него быть не должно
Раскрытие комментариев к закрытым и неопубликованным записям	Неавторизованный посетитель может увидеть чужие комментарии
XSS во встраиваниях Imgur	Код через встроенную картинку может выполниться на странице
Коллизия имён действий в хуке {status}_{type}	Подделываемые параметры позволяют вызвать не то действие

Для справки, XSS (межсайтовый скриптинг) — это уязвимость, при которой чужой JavaScript выполняется в браузере посетителя или администратора от имени вашего сайта. Опасность в том, что код срабатывает там, где у человека есть права.

SQL-инъекция второго порядка — это атака, когда опасное значение сначала спокойно сохраняется в базе, а срабатывает позже, когда другая часть сайта использует его в запросе. Поэтому такие дыры не видно на входе, и поэтому их закрывают на стороне самого движка.

В обзоре сервиса witscode отмечено, что для эксплуатации SQL-инъекции в экспорте нужно, чтобы некорректное значение уже находилось в базе, а сама выгрузка выполнялась администратором. Это снижает риск, но не отменяет необходимость обновиться: на сайте могут быть плагины и пользователи, которые это значение туда положат.

Насколько срочно нужно обновлять сайт?

Срочно: сама команда WordPress пишет, что раз это релиз безопасности, сайты рекомендуется обновить немедленно. Подтверждённой массовой эксплуатации в просмотренных нами источниках на момент написания нет, но сроки здесь определяет то, что после публикации исправления любой желающий может сравнить версии и понять, где была дыра.

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

Каким сайтам риск выше?

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

• сайты с открытыми комментариями, где модератор регулярно заходит в раздел комментариев;
• блоги и порталы с несколькими авторами, редакторами и внешними авторами-гостями;
• сайты с закрытыми записями или черновиками, к которым есть комментарии;
• сайты, где используется экспорт WXR, например при переносе контента между площадками;
• страницы со встроенными материалами с Imgur.

У одностраничного сайта-визитки без комментариев и с одним администратором поверхность атаки заметно меньше. Но движок на нём тот же, а часть исправлений, например в обработке адресов, касается любого WordPress.

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

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

1. Сделайте полную резервную копию. Файлы и база данных вместе. Проверьте, что копию можно скачать и что она открывается, а не просто лежит где-то на хостинге.
2. Посмотрите версию. В разделе «Консоль > Обновления» видно, какая версия установлена и какая доступна. Если у вас старая ветка, WordPress предложит исправление именно для неё.
3. Проверьте плагины и тему. Если плагин давно не обновлялся, лучше сначала проверить его на копии сайта.
4. Запустите обновление в часы наименьшей нагрузки. Для интернет-магазина это ночь или раннее утро.
5. Проверьте сайт после обновления. Откройте главную, форму заявки, корзину, раздел комментариев и админку.
6. Очистите кэш. Если на сайте стоит плагин кэширования, сбросьте его через собственные настройки плагина, чтобы посетители не получали старую версию страниц.

Если сайт работает на нестандартном хостинге, где автоматическое обновление отключено, обновление ставят вручную из архива с wordpress.org или через панель хостинга. Адрес со всеми версиями дан в справке: архив релизов WordPress.

Что делать, если сайт на старой версии WordPress?

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

Из нашей практики типичная причина отставания — страх сломать тему или плагин, написанные много лет назад. Решение в таких случаях одно: поднять копию сайта, обновить там, найти несовместимое и исправить, а потом переносить на рабочий сайт. Это дешевле, чем разбирать последствия взлома, а для компании в Казахстане ещё и меньше рисков остановить продажи.

Что проверить после обновления?

Обновление движка не исправляет то, что уже успело попасть на сайт. Если вы долго не обновлялись, проверьте несколько вещей:

• список комментариев на модерации: нет ли странных ссылок и кода в тексте;
• список пользователей: нет ли лишних авторов и редакторов, которых вы не создавали;
• роли сотрудников: у внешних авторов должны быть только нужные права;
• недавно изменённые файлы на хостинге, если хостинг показывает такой список;
• встраивания Imgur и других сервисов в старых записях: оставьте только нужные;
• журнал входов и письма безопасности, если на сайте стоит плагин защиты.

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

Почему роли пользователей важны для безопасности

В WordPress есть встроенные роли: администратор, редактор, автор, участник и подписчик, и чем выше роль, тем больше возможностей. Часть исправлений 7.1.3 касается ситуаций, когда пользователь с ограниченной ролью получает больше возможностей, чем задумано, поэтому набор ролей на сайте напрямую влияет на риск.

Администратор управляет всем: плагинами, пользователями, настройками. Редактор работает с чужими материалами и комментариями. Автор публикует собственные записи. Участник пишет черновики, но не публикует их сам. Подписчик только читает и, например, комментирует. Если на сайте десять человек и все они администраторы «чтобы не возиться с правами», вы вручную сделали из каждой уязвимости худший сценарий.

Проверьте раздел «Пользователи» в админке и ответьте на три вопроса. Кто из этих людей ещё работает в компании? Какая роль нужна каждому на самом деле? Есть ли учётные записи подрядчиков, которым доступ уже не нужен? Лишние аккаунты лучше удалить или понизить до подписчика, а пароли администраторов сменить, если вы давно этого не делали.

Регламент обновлений: кто, что и как часто

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

Что делаем	Как часто	Кто отвечает
Проверка обновлений ядра, плагинов и темы	Раз в неделю	Ответственный за сайт или подрядчик
Срочное обновление при релизе безопасности	В день релиза или в течение трёх рабочих дней	Ответственный за сайт
Резервная копия файлов и базы	Перед каждым обновлением и по расписанию	Хостинг или подрядчик
Пробное восстановление из копии	Раз в квартал	Подрядчик
Ревизия пользователей и ролей	Раз в квартал и при уходе сотрудника	Руководитель или администратор
Удаление неиспользуемых плагинов и тем	Раз в полгода	Подрядчик

Отдельно закрепите в регламенте, что делать при релизе безопасности вне расписания: кто принимает решение, кто делает копию, кто проверяет сайт после обновления и кому сообщать о результате. Для небольшой компании это две-три строки, но именно они превращают намерение «надо бы обновиться» в действие с исполнителем и сроком. Если на сайте несколько ролей, добавьте в регламент и правило выдачи прав: новый автор получает минимальную роль, а повышение согласуется.

Это пример, а не требование: частота зависит от размера сайта и того, сколько денег он приносит. Для магазина с ежедневными заказами проверка раз в неделю может оказаться слишком редкой, для сайта-визитки раз в квартал нормально. Важно, чтобы у каждой строки был живой исполнитель, а не «отдел».

Что делать, если сайт сломался после обновления

Если после обновления открывается белый экран или сообщение об ошибке, сохраняйте спокойствие: чаще всего виноват конфликт плагина или темы с новой версией, а не сам движок. Порядок действий такой:

1. Не запускайте обновление повторно. Повторные попытки на сломанном сайте усложняют диагностику.
2. Проверьте письмо от WordPress. Если включён режим восстановления, на почту администратора приходит ссылка для входа в безопасном режиме и название плагина, который вызвал ошибку.
3. Отключите подозрительный плагин. Из админки или, если она недоступна, переименуйте его папку в каталоге плагинов через файловый менеджер хостинга.
4. Верните тему по умолчанию, если проблема в теме: так вы поймёте, что именно ломается.
5. Восстановите сайт из резервной копии, если простых шагов не хватило. Именно поэтому копия делается до обновления.
6. Зафиксируйте причину и сообщите подрядчику, чтобы конфликтующий плагин заменили или доработали.

Если сайт принимает заявки или платежи, на время ремонта поставьте заглушку или переключите приём заявок на запасной канал. Минута простоя без предупреждения обходится дороже, чем честное сообщение клиенту.

Пример из практики: как выглядит спокойное обновление

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

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

Как не пропустить следующий релиз безопасности?

Самый надёжный способ — не полагаться на память, а подписаться на источник и назначить получателя. О новой версии сообщает сама админка WordPress: в разделе «Консоль > Обновления» и в уведомлении вверху экрана. Но этим уведомлением должен кто-то заниматься, а админку открывают далеко не каждый день.

Поэтому мы советуем два дублирующих канала. Первый: письмо о доступном обновлении на рабочий адрес ответственного, а не на давно забытый почтовый ящик первого подрядчика. Второй: еженедельная проверка раздела обновлений по календарю, чтобы релиз, пропущенный из-за отпуска, не лежал месяц. Если сайтов у вас несколько, удобнее вести единый список с версиями и датами последней проверки.

Отдельно стоит договориться с хостингом: понять, делает ли он копии сам, как долго их хранит и как быстро можно получить восстановление. В нашей практике на этом вопросе спотыкаются чаще, чем на самом обновлении, потому что копия «есть», но никто не знает, как её достать в понедельник утром.

Типичные ошибки при обновлении

Вот что мы чаще всего встречаем у компаний, которые обращаются к нам после проблем.

Обновление без копии. Если обновление пошло не так, вернуться некуда. Хостинг иногда делает свои копии, но восстановление из них занимает часы, а то и сутки.

Обновление в рабочее время для магазина. Сайт на несколько минут недоступен, а в это время идут заказы. Для магазина лучше выбирать окно с минимальной активностью.

Отключённые автообновления. Их выключают после неудачного опыта и забывают включить обратно. В итоге сайт месяцами живёт без исправлений безопасности. Если вы отключили автообновления, поставьте себе регулярную задачу на ручную проверку.

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

Старые плагины. Движок обновлён, а плагин пятилетней давности остаётся дырой. Проверяйте не только ядро.

Как к этому относиться компании в Казахстане?

Для компании в Казахстане обновление WordPress — это в первую очередь вопрос ответственности: кто именно на стороне бизнеса знает, что сайт нужно обновлять, и кто это делает. На практике сайт часто делал один подрядчик, хостинг оплачивает бухгалтерия, а админку открывает маркетолог. Релиз безопасности выходит, а у задачи нет хозяина.

Мы советуем закрепить три вещи: ответственного за сайт, регламент обновлений (например, проверка раз в неделю и срочное обновление при релизе безопасности) и резервные копии, которые кто-то периодически проверяет. По нашему опыту сопровождения сайтов, этих трёх пунктов достаточно, чтобы большинство инцидентов не случалось вообще.

B2BPRO.KZ разрабатывает и сопровождает сайты на WordPress для компаний Казахстана. Если вам нужно привести в порядок сайт, проверить роли, плагины и копии или вести обновления на постоянной основе, посмотрите нашу страницу разработка сайтов под ключ. Про предыдущие релизы мы писали отдельно: WordPress 7.1.1 и 11 закрытых уязвимостей и WordPress 7.1.2 и критическая уязвимость.

Частые вопросы

Нужно ли обновляться до WordPress 7.1.3, если сайт простой?

Да, нужно: даже у простого сайта то же ядро, а релиз безопасности исправляет и общие проблемы, например в обработке адресов. Разработчики WordPress рекомендуют обновить сайты сразу. Если у вас визитка без комментариев и с одним администратором, риск ниже, но откладывать обновление всё равно не стоит.

Как проверить, какая версия WordPress стоит на сайте?

Откройте админку и перейдите в Консоль > Обновления: там указаны установленная версия и доступная новая. Версию также видно внизу страниц админки. Если вы не можете войти в админку, обратитесь к тому, кто сопровождает сайт, или к хостинг-провайдеру, чтобы проверить версию на сервере.

Можно ли обновить WordPress без резервной копии?

Технически можно, но делать этого не стоит. Если обновление остановится на середине или конфликтует с плагином, без копии вы не вернёте прежнее состояние. Перед обновлением сохраните файлы и базу данных вместе и убедитесь, что копию можно скачать и открыть.

Что делать, если сайт на старой версии и не обновляется?

Сначала создайте копию сайта на тестовой площадке и обновите её там. Так видно, какие тема или плагины ломаются, и их можно заменить или доработать. Разработчики WordPress напоминают, что активно поддерживается только последняя версия, поэтому откладывать переход на неё не стоит.

Кто в компании должен отвечать за обновление сайта?

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