У сайта может быть свежий WordPress, обновлённые плагины и аккуратная админка — и при этом уязвимая серверная среда. 21 октября 2026 года команда PHP выпустила обновления, закрывающие две критические уязвимости CVE-2026-109618 и CVE-2026-109619. По данным PHP Project, они могут позволить удалённое выполнение кода без аутентификации. Для затронутых веток разработчики прямо указывают: полных способов защиты без обновления нет.
Для руководителя вывод проще технических деталей: сейчас стоит проверить, на какой версии PHP работает сайт компании и кто отвечает за её обновление. Это касается не только WordPress. PHP используется во множестве сайтов и веб-приложений, поэтому «CMS у нас обновляется автоматически» не отвечает на главный вопрос.
Почему обновление WordPress само по себе не решает проблему
WordPress 21 октября отдельно предупредил владельцев сайтов о критическом обновлении PHP. В сообщении подчёркивается: уязвимости относятся не к WordPress, поэтому отдельного патча самой CMS для них не требуется. Исправлять нужно серверную среду.
Это важное различие. В типичной схеме есть несколько уровней: CMS, плагины и тема, PHP, веб-сервер, база данных и настройки хостинга. Автообновление WordPress может закрыть проблему в ядре CMS, но не обновляет PHP на сервере.
Поэтому вопрос «у нас WordPress последней версии?» сейчас недостаточен. Нужны ещё два: «какая версия PHP фактически обслуживает сайт?» и «получила ли эта версия исправление от 21 октября?».
Какие версии нужно проверить в первую очередь
PHP Project выпустил исправленные версии для поддерживаемых веток. Например, для PHP 8.2 это 8.2.35, для PHP 8.3 — 8.3.36, для PHP 8.4 — 8.4.27. Если сервер работает на одной из этих веток, нужно сверить установленную версию с актуальным релизом своей ветки, а не ориентироваться только на первую цифру.
Отдельный риск — старые версии. WordPress напоминает, что ветки PHP ниже 8.2 больше не получают обновления безопасности от PHP Project. Если сайт всё ещё работает на такой версии, задача уже шире одного срочного патча: нужно планировать переход на поддерживаемую ветку и проверять совместимость сайта.
Самостоятельно искать номер версии в коде не обязательно. На WordPress его можно увидеть в «Инструменты → Здоровье сайта → Информация → Сервер». На управляемом хостинге версию часто показывает панель управления. Если сайт сопровождает подрядчик, достаточно запросить у него фактическую версию и подтверждение обновления.
Почему нельзя просто переключить PHP на самую новую версию
Срочность не отменяет проверку совместимости. Старый сайт может зависеть от темы, плагина или собственного кода, который некорректно работает на новой ветке PHP. Мгновенное переключение версии на боевом сервере способно превратить задачу безопасности в простой сайта, ошибку оплаты или неработающую форму заявки.
Нормальный сценарий выглядит так: сделать актуальную резервную копию файлов и базы данных, проверить обновление на тестовой копии или в контролируемом окне, пройти ключевые пользовательские сценарии и только затем обновлять рабочую среду. Для интернет-магазина стоит отдельно проверить корзину, оплату, уведомления и обмен с внешними системами; для корпоративного сайта — формы, личные кабинеты и интеграции с CRM.
Резервная копия здесь нужна не «для галочки». До начала работ должно быть понятно, где она хранится и как быстро из неё восстановить сайт, если после смены PHP обнаружится несовместимость.
Что запросить у хостинга или подрядчика сегодня
Руководителю не нужен технический отчёт на десять страниц. Достаточно получить ответы на пять вопросов:
- Какая версия PHP сейчас фактически используется на сайте?
- Установлено ли исправление безопасности от 21 октября для этой ветки?
- Если версия устарела, какой план перехода на поддерживаемую ветку и что мешает обновиться сразу?
- Есть ли свежая резервная копия файлов и базы данных, из которой сайт можно восстановить?
- Как после обновления проверят формы, оплату, интеграции и другие критичные функции?
Если хостинг управляемый, часть обновлений могла быть выполнена автоматически. Но предполагать это не стоит: WordPress рекомендует проверить уведомления хостинга и при необходимости обновить PHP как можно скорее.
Если обновиться быстро нельзя
И PHP Project, и NCSC оценивают ситуацию жёстко. NCSC рекомендует в первую очередь выявить интернет-доступные системы с PHP, следить за признаками вредоносной активности и применить обновления. Если немедленное устранение невозможно, организациям советуют рассмотреть отключение системы до полноценного исправления.
Для бизнеса это крайняя мера, но она показывает приоритет риска. WAF и дополнительные фильтры могут быть частью временной защиты, однако WordPress указывает, что хостеры могут применять такие меры лишь как снижение риска. PHP Project сообщает, что полных способов обойти проблему нет: безопасным решением остаётся обновление.
Если сайт нельзя обновить из-за старого кода, не стоит бесконечно откладывать задачу под предлогом совместимости. Нужно определить, что именно блокирует переход: конкретный плагин, тема, модуль интеграции или версия CMS. После этого можно оценить замену компонента, доработку или миграцию.
Что проверить после обновления
Сам факт смены версии PHP ещё не означает, что задача закрыта. После работ стоит убедиться, что сайт отвечает без ошибок, заявки доходят до почты или CRM, формы отправляются, авторизация работает, а интернет-магазин корректно оформляет заказ и проводит оплату.
Дополнительно имеет смысл проверить журналы ошибок и событий безопасности за период вокруг обновления. Это особенно актуально для публичных сайтов, поскольку NCSC рекомендует мониторить интернет-доступные PHP-системы на вредоносную активность.
Если компания не знает, кто отвечает за PHP, резервные копии и серверные обновления, это уже отдельный организационный риск. Сайт может годами работать стабильно, пока не появляется уязвимость, несовместимость или авария, требующая действий в течение часов, а не недель.
Как выстроить обслуживание сайта, чтобы не реагировать в последний момент
Срочные уязвимости хорошо показывают разницу между «сайт размещён на хостинге» и «сайт технически сопровождается». Во втором случае должны быть определены ответственные за обновления CMS и серверного окружения, резервное копирование, проверку совместимости и контроль после изменений.
Для WordPress и других поддерживаемых платформ IT-Wizards оказывает техническую поддержку сайтов: диагностику, исправление сбоев, работу с кодом, хостингом, доменом, SSL, формами и внешними сервисами. В ситуации с критическим обновлением задача начинается с проверки текущего окружения и только затем переходит к безопасному обновлению и тестированию.
Главный вывод
Уязвимости от 21 октября находятся ниже уровня WordPress, поэтому обновлённая CMS не гарантирует, что серверная среда уже защищена. Руководителю не нужно самостоятельно администрировать PHP, но нужно получить подтверждение версии, статуса обновления, наличия рабочей резервной копии и проверки сайта после изменений.
Если эти четыре пункта нельзя быстро подтвердить, проблема шире одного экстренного патча: у сайта нет прозрачного процесса технического сопровождения. И его стоит выстроить до следующего критического обновления, а не после первого серьёзного сбоя.
Источники: PHP Project, WordPress.org, UK National Cyber Security Centre.
