WordPress: дыра в обновлении ядра, нужен релиз 7.1.4

Что случилось

28 октября 2026 года WordPress выпустил релиз 7.1.4. В списке исправлений есть пункт, который стоит прочитать отдельно: слабое место в процессе обновления, которое может привести к удалённому выполнению кода «во время окна обновления». Нашёл его исследователь Umut Bayram. Так написано в официальном анонсе WordPress.

Позже уязвимость получила номер CVE-2026-119977. Она касается не плагина и не темы, а самого ядра. Чтобы ей воспользоваться, учётная запись на сайте не нужна.

Как это работает

Когда WordPress ставит полный пакет обновления, он сначала распаковывает файлы во временную папку внутри wp-content/upgrade. По описанию Хабра и SecurityLab, в этот момент один из временных файлов с установщиком может оказаться доступен по обычному адресу и выполнить PHP-код. Многое зависит от настроек веб-сервера.

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

Почему это не просто очередной патч

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

Есть и второй неприятный момент. Опасное окно открывается именно в момент обновления, а значит, чем реже вы обновляетесь вручную, тем дольше сайт висит на старой версии. Атакующим достаточно следить за сайтами, которые начали обновление, и бить в эти секунды. Такое поведение SecurityLab описывает по наблюдениям Wordfence: два самых активных источника несколько часов подряд проверяли небольшие группы сайтов.

Факты и цифры

• Релиз 7.1.4 вышел 28 октября 2026 года. В списке безопасности 12 исправлений и обновление корневых сертификатов (источник: WordPress.org).
• Оценка по CVSS: 8,1 (по данным Хабра и SecurityLab).
• Затронуты версии с 4.7 по 7.1.3 включительно (там же).
• Исправления вышли в 7.1.4. Для старых веток, по данным Хабра, это 7.0.8, 6.9.11 и 4.7.39. WordPress.org пишет, что бэкпорты идут и выходят по мере готовности, так что точную версию своей ветки сверяйте на wordpress.org.
• Версии 4.6 и старше исправлений не получают.
• По данным SecurityLab со ссылкой на Wordfence, за первые 21 час наблюдения было больше 18 500 подозрительных запросов. Первое срабатывание правила пришло через девять минут после публикации релиза.
• Wordfence не сообщил о подтверждённых успешных взломах. Число запросов не равно числу взломанных сайтов.
• Хабр пишет, что 3 ноября 2026 года CISA добавила уязвимость в каталог эксплуатируемых. Мы эту запись у CISA напрямую не проверяли.

Что это значит для бизнеса

Для интернет-магазина или сайта с заявками это классический сценарий. Подрядчик, который «когда-то делал сайт», обычно не следит за версиями. Хостинг обычно не обновляет ядро за вас. Владелец узнаёт о проблеме, когда клиенты жалуются на странные переходы или поисковик пометил сайт как опасный. Вот что бывает после взлома: чужой код на вашем сервере значит скрытые редиректы, подмену форм, спам от вашего имени и потерю позиций в поиске. Лечить последствия дороже, чем обновиться.

Отдельно о тех, кто сидит на версиях старше 4.7 и на заброшенных сайтах. Обновления безопасности для них не выйдут вообще. Единственный выход — переезд на поддерживаемую версию.

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

Если у вас сайт на 1С-Битрикс или Аспро, эта новость вас напрямую не касается. Но если рядом живёт блог, лендинг или старый сайт на WordPress, проверьте и его.

Как проверить и защититься

1. Откройте админку: Консоль, затем «Обновления». Там видна текущая версия. Если ниже 7.1.4 или патча вашей ветки, обновляйтесь.
2. Сначала сделайте копию файлов и базы. Если копий нет, это отдельная проблема, и решать её нужно сегодня.
3. До обновления закройте доступ к папке wp-content/upgrade/ на уровне веб-сервера. Для nginx это правило location ^~ /wp-content/upgrade/ { deny all; }. Его же советуют Хабр и SecurityLab.
4. После обновления проверьте версию и убедитесь, что она действительно изменилась.
5. Просмотрите логи доступа на запросы к временным файлам установщика. Откройте список администраторов: незнакомая учётная запись — повод бить тревогу. Посторонний .php-файл в папке upgrade Хабр советует считать признаком взлома.

Wordfence, по данным SecurityLab, выпустил правило файрвола для платных пользователей 28 октября. Бесплатным оно придёт 27 ноября, с задержкой в 30 дней. Ждать его не нужно: обновление закрывает проблему само.

Коротко

В WordPress от 4.7 до 7.1.3 нашли уязвимость в процессе обновления, которая позволяет выполнить код без входа в админку. Исправление вышло 28 октября. Проверьте версию, сделайте копию, закройте wp-content/upgrade/ и обновитесь. Если версия старше 4.7, сайт придётся переносить.