21 октября 2026 года команда PHP выпустила исправления двух критических уязвимостей. Для владельца сайта на WordPress это повод срочно связаться с хостингом и ответственным за поддержку: обновить только сам WordPress в данном случае недостаточно. PHP — серверная среда, в которой выполняется сайт; её обслуживание может находиться за пределами доступа обычного администратора WordPress.
В сообщении WordPress.org от 21 октября отдельно поясняется: проблема не ограничивается WordPress, а отдельное обновление этой CMS для её исправления не требуется и не планируется. Поэтому привычный ответ «в админке все обновления установлены» ещё не закрывает вопрос.
Что сделать сегодня: запросить подтверждение, что исправления PHP установлены именно для вашего сайта, и назначить человека, который проверит его работу после изменения серверной среды.
Сначала выясните, кто отвечает за сервер
На обычном виртуальном хостинге серверную часть обслуживает провайдер. При аренде отдельного виртуального сервера ответственность может лежать на вашем администраторе или подрядчике. Не стоит предполагать, что разработчик сайта автоматически следит за всеми обновлениями: это зависит от состава оплаченного сопровождения.
Отправьте запрос обеим сторонам, если границы ответственности пока не определены. Хостинг должен пояснить состояние своей среды, а специалист по сайту — оценить совместимость и проверить рабочие сценарии. Согласуйте одного ответственного, который соберёт ответы и сообщит о завершении работ. Два сообщения «это не к нам» не дают бизнесу результата.
Какие подтверждения запросить
- Версия и исправления. Какая сборка PHP обслуживает рабочий домен и устранены ли в ней обе уязвимости из сообщения от 21 октября?
- Срок. Если исправления ещё не установлены, когда планируется установка и кто уведомит о её завершении?
- Защита на время работ. Какие меры приняты до обновления и какие ограничения у них остаются?
- Проверка сайта. Кто отвечает за формы, оформление заказа и другие важные функции после изменения?
В официальном сообщении PHP названы исправленные выпуски: 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Для некоторых серверных систем поставщики выпускают собственные пакеты с перенесёнными исправлениями. Поэтому при другом номере сборки просите ссылку на уведомление поставщика и подтверждение применения патча, а не делайте вывод по одной цифре.
Не поручайте сотруднику просто выбрать самую новую версию в панели хостинга. Исправление безопасности в используемой ветке и переход между ветками — разные изменения. Выбор подходящего пути должен сделать специалист с учётом темы, плагинов и индивидуальных доработок.
Готовый запрос для хостинга и подрядчика
Тема: проверка исправлений PHP для нашего сайта
Просим проверить рабочий домен в связи с критическим релизом PHP от 21.10.2026. Подтвердите, пожалуйста, текущую сборку и применение исправлений CVE-2026-109618 и CVE-2026-109619. Если работы ещё идут, укажите срок и ответственного.
До изменения согласуйте резервную копию, проверку совместимости и порядок действий при сбое. После завершения просим подтвердить фактическое обновление среды и результаты проверки основных функций сайта.
Добавьте адрес сайта и контакт сотрудника, который сможет проверить обращения или тестовый заказ. Пароли и данные клиентов в такое письмо прикладывать не нужно. Если исполнителю потребуются дополнительные полномочия, согласуйте их отдельно.
Как принять результат без чтения технического отчёта
Попросите короткий отчёт с датой работ, применённой сборкой или пакетом исправлений и результатом проверок. В нём должно быть понятно, какая среда обновлена: рабочий сайт, тестовая копия или только командный инструмент на сервере. Для компании важна среда, которая действительно обрабатывает обращения посетителей.
Со своей стороны проверьте доступность основных страниц и отправьте согласованную тестовую заявку. Для магазина попросите специалиста провести тестовый заказ и подтвердить его получение менеджером. Не ограничивайтесь открытием главной: ошибка может проявиться только при отправке формы или обработке оплаты.
Если после работ обнаружилась неисправность, зафиксируйте конкретное действие и время. Порядок восстановления должен учитывать безопасность: возвращение к прежней уязвимой среде нельзя оставлять единственным решением. Выбор временной меры и дальнейший план согласуют специалисты хостинга и поддержки.
Два вопроса, которые возникают у владельца
Если сайт открывается, можно подождать? Доступность страницы не подтверждает устранение уязвимости. Команда PHP призывает обновиться немедленно и указывает, что временные меры не делают установку полностью безопасной. Запрос на проверку лучше отправить сразу.
Означает ли новость, что сайт уже взломан? Нет: наличие уязвимой среды и подтверждённый инцидент — разные вещи. Если есть подозрительные изменения, поручите отдельную проверку. Сам факт установки исправления не является заключением об отсутствии предыдущего вмешательства.
После срочных работ полезно уточнить договорённости о сопровождении: кто отслеживает серверные предупреждения, кто связывается с хостингом и как компания получает подтверждение завершения. Тогда следующая подобная новость превратится в управляемую задачу, а не в поиск ответственного.
