17 сентября 2026 года команда WordPress выпустила версию 7.1.1: это срочное обновление безопасности, которое закрывает 11 уязвимостей ядра и исправляет 36 ошибок. Разработчики рекомендуют обновить сайты немедленно. Если на вашем сайте работают автоматические фоновые обновления, патч уже мог установиться сам, но проверить это стоит сегодня.
Источник новости: официальный анонс WordPress 7.1.1 на wordpress.org. В тот же день вышли исправления для старых веток движка, например версия 6.8.9 со списком закрытых уязвимостей. Ниже объясняем, какие дыры закрыли, кому они угрожают и что сделать владельцу корпоративного сайта в Казахстане, чтобы не узнать о проблеме от клиентов или хостера.
Что вошло в WordPress 7.1.1
В релиз вошли 17 исправлений ядра, 19 исправлений блочного редактора и 11 исправлений безопасности. Версия 7.1 под названием «Mary Lou» вышла в августе 2026 года, так что 7.1.1 стала для неё первым сервисным выпуском. Следующий крупный релиз, 7.2, по плану разработчиков выйдет между 8 и 10 декабря 2026 года.
Минорный релиз WordPress: это выпуск с третьей цифрой в номере (7.1.1, 6.8.9), в котором нет новых функций, только исправления ошибок и уязвимостей. Такие выпуски почти никогда не ломают тему или плагины, поэтому откладывать их нет смысла. Совсем другая история у мажорных версий вроде 7.2: там меняется редактор, появляются новые API, и перед установкой разумно проверить сайт на копии.
Исправления безопасности из 7.1.1 разработчики перенесли и в старые ветки. Если сайт по какой-то причине работает, например, на 6.8, для него вышла 6.8.9 с тем же набором исправлений. Но активно поддерживается только последняя версия движка, так что старая ветка остаётся временным решением: следующую уязвимость для неё могут уже не закрыть.
Какие уязвимости закрыли и кому они опасны
Большинство из 11 уязвимостей требуют, чтобы у злоумышленника уже был аккаунт на сайте, но две из них может использовать посторонний человек. Для компании это значит простую вещь: опасность зависит от того, сколько людей имеет доступ в админку и открыты ли на сайте комментарии.
XSS (межсайтовый скриптинг): это атака, при которой в страницу сайта попадает чужой JavaScript-код и выполняется в браузере посетителя или администратора. Через такой код можно украсть сессию администратора, подменить ссылки или показать фишинговую форму.
Мы сгруппировали уязвимости по тому, кто может ими воспользоваться. Формулировки взяты из официального анонса, пересказ наш.
| Уязвимость | Кто может воспользоваться | Чем грозит |
|---|---|---|
Хранимый XSS через функцию форматирования абзацев wpautop() |
Неавторизованный посетитель, при условии что его комментарий одобрят | Вредоносный скрипт на странице с комментариями |
| Установка и предпросмотр неактивной темы с WordPress.org по специально подготовленной ссылке | Посторонний, который подсунет ссылку | На сайте появляется тема, которую никто не ставил |
| Хранимый XSS в изображениях шапки (custom header) в некоторых темах | Пользователь с доступом к настройке шапки | Скрипт в шапке на всех страницах |
| Выход текста за пределы HTML-комментария в HTML API | Зависит от кода, который использует этот API | Внедрение разметки в страницу |
| Перезапись произвольных записей | Участник (Contributor) и выше | Автор с минимальными правами меняет чужие материалы |
| Раскрытие slug черновиков и записей на утверждении | Участник и выше | Утечка адресов неопубликованных материалов |
| Раскрытие заголовка приватной родительской записи через медиафайл | Авторизованный пользователь | Утечка названия закрытой страницы |
| Обход каталога (path traversal) в контроллере шаблонов REST API | Авторизованный пользователь | Доступ к файлам за пределами разрешённой папки |
| Публикация changeset через XML-RPC в обход проверки права на правку CSS | Авторизованный пользователь | Изменение стилей сайта без нужных прав |
| Перепривязка комментариев, включая заметки | Любой авторизованный пользователь | Путаница в обсуждениях и внутренних заметках |
| Сетевая активация плагина, доступного только сети | Администратор отдельного сайта в мультисайте | Выход за пределы своих полномочий в сети сайтов |
Колонку «Чем грозит» мы заполнили по описаниям уязвимостей. Технических деталей эксплуатации команда WordPress не публикует, и это правильно: так у владельцев сайтов есть время обновиться до того, как появятся готовые инструменты для атак.
Обновился ли ваш сайт автоматически
Скорее всего, да, если настройки по умолчанию никто не трогал. Автоматические фоновые обновления появились в WordPress 3.7, и для существующих установок по умолчанию включены обновления минорных версий ядра и файлов перевода. Сайты, установленные с нуля начиная с версии 5.6, по умолчанию получают автоматически и минорные, и мажорные версии. Это описано в руководстве WordPress по обновлению.
На практике «скорее всего» означает, что проверять всё равно нужно. На проектах B2BPRO.KZ мы регулярно встречаем сайты, где автообновления когда-то отключили и забыли: разработчик боялся, что обновление сломает доработки, или хостинг-панель поставила свои правила. Такой сайт годами живёт на старой версии, и владелец об этом не знает.
Проверка занимает пять минут:
- Зайдите в админку и откройте раздел «Консоль» → «Обновления». Там указана текущая версия WordPress и есть ли доступное обновление.
- Если версия 7.1.1 (или 6.8.9 и аналогичная для старой ветки), ядро уже обновлено. Переходите к проверке плагинов и тем ниже.
- Если WordPress предлагает обновиться, значит, автообновление не сработало. Сделайте резервную копию и нажмите кнопку «Обновить сейчас».
- Попросите разработчика или хостера посмотреть файл
wp-config.php. Если там есть строкаdefine( 'AUTOMATIC_UPDATER_DISABLED', true );, все автоматические обновления на сайте выключены полностью. - Там же проверьте константу
WP_AUTO_UPDATE_CORE. Значениеfalseотключает автообновления ядра,'minor'оставляет только минорные,trueвключает все.
Разработчики WordPress прямо пишут, что отключать автообновления настоятельно не рекомендуется: это один из лучших способов держать сайт в актуальном и защищённом состоянии. Для корпоративного сайта разумный компромисс такой: минорные обновления ядра приходят автоматически, мажорные ставит специалист после проверки на копии.
Почему автообновление иногда не срабатывает
Самая частая причина: у WordPress нет прав на запись в свои файлы на сервере. В руководстве по обновлению об этом сказано прямо: обновление в один клик работает на большинстве серверов, а если что-то пошло не так, проблема, скорее всего, в правах доступа к файловой системе.
Кроме прав на файлы, есть ещё несколько типичных ситуаций, которые мы видим на аудитах:
- автообновления отключены константой в
wp-config.phpили отдельным плагином «для стабильности»; - сайт развёрнут из системы контроля версий, и WordPress видит это и ведёт себя осторожнее с автоматическими обновлениями;
- на сайте не работает планировщик WordPress (WP-Cron), потому что его отключили, а замену через системный cron на хостинге так и не настроили;
- сайт лежит на старой версии PHP, и новая версия движка на неё не встаёт.
Любая из этих причин лечится за час работы специалиста. Проблема в том, что её никто не ищет, пока сайт не взломали.
Что сделать владельцу сайта прямо сейчас
Нужно убедиться, что ядро обновлено до 7.1.1, и заодно закрыть сопутствующие риски, которые подсвечивает этот релиз. Порядок действий такой:
- Сделайте резервную копию базы данных и файлов. Руководство WordPress начинает любое обновление именно с этого шага и отдельно советует убедиться, что копия действительно восстанавливается. Подробно о настройке копирования мы писали в статье о резервном копировании WordPress.
- Обновите ядро через «Консоль» → «Обновления», если это не произошло автоматически.
- Проверьте список пользователей. Половина уязвимостей из списка требует аккаунта на сайте. Удалите старых сотрудников, подрядчиков, которые закончили работу, и тестовые учётные записи. Роль «Администратор» оставьте двум-трём людям, которые реально за сайт отвечают.
- Посмотрите комментарии. Если блог не принимает комментарии, закройте их в настройках обсуждения. Если принимает, оставьте ручную модерацию: одна из уязвимостей срабатывает только после одобрения комментария.
- Решите вопрос с XML-RPC. Если вы не публикуете записи из мобильного приложения или внешних сервисов, этот интерфейс, как правило, можно отключить. Решение принимает разработчик: некоторые плагины и интеграции его используют.
- Удалите неиспользуемые темы, особенно если на сайте вдруг появилась тема, которую никто не ставил. Это повод проверить журнал действий.
- Обновите плагины и тему. Ядро закрыто, но большинство взломов WordPress-сайтов идёт через дополнения.
После обновления откройте главную, несколько внутренних страниц, формы заявок и корзину, если она есть. Минорный релиз вряд ли что-то сломает, но проверка формы заявки занимает минуту, а потерянные лиды обходятся дороже.
Типичные ошибки при обновлении WordPress
Главная ошибка: откладывать обновление безопасности «до выходных» или «до следующего релиза». После публикации анонса список уязвимостей видят все, включая тех, кто пишет автоматические сканеры. Чем дольше сайт остаётся на старой версии, тем выше шанс, что его найдут.
Остальные ошибки встречаются так же часто:
- Обновление без резервной копии. Если на сайте есть доработки, написанные прямо в файлах ядра или родительской темы, обновление их перезапишет. Копия позволяет вернуть всё за минуты.
- Правки в файлах ядра. Это отдельная беда старых сайтов: разработчик когда-то поправил системный файл вместо того, чтобы написать плагин. После такого владелец боится любых обновлений, и сайт застревает на устаревшей версии.
- Обновление только ядра. Владелец видит «WordPress 7.1.1» и успокаивается, а плагин форм или слайдер двухлетней давности остаётся с известной дырой.
- Общий аккаунт администратора на всех. Один логин на маркетолога, подрядчика по SEO и бывшего разработчика не даёт понять, кто и что менял, и держит доступ открытым для людей, которые давно не работают с компанией.
- Никто не отвечает за сайт. Разработчик сдал проект и ушёл, штатного специалиста нет, хостер отвечает только за сервер. В итоге обновления никто не ставит, пока не случится инцидент.
Как понять, не успели ли сайт атаковать до обновления
Проверить это можно по нескольким явным признакам в админке и в Google Search Console, и начинать стоит с пользователей и тем. Если сайт долго жил без обновлений, такая проверка обязательна, даже когда внешне всё работает.
Что смотреть в первую очередь:
- список пользователей: нет ли незнакомых аккаунтов, особенно с ролью «Администратор» или «Редактор», и не повысил ли кто-то себе права;
- раздел «Внешний вид» → «Темы»: нет ли там темы, которую никто из вашей команды не устанавливал;
- последние изменения записей и страниц: не правил ли чужие материалы автор или участник, у которого на это не должно быть прав;
- исходный код главной страницы: нет ли в шапке или подвале незнакомых скриптов и ссылок на посторонние домены;
- отчёт «Проблемы безопасности» в Google Search Console: если Google нашёл на сайте вредоносный код или взлом, он сообщит об этом там.
Если хотя бы один пункт вызывает сомнения, не пытайтесь чистить сайт вслепую. Сначала сохраните копию в текущем состоянии, чтобы специалист мог разобраться, как именно проникли на сайт. Затем смените пароли всех администраторов, пароль к базе данных и доступы к хостингу. Удаление одного подозрительного файла без поиска причины обычно заканчивается повторным заражением через пару недель.
Чем это грозит бизнесу в Казахстане
Для компании взломанный сайт означает потерянные заявки, падение позиций в поиске и, всё чаще, вопросы по персональным данным. Через корпоративный сайт проходят имена, телефоны и адреса почты клиентов, часто они уходят в CRM. С 21 сентября 2026 года в Казахстане действуют обновлённые правила защиты персональных данных, и мы разбирали их отдельно в материале о новых правилах защиты персональных данных для компаний с CRM и сайтом. Своевременные обновления движка и контроль доступа к админке входят в ту самую базовую гигиену, о которой там идёт речь.
Отдельный риск связан с поиском. Если на сайт внедрят скрипт или скрытые ссылки, Google может пометить его как опасный, и в браузере посетители увидят предупреждение вместо вашей страницы. Восстановление доверия поисковика занимает недели, и всё это время реклама ведёт людей на страницу с предупреждением.
Для сайтов на WordPress ещё одна казахстанская особенность: многие компании держат сайт на недорогом виртуальном хостинге, где за обновления отвечает сам владелец. Хостер следит за сервером, но не за версией вашего движка и плагинов. Если в договоре с подрядчиком нет пункта о поддержке, обновления фактически не делает никто.
Как выстроить обновления, чтобы не зависеть от случайности
Надёжная схема держится на трёх вещах: автоматические минорные обновления, копия сайта для проверки крупных изменений и человек, который отвечает за сайт по договору. По нашему опыту внедрений, этого хватает, чтобы релизы вроде 7.1.1 проходили для владельца незаметно.
Выглядит это так. Минорные обновления ядра ставятся сами, как задумано в WordPress. Плагины обновляются по расписанию, например раз в неделю, после проверки на тестовой копии сайта. Мажорные версии движка ставятся через одну-две недели после выхода, когда авторы популярных плагинов успели выпустить совместимые версии. Резервные копии хранятся отдельно от основного хостинга. Раз в месяц кто-то смотрит список пользователей и журнал действий.
Для сайтов, где много доработок, мы рекомендуем вынести весь собственный код в дочернюю тему и отдельные плагины. Тогда обновление ядра и родительской темы ничего не перезаписывает, и страх перед обновлениями исчезает сам собой. Если сайт собран так, что без правки системных файлов работать не может, дешевле его пересобрать, чем годами держать на уязвимой версии. Такую задачу мы решаем в рамках услуги разработка сайтов под ключ: переносим доработки в правильную архитектуру, чтобы движок обновлялся без риска.
Если своего специалиста нет, поддержку сайта можно отдать на аутсорс. Что обычно входит в такой договор и как оценивать стоимость, мы описали в статье о техподдержке сайта на WordPress. Недавно WordPress.org начал и сам проверять обновления плагинов перед раздачей, об этом тоже есть отдельный материал о блокировке опасных обновлений плагинов. Обе меры работают только на сайте, который вообще получает обновления.
Частые вопросы
Как узнать, какая версия WordPress стоит на моём сайте?
Откройте админку и перейдите в «Консоль» → «Обновления»: там указана текущая версия и есть ли доступное обновление. Версию также видно в самом низу любой страницы админки. Если там 7.1.1, ядро закрыто от уязвимостей из сентябрьского релиза. Если сайт работает на старой ветке, ищите номер 6.8.9 или аналогичный выпуск для своей ветки от 17 сентября 2026 года.
Можно ли обновить WordPress, не сломав сайт?
Да, минорные обновления вроде 7.1.1 почти никогда не ломают сайт, потому что в них нет новых функций, только исправления. Риск появляется, если кто-то когда-то правил файлы ядра или родительской темы: обновление их перезапишет. Поэтому перед обновлением сделайте резервную копию базы и файлов, а после обновления проверьте формы заявок и ключевые страницы.
Нужно ли обновлять WordPress, если сайт маленький и на нём ничего не продаётся?
Да, нужно. Автоматические сканеры не выбирают сайты по размеру бизнеса, они перебирают все сайты с уязвимой версией подряд. Взломанную визитку используют для рассылки спама, скрытых ссылок или фишинговых страниц, после чего поисковики помечают домен как опасный. Восстанавливать репутацию домена дольше и дороже, чем поставить обновление, которое на большинстве сайтов устанавливается автоматически.
Что делать, если на сайте отключены автообновления WordPress?
Сначала обновите ядро вручную через «Консоль» → «Обновления», сделав перед этим резервную копию. Затем выясните, кто и зачем отключил автообновления: обычно это константа AUTOMATIC_UPDATER_DISABLED или WP_AUTO_UPDATE_CORE в файле wp-config.php, либо отдельный плагин. Для большинства корпоративных сайтов разумно вернуть автоматическую установку хотя бы минорных обновлений.
Сколько времени занимает обновление WordPress?
Само обновление ядра через админку обычно занимает несколько минут. Больше времени уходит на подготовку: резервную копию, проверку плагинов и контроль форм после обновления. На сайте без доработок в системных файлах всю процедуру специалист проходит примерно за час. Если автообновления работают, минорные версии устанавливаются вообще без участия человека.