WordPress 7.1.4: уязвимость уже атакуют. Как за минуту проверить, обновился ли ваш сайт — вопрос, который после 3 ноября 2026 года стоит задать каждому владельцу сайта на WordPress. 28 октября вышло срочное обновление безопасности 7.1.4, которое закрывает 22 уязвимости. Самая опасная из них позволяет выполнить чужой код на сервере в момент обновления сайта, а 3 ноября американское агентство кибербезопасности CISA внесло ее в каталог уязвимостей, которые уже используют в атаках.
Большинство сайтов получили 7.1.4 автоматически — WordPress сам ставит такие обновления в фоне. Но «большинство» не значит «ваш». Автообновления могут быть отключены, не сработать из-за настроек хостинга или прав на файлы, а старые копии сайта на поддоменах часто вообще никто не обновляет. Поэтому версию лучше проверить самостоятельно, а не предполагать, что все в порядке.
Ниже разберем, что именно исправили в 7.1.4, почему об этой уязвимости заговорили снова, как за минуту узнать версию своего сайта, почему WordPress иногда не обновляется сам и что сделать после обновления.
Читайте также интересную статью на тему: что делать владельцу сайта, когда находят критическую дыру в PHP.
Нужна консультация по созданию или продвижению сайта?
Ответим на вопросы и подскажем, с чего начать — бесплатно.
Что произошло: WordPress 7.1.4 и 22 закрытые уязвимости
28 октября 2026 года команда WordPress выпустила версию 7.1.4. Это не релиз с новыми функциями, а чистое обновление безопасности: в нем нет изменений в интерфейсе или редакторе, зато закрыто 22 уязвимости (такой подсчет приводят исследователи Patchstack и профильные издания; в официальном анонсе часть проблем объединена в общие пункты). Официальная рекомендация разработчиков WordPress короткая: обновить сайты немедленно.
Исправления касаются не только последней версии. Их перенесли во все старшие ветки, которые еще получают обновления безопасности, — вплоть до 4.7. То есть сайт на 6.9 или 7.0 не обязан переходить на 7.1, но должен получить свою исправленную версию. А вот сайты на WordPress 4.6 и старше никаких исправлений не получили вовсе.
Что именно исправили
- Уязвимость в процессе обновления, которая при определенных условиях позволяет выполнить чужой код на сервере (remote code execution, RCE). Именно она самая опасная.
- Больше десятка сценариев хранимого XSS — когда в контент сайта можно встроить вредоносный скрипт, который потом выполняется в браузере администратора или посетителя. Речь шла о разметке блоков, блоках изображений и плейлистов, рубриках, пагинации комментариев, логинах пользователей, запросах на удаление персональных данных, Customizer и Interactivity API.
- Утечки информации: неопубликованные изменения из Customizer могли быть видны неавторизованным посетителям, а заметки к записям — пользователям, у которых нет права редактировать саму запись.
- Отказ в обслуживании через Interactivity API — способ «положить» отдельные страницы.
- Обновление корневых сертификатов, встроенных в WordPress, после отзыва сертификатов центра eMudhra. От этого зависят защищенные соединения, которые сайт делает сам: оплаты, API, обновления.
Для большинства XSS-уязвимостей злоумышленник должен уже иметь учетную запись на сайте — например, автора или контрибьютора. Поэтому наибольший риск они несут сайтам, где пишут несколько человек, есть блоги с гостевыми авторами или открытая регистрация. Уязвимость в обновлении — другая история: для нее учетная запись не нужна.
Почему об этой уязвимости заговорили снова 3 ноября
Когда 7.1.4 только вышел, исследователи Patchstack оценили эксплуатацию RCE-уязвимости как сложную: атака возможна лишь в течение нескольких секунд, пока идет обновление. Многие успокоились — мол, теоретическая угроза, и автообновления все равно все закроют.
3 ноября 2026 года агентство кибербезопасности США CISA внесло эту уязвимость (CVE-2026-119977, «Time-of-check Time-of-use race condition в ядре WordPress») в свой каталог Known Exploited Vulnerabilities. В этот каталог попадают только уязвимости, для которых есть подтверждение реальных атак. Государственным учреждениям США, по данным профильных изданий, дали на обновление всего несколько дней. Для владельца обычного сайта вывод простой: это уже не теоретическая угроза, а инструмент, который кто-то использует.
Чем рискует сайт, который не обновился
Выполнение кода на сервере — худший сценарий для сайта. Злоумышленник может оставить себе «черный ход» (бэкдор), добавить скрытого администратора, встроить спам-ссылки или редирект на мошеннические сайты, украсть данные заказов и клиентов, рассылать спам с вашего хостинга. Часто владелец узнает о взломе не сразу, а тогда, когда Google помечает сайт как опасный, хостинг блокирует аккаунт или клиенты жалуются на странные переадресации.
Как работает атака во время обновления — простыми словами
Когда WordPress обновляет сам себя, плагин или тему, он сначала распаковывает загруженный архив во временную папку wp-content/upgrade, а затем копирует файлы на место. До версии 7.1.4 название этой папки можно было предсказать, а защитный файл, запрещающий просматривать ее содержимое, удалялся во время уборки. В результате на несколько секунд в открытой части сайта лежала полная копия WordPress — вместе со страницей первичной установки.
Если злоумышленник успевал обратиться к этой копии именно в этот момент, он мог запустить «установку WordPress» со своей базой данных и получить возможность выполнять код на вашем сервере. Обычные плагины безопасности здесь не помогают: временная копия загружает собственные файлы и не видит защиты, настроенной в основном сайте.
В 7.1.4 к названию временной папки добавляют случайные символы, защитный файл больше не удаляется, а конфигурация сайта не копируется в рабочую папку. Важный нюанс: «окно» для атаки открывается во время каждого обновления, в том числе автоматического. Именно поэтому обновление до 7.1.4 закрывает проблему, а дополнительный запрет доступа к папке wp-content/upgrade на уровне сервера — хорошая страховка на будущее.
Как за минуту проверить, обновился ли ваш сайт
Проверка действительно занимает минуту, если у вас есть доступ к админке. Если доступа нет или сайт ведет подрядчик — попросите его прислать скриншот с версией, это нормальная просьба.
Способ 1. Консоль WordPress
Войдите в админку и откройте «Консоль → Обновления». Вверху страницы WordPress пишет, какая версия установлена и есть ли более новая. Версию также видно внизу любой страницы админки, справа, и в блоке «На виду» на главной странице консоли.
Способ 2. «Здоровье сайта»
Откройте «Инструменты → Здоровье сайта». Здесь WordPress не только показывает версию, но и проверяет, работают ли фоновые обновления. Если есть проблемы с автообновлениями, запланированными задачами или правами на файлы, вы увидите их в списке рекомендаций. Этот экран стоит открыть даже тогда, когда версия уже правильная.
Способ 3. Почта администратора
После успешного автообновления WordPress отправляет письмо «Your site has updated to WordPress 7.1.4» (или аналогичное на русском) на email администратора сайта. Если письма нет, это еще не значит, что обновления не было, — но стоит проверить, на какой адрес вообще приходят письма от сайта. Нередко там до сих пор стоит почта бывшего разработчика.
Какая версия считается безопасной
- ветка 7.1 — 7.1.4 и новее;
- ветка 7.0 — 7.0.8;
- ветка 6.9 — 6.9.11;
- ветка 6.8 — 6.8.12;
- более старые ветки — последняя версия своей ветки (например, 6.4.14), вплоть до 4.7.39;
- WordPress 4.6 и старше — исправлений нет, такой сайт нуждается в полном обновлении.
Если ваш сайт на старой ветке, он защищен от этой уязвимости, но не получает новых функций и быстрее «стареет». Планировать переход на актуальную версию все равно стоит — лучше спокойно, с тестовой копией, чем в панике после взлома.
Почему WordPress может не обновиться сам
Фоновые обновления в WordPress включены по умолчанию для минорных версий и обновлений безопасности. Однако на практике цепочка «вышел релиз → сайт обновился» рвется чаще, чем кажется. Вот самые частые причины.
Автообновления отключили сознательно
Разработчик мог отключить их в файле конфигурации или плагином управления обновлениями, чтобы «ничего не сломалось». Логика понятна, но тогда кто-то должен обновлять сайт вручную. Если этого «кого-то» нет, сайт годами остается на старой версии.
Не работают запланированные задачи (WP-Cron)
Проверку обновлений WordPress запускает через свой планировщик задач. Если планировщик отключен без замены на системный cron, если хостинг блокирует внутренние запросы сайта к самому себе или если страницы полностью отдаются из кэша и PHP почти не запускается, проверка обновлений просто не происходит. Внешне сайт работает нормально, а обновления тихо останавливаются.
Нет прав на запись или закончилось место
Чтобы обновиться, WordPress должен записать новые файлы. Неправильные права доступа, другой владелец файлов или переполненный диск на хостинге — и обновление завершается ошибкой. После серьезной неудачной попытки WordPress отправляет письмо администратору и может не повторять автообновление, пока его не обновят вручную.
Сайт под системой контроля версий
Если на сервере в папке сайта есть служебная папка Git или SVN, WordPress считает, что обновлениями управляет разработчик, и сам ядро не обновляет. Это правильное поведение — но тогда обновление должно быть частью процесса разработчика.
Забытые копии сайта
Тестовые поддомены, старые версии до редизайна, копии «на всякий случай» — их никто не открывает, а значит, и не обновляет. Когда мы после выхода 7.1.4 проверили сайты, которые обслуживаем, все рабочие сайты уже стояли на новой версии благодаря автообновлениям. А вот несколько старых тестовых копий на том же хостинге остались на версиях 6.x и 7.1.1. Они не были доступны из интернета, но это хороший пример: проверять нужно не только основной сайт, а все, что лежит рядом.
Что сделать после обновления
Обновление до 7.1.4 закрывает уязвимость, но не отменяет последствий, если сайт уже успели атаковать. Поэтому после обновления стоит сделать несколько простых проверок — особенно если сайт долго стоял на старой версии.
- Проверьте, что сайт работает. Откройте главную, несколько страниц услуг, форму заявки, корзину и оплату, если это магазин. Обновления безопасности редко что-то ломают, но проверка занимает пять минут.
- Посмотрите список администраторов. «Пользователи → Все пользователи», фильтр по роли «Администратор». Каждого незнакомого — выяснить и удалить.
- Проверьте папку wp-content/upgrade. Вне момента обновления в ней должен быть только служебный файл index.php. Другие PHP-файлы там — повод для детальной проверки.
- Попросите запретить доступ к wp-content/upgrade из интернета. Это одно правило в настройках веб-сервера (.htaccess или конфигурации Nginx). Обновления оно не ломает, потому что WordPress работает с этой папкой напрямую, а не через браузер.
- Проверьте автообновления плагинов и тем. Ядро — лишь часть истории: большинство взломов WordPress происходит через устаревшие плагины.
- Убедитесь, что есть свежая резервная копия, которая хранится не только на том же сервере, — и что ее реально можно восстановить.
Если что-то из этого кажется сложным или на сайте что-то уже выглядит подозрительно, лучше не откладывать. Это именно та работа, которую закрывает техническое обслуживание сайта с контролем обновлений и бэкапов: проверка версий, мониторинг и реакция на такие новости входят в ежемесячную работу, а не делаются «когда-нибудь потом».
Кого эта новость касается больше всего
Обновиться должны все сайты на WordPress, но для некоторых риск и последствия заметно выше. Если ваш сайт в списке ниже, проверку лучше сделать сегодня.
- Интернет-магазины. Данные клиентов и заказов, платежные интеграции — самая ценная добыча, а простой магазина стоит денег каждый час.
- Сайты с несколькими авторами или открытой регистрацией. Для них актуальны и XSS-уязвимости, которым нужна учетная запись.
- Сайты, которые давно никто не обслуживает. Разработчик сделал сайт несколько лет назад, доступы потерялись, а обновления «должны были идти сами».
- Сайты на старых ветках WordPress. Особенно 4.6 и старше, которые не получили исправления вообще.
- Сайты с тестовыми копиями и поддоменами. Основной сайт обновился, а копия на test.domain — нет.
- Сайты с собственными доработками ядра или старыми темами. Здесь обновления откладывают из-за страха «слетит верстка» — и копят риски.
Если сайт годами не обновлялся из-за кастомной темы или несовместимых плагинов, это отдельная задача: сначала обновление на тестовой копии, исправление того, что сломалось, и только потом — на рабочем сайте. Такую работу мы делаем в рамках доработки сайтов на WordPress.
Обновления безопасности WordPress: почему их стало больше
7.1.4 — уже не первое срочное обновление безопасности ядра за лето и осень 2026 года. Отчасти это следствие того, что уязвимости ищет больше людей и автоматизированных инструментов, в том числе с использованием искусственного интеллекта. Отчасти — того, что WordPress остается самой распространенной платформой для сайтов, а значит, самой привлекательной целью.
Для бизнеса из этого следует не «WordPress опасен», а «WordPress нуждается в обслуживании». Платформа быстро закрывает найденные проблемы, но защищены только те сайты, на которых исправления действительно установлены. Между релизом и атакой сегодня проходят дни, а не месяцы.
Типичные ошибки владельцев сайтов
- Считать, что автообновления сработали, и не проверять версию.
- Отключить автообновления «чтобы ничего не сломалось» и никогда не обновлять сайт вручную.
- Не иметь доступа к админке собственного сайта — все пароли у бывшего подрядчика.
- Получать системные письма WordPress на почту, которую никто не читает.
- Забывать о тестовых копиях, поддоменах и старых версиях сайта на том же хостинге.
- Обновить ядро, но оставить устаревшие плагины и темы.
- Пользоваться «пиратскими» плагинами и темами, которые не обновляются вообще.
- Обновлять без резервной копии, а потом не иметь ничего для отката.
- Хранить бэкапы только на том же сервере, что и сайт.
- Годами сидеть на старой ветке WordPress из-за страха, что «слетит» тема.
- Не проверять список администраторов после новостей об уязвимостях.
- Игнорировать предупреждения в «Здоровье сайта».
- Полагаться только на плагин безопасности — он защищает не от всех сценариев, в том числе не от этого.
- Узнавать о взломе от клиентов или из предупреждения Google, а не из мониторинга.
Чек-лист: проверка сайта после выхода WordPress 7.1.4
- Версия WordPress — 7.1.4 или исправленная версия вашей ветки.
- В «Здоровье сайта» нет критических проблем.
- Фоновые обновления работают — WordPress не пишет о проблемах с ними.
- Запланированные задачи (WP-Cron или системный cron) выполняются.
- Email администратора актуален, письма от сайта приходят.
- Письмо об обновлении до 7.1.4 получено или обновление проверено вручную.
- Тестовые копии и поддомены тоже обновлены или удалены.
- В списке администраторов нет незнакомых учетных записей.
- Пароли администраторов надежные и не используются в других местах.
- В wp-content/upgrade нет посторонних PHP-файлов.
- Доступ к wp-content/upgrade из интернета запрещен на уровне сервера.
- Плагины и темы обновлены, неиспользуемые — удалены.
- Нет «пиратских» плагинов и тем.
- Есть свежая резервная копия вне сервера сайта.
- Восстановление из бэкапа хотя бы раз проверено.
- Сайт открывается, формы и оплата работают.
- Google Search Console не сообщает о проблемах безопасности.
- Известен ответственный человек, который следит за обновлениями.
Частые вопросы
Стоит сделать две вещи: убедиться в «Здоровье сайта», что автообновления работают и дальше, и быстро просмотреть список администраторов. Если сайт обновился вовремя, последствий атаки почти наверняка нет, но проверка занимает несколько минут.
Обновления безопасности в пределах одной ветки (например, с 7.1.3 до 7.1.4) меняют очень мало кода и почти никогда не ломают сайты. Риск выше, если сайт годами не обновлялся и нужно перепрыгнуть несколько больших версий, — тогда лучше сначала обновить тестовую копию.
Эта конкретная уязвимость — нет. Но принцип тот же для любой CMS: обновления безопасности нужно устанавливать быстро, а их наличие — проверять, а не предполагать.
Признаки: незнакомые администраторы, новые файлы со странными названиями, переадресации на сторонние сайты (часто только для мобильных или для посетителей из Google), спам-страницы в поиске по запросу «site:ваш-домен», предупреждения от Google или хостинга. Если видите что-то подобное — не удаляйте файлы наугад, сначала сделайте копию и обратитесь к специалисту.
Минута на проверку версии дешевле восстановления после взлома
WordPress 7.1.4 закрывает уязвимость, которую уже используют в атаках. Большинство сайтов получили исправление автоматически, но именно те, что «выпали» из автообновлений, и становятся целями. Поэтому откройте «Консоль → Обновления» и «Здоровье сайта» сегодня, а не тогда, когда что-то пойдет не так.
Если вы не уверены, кто отвечает за обновления вашего сайта, — это и есть главный вывод из этой новости. Безопасный сайт — это не разовая разработка, а регулярный уход. Мы делаем создание сайтов на WordPress под ключ и дальше берем их на ведение сайта с контролем обновлений, чтобы такие новости для наших клиентов заканчивались письмом «все уже обновлено».
