Критические уязвимости PHP в октябре 2026: что делать владельцу сайта
Если ваш сайт работает на PHP, сейчас стоит связаться с хостингом или администратором сервера. 21 октября 2026 года команда PHP выпустила исправления двух критических уязвимостей: CVE-2026-109618 и CVE-2026-109619. Они могут позволить постороннему выполнить код на сервере без входа на сайт. Для владельца бизнеса первый шаг — выяснить, установлен ли исправленный пакет PHP именно для его сайта.
Что произошло и кого это касается?
В сообщении от 21 октября команда PHP относит к группе риска установки, обслуживающие веб-запросы: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Наибольший риск отмечен для mod_php: показана атака, которая срабатывает ещё до запуска кода сайта.
Поэтому фразы «у нас нет регистрации» или «админка закрыта паролем» сами по себе не отвечают на вопрос о защите. Проблема находится в PHP, на котором выполняется сайт. Обновление Битрикса, WordPress или другой CMS не заменяет исправление серверного пакета.
Наличие уязвимой версии ещё не означает, что сайт уже взломан. Но откладывать проверку до появления заметных сбоев не стоит: нормальная работа страниц не подтверждает безопасность сервера.
Какие версии PHP содержат исправления?
Для поддерживаемых стабильных веток выпущены следующие версии. Это минимальные исправленные выпуски в каждой из перечисленных веток.
| Ветка PHP | Версия с исправлениями |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
Список опубликован в бюллетене PHP об ошибке обработки нехватки памяти. Для сайта на PHP 8.3 нужно обсуждать установку исправления в ветке 8.3; срочная проверка безопасности не требует автоматически переходить на 8.5.
У Linux-дистрибутивов и поставщиков длительной поддержки исправление может быть перенесено в пакет с прежним базовым номером PHP. Тогда нужен ответ поставщика о закрытии обеих CVE и полный номер пакета. Одной надписи «PHP 8.3» в панели недостаточно. PHP 8.1 и более старые ветки уже не получают обычных обновлений от проекта PHP: для них нужно отдельно выяснять наличие исправления у поставщика и планировать переход на поддерживаемую ветку.
Почему здесь две уязвимости?
CVE-2026-109618 связана с обработкой нехватки памяти. При прерывании запроса PHP может оставить внутренние данные в некорректном состоянии, а затем использовать их при завершении работы запроса. В техническом разборе подтверждено удалённое выполнение кода с правами рабочего процесса веб-сервера.
CVE-2026-109619 касается внутреннего состояния, которое переживает один запрос и используется следующим после освобождения связанной с ним памяти. Условия зависят от конфигурации и приложения. Бюллетень второй уязвимости разбирает в том числе подтверждённый путь для PHP-FPM, которому нужна подходящая операция в приложении. Считать FPM заведомо защищённым нельзя.
Оба бюллетеня называют полное обновление необходимой мерой. Изменения настроек могут перекрыть отдельные способы атаки, но не дают общей защиты. Копировать временные настройки из чужой инструкции без оценки своего сервера не стоит: это работа администратора, а не замена установке исправлений.
Что написать хостингу или администратору?
Вместо общего вопроса «у вас всё безопасно?» можно отправить короткий запрос:
Проверьте, пожалуйста, защиту нашего сайта от CVE-2026-109618 и CVE-2026-109619. Какая версия и сборка PHP обслуживает его веб-запросы? Установлены ли исправления обеих уязвимостей? Если используется пакет с перенесёнными исправлениями, пришлите номер пакета и ссылку на бюллетень поставщика. Перезапущены ли рабочие процессы PHP после обновления?
На обычном хостинге пакетами сервера чаще занимается провайдер. На VPS ответственность нужно уточнить: аренда сервера сама по себе ещё не говорит, кто устанавливает обновления. Если сайт ведёт подрядчик, полезно сразу подключить его к разговору о совместимости и проверке функций.
Как проверить результат без долгого простоя?
До работ стоит убедиться, что есть пригодная для восстановления копия файлов и базы данных. Затем согласовать с администратором установку исправленного пакета, перезапуск обслуживающих сайт процессов и короткую проверку основных сценариев.
Для магазина это открытие каталога и карточки, добавление товара в корзину, оформление тестового заказа, работа интеграций. Для сайта услуг — отправка формы и получение обращения. Важно проверить и фоновые задания, если они используют отдельную версию PHP: например, обмен или импорт по расписанию.
В отчёте о работе нужны версия или сборка пакета, подтверждение исправления обеих CVE и результаты проверки сайта. Если уже замечены посторонние файлы или неожиданные изменения, одной установки обновления мало: потребуется отдельно разобраться в возможном проникновении.
Если некому согласовать эти работы с хостингом и проверить сайт после них, задачу можно передать в поддержку WBStudio. В обращении достаточно указать адрес сайта и тип хостинга; пароли в описание заявки добавлять не нужно.