22 сентября 2026 года вышел WordPress 7.1.2. Он закрывает одну критическую уязвимость, через которую при определённых условиях можно выполнить чужой код на сервере без входа в админку. Уязвимы все версии с 4.7 по 7.1.1. Проверьте, какая версия стоит на вашем сайте: если ниже 7.1.2 или ниже исправленной версии своей ветки, обновитесь сегодня.
Об исправлении WordPress сообщил в официальном анонсе выпуска WordPress 7.1.2, технические детали опубликованы в бюллетене безопасности GHSA-7hp8-65ch-5whp на GitHub. Выпуск вышел всего через пять дней после 7.1.1, который закрыл 11 уязвимостей (мы разбирали его отдельно). Два выпуска безопасности за одну неделю встречаются нечасто, и второй серьёзнее первого: у уязвимости уровень «критический», а оценка по шкале CVSS 9,2 из 10.
Что именно исправили в WordPress 7.1.2
В WordPress 7.1.2 исправлена одна уязвимость в том, как движок выбирает шаблон для страницы. Злоумышленнику не нужен логин и пароль: по описанию разработчиков, неавторизованный посетитель может заставить функцию get_page_template() подключить выбранный им PHP-файл, который лежит на сервере за пределами папки активной темы.
Обход каталога (path traversal): это уязвимость, при которой программа открывает файл не из той папки, куда ей положено смотреть, потому что путь к файлу подсовывает атакующий. Удалённое выполнение кода (RCE, remote code execution): это ситуация, когда посторонний человек запускает на вашем сервере свои команды через интернет. На практике RCE означает полный контроль над сайтом: можно подменить страницы, добавить скрытые ссылки, украсть базу заявок или разослать с сервера спам.
Основные данные из бюллетеня:
| Параметр | Значение |
|---|---|
| Идентификаторы | CVE-2026-87902, GHSA-7hp8-65ch-5whp |
| Уровень | критический, CVSS v4: 9,2 |
| Нужна ли авторизация | нет |
| Уязвимые версии | с 4.7.0 по 7.1.1 |
| Дата исправления | 22 сентября 2026 года |
| Кто нашёл | исследователь Robert Ressl |
Уязвимость существует с версии 4.7, а эта версия вышла в 2016 году. Значит, под неё попадают почти все сайты на WordPress, которые сейчас работают, включая давно заброшенные корпоративные сайты, которые никто не обновлял.
Какие сайты действительно под угрозой
Код злоумышленника выполнится не на каждом сайте, а только там, где совпали два условия. Разработчики перечисляют их в бюллетене прямо.
- В активной теме есть папка верхнего уровня, название которой начинается с
page-, напримерpage-templates. Такие папки есть в старых стандартных темах Twenty Twelve и Twenty Fourteen и в популярных сторонних темах, среди которых в бюллетене названы Neve, Hestia и Sydney. - На сервере есть читаемый PHP-файл, который можно использовать для атаки. В бюллетене в пример приводится
pearcmd.phpпри включённой настройке PHPregister_argc_argv. По данным бюллетеня, такая конфигурация включена по умолчанию в официальных Docker-образах PHP и в старых конфигурациях cPanel.
Если одного из условий нет, по описанию разработчиков полноценного выполнения кода не получится. Но полагаться на это мы бы не стали. Владелец сайта обычно не знает, как настроен PHP у хостинга и какие файлы лежат на сервере. Кроме того, подключение чужого файла само по себе остаётся дырой, даже если конкретный сценарий атаки пока не сработал. И наконец, после публикации бюллетеня такие уязвимости начинают массово проверять автоматическими сканерами, которые обходят все сайты подряд.
Про настройку register_argc_argv стоит знать ещё одно. В документации PHP по основным настройкам указано, что её значение по умолчанию «1», то есть она включена, а начиная с PHP 8.5 эта возможность объявлена устаревшей и документация советует выставлять register_argc_argv=0. Сайту на WordPress эта настройка обычно не нужна.
Как проверить, обновился ли ваш сайт
Быстрее всего проверить версию в админке: номер указан в разделе «Консоль» → «Обновления» и в правом нижнем углу любой страницы админки. Если там 7.1.2 или исправленная версия вашей ветки, сайт защищён от этой уязвимости.
WordPress выпустил исправления не только для последней версии, но и для всех старых веток, начиная с 4.7. Если сайт работает на старой ветке, ориентируйтесь на таблицу:
| Ваша ветка | Уязвимые версии | Исправленная версия |
|---|---|---|
| 7.1 | 7.1.0 по 7.1.1 | 7.1.2 |
| 7.0 | 7.0.0 по 7.0.5 | 7.0.6 |
| 6.9 | 6.9.0 по 6.9.8 | 6.9.9 |
| 6.8 | 6.8.0 по 6.8.9 | 6.8.10 |
| 6.7 | до 6.7.8 | 6.7.9 |
| 6.6 | до 6.6.8 | 6.6.9 |
| 6.5 | до 6.5.11 | 6.5.12 |
| 4.7 | 4.7.0 по 4.7.36 | 4.7.37 |
Полный список исправленных версий для всех веток есть в бюллетене на GitHub. Сидеть на старой ветке всё равно не стоит: исправление закрывает эту конкретную дыру, но старые версии движка часто несовместимы со свежими версиями плагинов, а плагины уязвимы чаще, чем ядро.
Почему сайт мог не обновиться сам
Автоматические фоновые обновления появились в WordPress 3.7, и по умолчанию они включены на большинстве сайтов. Так написано в руководстве WordPress по обновлению. В анонсе 7.1.2 сказано, что на сайтах с включёнными фоновыми обновлениями исправление установится автоматически. Проблема в словах «с включёнными». На проектах B2BPRO.KZ мы регулярно видим сайты, где автообновления отключены. Причины обычно такие:
- в
wp-config.phpпрописана константаAUTOMATIC_UPDATER_DISABLED, которая отключает все автоматические обновления, илиWP_AUTO_UPDATE_COREсо значениемfalse; - обновления отключил плагин безопасности или оптимизации, потому что прошлый подрядчик боялся, что обновление что-то сломает;
- тема или плагин были доработаны прямо в файлах, и разработчик запретил обновления, чтобы их не затёрло;
- у хостинга не хватает прав на запись в папки сайта, и WordPress не может заменить файлы.
Если версия в админке старая, значит, одна из этих причин есть и у вас. Её стоит найти, а не просто нажать «Обновить» один раз: следующий выпуск безопасности тоже не установится сам.
Что сделать владельцу сайта прямо сейчас
Главное действие одно: обновить WordPress до 7.1.2 или до исправленной версии своей ветки. Остальные шаги нужны, чтобы обновление ничего не сломало и чтобы понять, не успели ли сайт взломать. Порядок такой:
- Сделайте резервную копию файлов и базы данных. Руководство WordPress прямо советует делать её перед обновлением, чтобы при проблеме можно было откатиться. Если копий нет, начните с этого (об этом у нас есть отдельная инструкция по резервному копированию).
- Обновите ядро через «Консоль» → «Обновления». Для минорного выпуска вроде 7.1.1 → 7.1.2 это обычно занимает минуту и не затрагивает тему и плагины.
- Проверьте после обновления главную, формы заявок, корзину и оплату, если они есть. Отправьте тестовую заявку и убедитесь, что она дошла в почту или CRM.
- Посмотрите, есть ли в папке активной темы (
wp-content/themes/название-темы/) папка, имя которой начинается сpage-. Это можно сделать через файловый менеджер хостинга или FTP. Если есть, ваш сайт подходил под первое условие атаки, и шаги 5 и 6 для вас обязательны. - Спросите хостинг, включена ли у вас настройка
register_argc_argvи установлен ли PEAR. Если сайту они не нужны, попросите отключить. После обновления WordPress это уже не обязательно, но лишние возможности на сервере лучше убирать. - Проверьте признаки взлома за последние дни: незнакомые администраторы в разделе «Пользователи», новые PHP-файлы в папках
uploadsи темы, скачок числа страниц в индексе Google, жалобы клиентов на переадресацию на чужие сайты. - Включите автоматические обновления ядра хотя бы для минорных выпусков, если они были отключены.
Если сайт сделан на заказ и обновлять его страшно, это отдельный сигнал. Нормальный сайт на WordPress переносит минорное обновление ядра без последствий. Если он ломается, значит, при разработке правили ядро или сторонние файлы вместо дочерней темы, и эту проблему лучше исправить сейчас, а не в день следующей уязвимости.
Как обновить WordPress, если кнопка обновления не работает
Если кнопка «Обновить» в админке не срабатывает или её нет, WordPress можно обновить вручную или через командную строку. Способ выбирайте по тому, какие доступы у вас есть.
Первый вариант: WP-CLI. Это инструмент командной строки для управления WordPress, который установлен у многих хостингов. Если у вас есть доступ к серверу по SSH, обновление делается одной командой wp core update из папки сайта. После неё стоит выполнить wp core version и убедиться, что версия сменилась.
Второй вариант: ручное обновление через файловый менеджер или FTP. Порядок описан в руководстве WordPress по обновлению, суть такая:
- сделать резервную копию файлов и базы данных;
- скачать свежий архив WordPress с wordpress.org и распаковать его на компьютере;
- на сервере заменить папки
wp-adminиwp-includesновыми; - загрузить файлы из корня архива поверх старых, при этом не трогать папку
wp-contentи файлwp-config.php: в них ваши темы, плагины, загрузки и настройки подключения к базе; - зайти в админку: если WordPress попросит обновить базу данных, согласиться.
Третий вариант: попросить хостинг. У многих хостингов в панели управления есть установщик приложений, который умеет обновлять WordPress, а поддержка хостинга обычно делает такое обновление по заявке. Для сайта-визитки без доработок это самый простой путь.
После любого способа обновления снова загляните в «Консоль» → «Обновления» и проверьте номер версии. Затем выясните, почему не сработало автообновление: иначе следующий выпуск безопасности придётся ставить так же вручную.
Что делать, если сайт уже успели взломать
Если вы нашли признаки взлома, одного обновления недостаточно: оно закрывает дверь, но не убирает то, что злоумышленник уже оставил внутри. Вредоносный файл в папке загрузок или лишний администратор переживут любое обновление ядра. Порядок действий мы обычно выстраиваем так:
- Сохранить копию сайта в текущем состоянии. Она понадобится, чтобы понять, что именно изменили и когда.
- Сменить пароли всех администраторов, пароль к хостингу, FTP и базе данных, а также секретные ключи в
wp-config.php. После смены ключей все, кто вошёл в админку, будут разлогинены, в том числе злоумышленник. - Удалить незнакомых пользователей с правами администратора.
- Если есть чистая резервная копия, сделанная до взлома, восстановить сайт из неё и сразу обновить ядро, тему и плагины. Если чистой копии нет, сравнить файлы ядра с оригинальным архивом и вручную искать посторонние PHP-файлы в
wp-content. - Проверить сайт в Google Search Console: раздел о проблемах безопасности покажет, пометил ли Google сайт как опасный. После очистки там же отправляется запрос на повторную проверку.
Чистка взломанного сайта требует аккуратности: пропущенный файл-бэкдор вернёт злоумышленника через неделю. Если своего разработчика нет, лучше отдать эту работу специалистам, чем чистить наугад.
Чем эта уязвимость опасна для бизнеса в Казахстане
Для компании взломанный сайт означает прежде всего потерянные заявки и испорченную репутацию в поиске. Технический ущерб обычно вторичен. Когда злоумышленник получает возможность выполнять код, сайт используют как ресурс: размещают страницы казино и займов, вставляют скрытые ссылки, перенаправляют посетителей с мобильных телефонов на мошеннические страницы. Владелец сайта этого часто не видит, потому что сам заходит с компьютера и сразу в админку.
Последствия проявляются с задержкой. Google помечает сайт как опасный, браузер показывает посетителям предупреждение, трафик из поиска падает, а Google Ads может приостановить рекламу, которая ведёт на взломанный сайт. На очистку и восстановление позиций уходят недели. Для небольшой компании, которая получает заявки в основном с сайта, это прямые потери выручки.
Есть и вопрос данных. Если в базе сайта хранятся заявки клиентов с телефонами и адресами, доступ к серверу означает доступ к этим данным. Для компании это уже не только технический, но и юридический риск, потому что персональные данные клиентов в Казахстане защищены законом.
По нашему опыту, чаще всего под удар попадают не крупные интернет-магазины, у которых есть свой разработчик, а сайты-визитки и корпоративные сайты, сделанные несколько лет назад. Подрядчик сдал проект и ушёл, доступы к хостингу есть только у бухгалтера, и никто не следит за обновлениями. Именно такие сайты автоматические сканеры находят первыми.
Типичная картина выглядит так (пример собирательный). Строительная компания в Алматы заказала сайт в 2019 году на популярной бесплатной теме. Сайт приносит пять-семь заявок в неделю, и никто его не трогает. Однажды менеджер замечает, что заявок нет уже десять дней. Форма при этом работает, но в поиске под названием компании появляются страницы на английском про онлайн-казино, а посетители с телефонов попадают на чужой сайт. Разбор показывает, что версия WordPress отстала на несколько лет, а автообновления когда-то отключил прежний подрядчик. Восстановление занимает две недели и стоит в разы дороже, чем стоило бы годовое обслуживание сайта.
В таких историях почти никогда не бывает одной причины. Устаревшее ядро соседствует с заброшенными плагинами, пароль администратора годами не менялся, а резервные копии лежат на том же хостинге, что и сам сайт. Поэтому после обновления до 7.1.2 полезно пройтись и по плагинам: у каждого в списке «Плагины» указано, есть ли для него обновление, и плагины, которые давно не обновлялись самим разработчиком, лучше заменить.
Как не оказаться в той же ситуации при следующем выпуске
Надёжнее всего защищает не реакция на новости, а постоянный порядок обслуживания: автообновления ядра, еженедельная проверка плагинов и резервные копии, которые хранятся отдельно от хостинга. В 2026 году WordPress выпускает исправления безопасности регулярно, и два выпуска за неделю в сентябре хорошо это показывают.
Минимальный набор, который мы советуем клиентам:
- автоматические обновления ядра включены хотя бы для минорных выпусков;
- тема и плагины обновляются раз в неделю или раз в две недели, после резервной копии;
- неиспользуемые плагины и темы удалены с сервера, а не просто выключены;
- правки внешнего вида сделаны в дочерней теме, поэтому обновление темы их не затирает;
- доступы к хостингу, домену и админке оформлены на компанию и хранятся у ответственного сотрудника;
- есть человек или подрядчик, который читает анонсы безопасности и отвечает за обновления.
Если сайт старый, собран на устаревшей теме или его страшно обновлять, иногда дешевле пересобрать его на актуальной версии, чем латать бесконечно. Мы делаем и то, и другое: можно заказать разовое обновление и проверку сайта на взлом, а можно заказать разработку сайта на свежем WordPress с поддержкой и регулярными обновлениями.
Уязвимость в 7.1.2 закрыта быстро, и для сайтов с работающими автообновлениями история уже закончилась. Для остальных она только начинается: бюллетень опубликован, описание атаки доступно всем, и сайты, которые остались на старой версии, будут проверять автоматически. Проверка версии занимает десять минут, восстановление после взлома растягивается на недели.
Частые вопросы
Какая версия WordPress сейчас безопасна?
Безопасна версия 7.1.2, выпущенная 22 сентября 2026 года, или исправленная версия вашей ветки: например, 7.0.6, 6.9.9 или 6.8.10. Уязвимость затрагивает все версии с 4.7.0 по 7.1.1. Точный номер версии сайта указан в админке в разделе «Консоль» → «Обновления».
Обновится ли WordPress до 7.1.2 сам?
Да, если на сайте включены автоматические фоновые обновления: так сказано в анонсе WordPress. Но на многих сайтах они отключены через wp-config.php, плагином или из-за прав доступа на хостинге. Поэтому лучше зайти в админку и проверить версию своими глазами, а не надеяться на автообновление.
Может ли обновление WordPress сломать сайт?
Минорное обновление вроде 7.1.1 → 7.1.2 обычно проходит без последствий, потому что закрывает ошибки и не меняет возможности движка. Сайт может сломаться, если при разработке правили файлы ядра или стороннюю тему без дочерней. Перед обновлением сделайте резервную копию файлов и базы, после обновления проверьте формы заявок.
Как понять, что мой сайт на WordPress уже взломали?
Проверьте список администраторов в разделе «Пользователи», новые PHP-файлы в папке uploads, число страниц в индексе Google и отчёт о проблемах безопасности в Search Console. Тревожные признаки: незнакомые пользователи, чужие страницы в поиске, переадресация посетителей с телефонов на посторонние сайты. При таких признаках одного обновления мало, нужна чистка сайта.
Нужно ли обновляться, если в моей теме нет папки page-?
Да, обновляться нужно всё равно. Папка page- в теме и файл pearcmd.php на сервере нужны для полного сценария атаки с выполнением кода, но уязвимость в ядре есть на всех версиях с 4.7 по 7.1.1. Тему могут сменить, конфигурацию хостинга тоже, а обновление ядра до исправленной версии закрывает проблему целиком.