Уязвимости PHP в октябре 2026: что проверить на сайте

21 октября 2026 года разработчики PHP выпустили исправления двух критических уязвимостей: CVE-2026-109618 и CVE-2026-109619. Обе связаны с обработкой запросов и при определенных условиях могут приводить к удаленному выполнению кода. Для владельца сайта на WordPress, 1С-Битрикс или собственном PHP-приложении задача — подтвердить исправление среды, которая фактически обслуживает посетителей.

Новый номер PHP в SSH-консоли подтверждает версию вызванного бинарника. Сайт при этом может продолжать работать через другой PHP-FPM, пакет панели управления или старый контейнер. Поэтому проверка должна охватить web-процесс, фоновые задания и критичные функции: вход, заявки, заказы и интеграции.

Сведения о релизах и уточнениях проверены 2 ноября 2026 года. Ниже — порядок обследования и приемки для ответственного за сайт и администратора. Он не устанавливает факт взлома конкретного проекта и не заменяет проверку пакетов его поставщиком.

Какие версии PHP содержат первоначальные исправления

В официальных advisories об ошибке при нехватке памяти и о сохранении состояния между запросами указаны первые исправленные выпуски поддерживаемых веток:

Ветка	Первый выпуск с исправлениями двух CVE от 21 октября
PHP 8.2	8.2.35
PHP 8.3	8.3.36
PHP 8.4	8.4.27
PHP 8.5	8.5.12

Таблица относится к двум указанным уязвимостям. Перед обновлением проверьте актуальные исправления своей ветки и последующие сообщения безопасности. Для пакета дистрибутива учитывается также его полная ревизия и бюллетень поставщика.

Так, в таблице cPanel отдельно перечислены варианты EasyApache и CloudLinux. У некоторых исправленных пакетов сохраняется более ранний номер исходной версии PHP с измененной ревизией. Это пример backport: поставщик переносит исправление в собственную поддерживаемую сборку. Наличие такого исправления нужно подтвердить для конкретного пакета; одного предположения по названию ОС недостаточно.

Какие октябрьские уточнения учесть отдельно

По сообщению PHP от 26 октября, Windows-пакеты пересобраны с Brotli 1.2.1. Суффикс -1 относится к сборке пакета, версия самого PHP остается прежней. Поэтому для Windows сохраняйте сведения о полном установленном пакете и его происхождении.

Для отдельной проблемы CVE-2026-115560 PHP опубликовал уточнение 23 октября. Описана редкая комбинация настроек и кода при работе с session upload progress. В сообщении cPanel, обновленном 28 октября, приведена временная настройка session.upload_progress.enabled=0. Поручите администратору проверить применимость и действующее исправление; изменение должно попасть в нужную серверную конфигурацию и пройти проверку функций сайта.

Для исходных двух CVE временные ограничения имеют неполное покрытие. Установка исправленного кода остается основным действием. Не копируйте случайный набор параметров php.ini как универсальное подтверждение безопасности.

Сначала найдите PHP, который обслуживает сайт

Составьте ведомость компонентов. В одном аккаунте хостинга могут сосуществовать разные обработчики для основного домена, старого поддомена и административного сервиса. В отдельной среде могут работать импорт товаров, генерация документов и обработка очереди.

Компонент	Что записать	Чем подтвердить после обновления
Основной сайт и API	Обработчик, версия, пакет, конфигурация	Сведениями о работающем web-процессе
Поддомены и старые приложения	Связь домена с конкретной средой	Проверкой каждого используемого обработчика
Cron и очереди	Пользователь, путь к PHP, команда запуска	Выполнением согласованной диагностической задачи
Контейнеры	Образ, базовая среда и запущенный экземпляр	Составом нового образа и проверкой работающего контейнера
Хостинг или панель	Поставщик пакета и назначенная домену версия	Полной ревизией и ответом службы поддержки

Команды ниже предназначены для диагностики выбранного CLI-интерпретатора в sh/bash. Они не устанавливают обновления и не перезапускают службы:

php -v
php --ini
php -m

По документации PHP, эти параметры показывают версию, конфигурационные файлы и загруженные модули. Зафиксируйте также путь к вызываемому исполняемому файлу. В той же выбранной среде можно получить компактную сводку:

php -r 'echo json_encode(["version" => PHP_VERSION, "sapi" => PHP_SAPI, "binary" => PHP_BINARY, "ini" => php_ini_loaded_file()], JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES), PHP_EOL;'

Значение sapi обозначает способ запуска PHP: например, cli, fpm-fcgi или apache2handler. Документация SAPI объясняет различия, а php_ini_loaded_file() возвращает путь загруженного php.ini либо false. Вывод этой команды относится к текущему CLI-вызову.

Web-окружение проверяйте отдельно: через закрытую диагностику, конфигурацию обработчика домена и сведения администратора о запущенных процессах. Полную страницу phpinfo() в публичном каталоге оставлять не следует: она раскрывает лишние сведения об окружении. Для отчета достаточно согласованного набора технических данных без секретов.

Как подтвердить исправление у хостинга

Запрос «обновите PHP» слишком неопределенный. Передайте домен, используемую панель, известную версию и названия уязвимостей. Попросите указать:

1. Какой пакет PHP фактически назначен домену и включены ли исправления CVE-2026-109618 и CVE-2026-109619.
2. Какая полная ревизия установлена и на какой бюллетень поставщика опирается подтверждение.
3. Были ли заменены работающие процессы и как это проверено.
4. Какие отдельные действия нужны для cron, очередей, контейнеров и других версий в аккаунте.
5. Проверены ли уточнения по CVE-2026-115560 и состав Windows-пакета, если это относится к вашей среде.

Ответ сохраните в карточке технической задачи вместе с датой проверки. Если хостинг использует собственные пакеты, сравнение только с таблицей upstream-версий не дает полного ответа. Применимость исправлений и статус поддерживаемой сборки должен подтвердить ее поставщик.

Подготовьте обновление отдельно от переделки приложения

Сначала сохраните рабочие конфигурации, текущий состав пакетов и резервные копии данных. Проверьте порядок восстановления и назначьте ответственного за решение о выпуске. Для магазина определите, как будут учтены заказы, появившиеся после создания копии. Простое восстановление старой базы способно удалить новые операции.

Затем подготовьте тестовую среду с целевым исправленным PHP, необходимыми расширениями и настройками. Доступ к ней ограничьте. Реальные оплаты, рассылки и внешние изменения отключите или замените согласованными тестовыми сценариями. Скопированные данные должны использоваться по правилам проекта.

Если текущая ветка поддерживается и получает нужные исправления, можно сначала проверить обновление внутри нее. Смену основной версии, базы, CMS и всей темы лучше планировать как отдельные изменения с понятной причиной. Это упрощает поиск несовместимости.

Для PHP 8.2 учитывайте календарь: upstream-поддержка безопасности заканчивается 31 декабря 2026 года. До этой даты остается время на подготовку перехода; требования CMS, расширений и поставщика хостинга нужно сверить заранее. Договорная поддержка конкретного вендора рассматривается отдельно от календаря PHP.net.

Для ядра, темы и плагинов WordPress используйте отдельный порядок подготовки обновления. Исправление PHP и изменение WordPress — разные пункты ведомости релиза.

Что проверить на тестовой копии и после выпуска

Приемка строится вокруг операций, на которых работает бизнес. Заранее определите контролируемые учетные записи, получателей писем и тестовые данные. Положительный результат одного HTTP-запроса не подтверждает выполнение всей цепочки.

Сценарий	Минимальная проверка	Подтверждение результата
Публичные страницы	Главная, услуга, каталог, карточка, поиск	Корректный HTML, изображения и отсутствие новых ошибок
Вход и сессии	Вход, выход, разрешенные разделы	Состояние сохраняется и права не расширяются
Заявка	Отправка, ошибка валидации, повторное нажатие	Одна запись у ответственного, понятное сообщение посетителю
Магазин	Корзина и согласованный тестовый заказ	Заказ, статус, письмо и учет без дублей
Файлы	Допустимый файл и предусмотренный отказ	Корректная обработка и доступ к сохраненному результату
Cron и очереди	Задание под рабочим пользователем	Успешное завершение и ожидаемая обработка
Интеграции	Тестовый обмен и предусмотренный сбой	Подтверждение у получателя и управляемая повторная попытка

В Битрикс отдельно проверьте выполнение агентов и почтовых событий. Если письма задерживаются, диагностируйте цепочку по инструкции для очереди b_event, сохраняя актуальные уведомления. Нельзя очищать очередь только ради удобства тестирования обновления.

Для CRM и обмена с учетной системой проверяйте внешние идентификаторы и защиту от дублей. Полезная основа для такой ведомости — раздел об интеграциях в материале об архитектуре CRM. Тестовый ответ API должен соответствовать реальному состоянию записи у получателя.

Как выпускать обновление и готовить восстановление

Зафиксируйте состав проверенного кандидата: код приложения, конфигурацию, пакет PHP или образ, расширения и результаты приемки. Перед переключением еще раз уточните, какие службы и рабочие процессы относятся к этому сайту. Универсальный перезапуск всех контейнеров или всех приложений на сервере добавляет риск посторонним сервисам.

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

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

Обновление не удаляет уже внедренный посторонний код. При признаках компрометации нужна отдельная процедура: сохранение материалов расследования, проверка целостности, восстановление и замена затронутых доступов. Для WordPress есть план действий после взлома; факт заражения нельзя выводить только из старой версии PHP.

Какой отчет запросить у ответственного

Итогом задачи должна быть короткая ведомость: домены и процессы, поставщик и ревизия пакета, применимые исправления, время переключения, результаты сценариев и оставшиеся ограничения. Отдельно перечислите непроверенные компоненты. Формулировка «PHP обновлен» без этого контекста оставляет неясным, какая часть системы принята.

Если у сайта несколько обработчиков, обменов или устаревших компонентов, включите такую проверку в техническую поддержку сайта. Для постановки задачи достаточно перечня доменов, доступа к текущей документации и списка операций, которые должны продолжить работать. Пароли и конфигурационные секреты в публичную заявку включать не нужно.

FAQ

Достаточно ли обновить WordPress или Битрикс?

Проверьте серверный PHP отдельно. Ядро CMS, расширения и среда выполнения имеют собственные версии и процедуры обновления. В отчет должны попасть те компоненты, которые действительно обслуживают сайт.

Почему php -v показывает новую версию, а сайт работает на старой?

Консоль и web-сервер могут использовать разные бинарники, пакеты и конфигурации. Сопоставьте домен с его обработчиком, проверьте запущенные процессы и отдельно задания по расписанию. Вывод CLI относится к вызванной команде.

Можно ли оценить пакет только по номеру PHP?

Для сборки поставщика нужна полная ревизия и подтверждение наличия исправления. Вендор может перенести патч в свою версию. Такой статус проверяется по его бюллетеню для конкретного пакета.

Значит ли старый PHP, что сайт уже взломан?

Нет. Версия указывает на необходимость проверки исправлений, а факт инцидента устанавливается отдельным расследованием. Отсутствие заметных симптомов также не подтверждает безопасность конфигурации.

Источники

• PHP: сообщения безопасности за октябрь 2026 года.
• PHP: RCE via OOM corruption, CVE-2026-109618.
• PHP: RCE via stale global state, CVE-2026-109619.
• Red Hat: RHSB-2026-013.
• cPanel: критические исправления и версии пакетов.
• cPanel: отдельное сообщение о CVE-2026-115560.
• PHP: параметры командной строки.
• PHP: php_sapi_name и PHP_SAPI.
• PHP: php_ini_loaded_file.
• PHP: предопределенные константы.
• PHP: сроки поддержки веток.