21 октября 2026 года команда PHP выпустила исправления для двух критических уязвимостей: CVE-2026-109618 и CVE-2026-109619. Обе могут привести к удалённому выполнению кода без предварительной авторизации. Для владельца сайта задача сейчас — не просто узнать номер PHP, а подтвердить, что исправлен именно тот интерпретатор, который обрабатывает запросы посетителей.
Короткий ответ: для поддерживаемых веток нужны PHP 8.2.35, 8.3.36, 8.4.27 или 8.5.12, либо более новые исправленные выпуски соответствующей ветки. Если PHP установлен из пакетов Linux-дистрибутива или поставщика длительной поддержки, проверьте его бюллетень: исправления могут быть перенесены в пакет без смены базовой версии. Основание — официальное сообщение команды PHP от 21 октября.
Что произошло и почему обновление касается не только CMS
Это проблемы самого PHP, а не отдельного плагина, CMS или фреймворка.
- CVE-2026-109618 связана с обработкой нехватки памяти: внутренние данные запроса могут остаться в некорректном состоянии, а затем использоваться при завершении обработки. Подробности опубликованы в бюллетене PHP о повреждении состояния при OOM.
- CVE-2026-109619 связана с устаревшим внутренним состоянием процесса: данные предыдущего запроса могут затронуть обработку следующего. См. отдельный бюллетень PHP.
По сообщению разработчиков, проверять нужно веб-установки PHP, включая PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Особо высокий риск отмечен для mod_php: продемонстрирован сценарий, который срабатывает ещё до выполнения кода приложения. Это не означает, что любую установку PHP-FPM можно считать защищённой.
Обновление CMS не заменяет исправление PHP. И наоборот: установка исправленного PHP не отменяет необходимость поддерживать CMS и её модули. В этом материале речь именно о выпуске безопасности от 21 октября, а общий порядок подготовки перехода описан в нашем руководстве по обновлению PHP на действующем сайте.
Какие версии содержат исправления
| Поддерживаемая ветка | Исправленный upstream-выпуск |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Таблица относится к выпускам проекта PHP. У пакета операционной системы может быть другая полная версия и собственная ревизия исправления. Поэтому сравнение только строки PHP 8.2.x или PHP 7.4.33 недостаточно: нужны название репозитория, полная версия пакета и подтверждение устранения обеих CVE.
Для PHP 8.1 и более старых веток PHP-проект больше не выпускает обычные обновления безопасности. Наличие стороннего backport-пакета нужно проверять у конкретного поставщика. Такой пакет может закрыть эти две уязвимости, но не делает старую ветку снова официально поддерживаемой и не заменяет план перехода.
Что попросить у хостинга или администратора
Вместо общего вопроса «у нас PHP обновлён?» отправьте короткий запрос:
Подтвердите устранение CVE-2026-109618 и CVE-2026-109619 на нашем сайте. Нужны полная версия пакета, источник обновления, ссылка на бюллетень или changelog и подтверждение, что исправлен веб-обработчик сайта. Отдельно укажите версии для фоновых задач, если они отличаются.
У ответа должны быть четыре проверяемые части:
- Где работает сайт: сервер или контейнер, версия PHP и способ запуска.
- Чем подтверждено исправление: официальный выпуск либо бюллетень поставщика с обеими CVE.
- Что уже применено: пакет не только скачан, но установлен; обработчики переведены на исправленную сборку по регламенту эксплуатации.
- Что проверено после обновления: ошибки приложения и основные пользовательские сценарии.
Если используется облачный или управляемый хостинг, обновлением пакетов может заниматься провайдер. В таком случае полезнее получить его подтверждение, чем пытаться самостоятельно менять системное окружение без доступа и понимания схемы запуска.
Почему одной команды php -v недостаточно
Команда в терминале показывает CLI-версию. Сайт при этом может обслуживаться другим PHP-FPM-пулом, модулем Apache или контейнером.
Для администратора на Debian-подобной системе начальная инвентаризация может выглядеть так:
php -v
dpkg-query -W 'php*-cli' 'php*-fpm' 'libapache2-mod-php*'Это команды чтения сведений, а не универсальный сценарий обновления. Они не доказывают, что конкретный виртуальный хост использует нужный обработчик. Нужно сопоставить конфигурацию веб-сервера, активный пул или контейнер и установленный пакет. Не оставляйте публичный файл phpinfo() ради такой проверки: сведения об окружении не должны становиться доступными посетителям.
Для Docker важно проверить образ и работающие контейнеры. Пересборка образа или появление нового тега в реестре сами по себе ещё не означают, что рабочий сервис уже запущен на исправленной сборке.
Как принять обновление на рабочем сайте
Исправление безопасности и переход на другую ветку PHP — разные задачи. Если доступен исправленный пакет текущей совместимой ветки, не обязательно совмещать срочное устранение CVE с большой миграцией приложения. Но совместимость пакета, расширений и способ применения всё равно нужно проверить.
Практичный список приёмки:
- Есть актуальная резервная копия и понятный способ восстановления.
- Зафиксированы исходная и установленная полные версии пакетов, а также источник исправлений.
- Проверено, что сайт обслуживает исправленный PHP, а не только новая CLI-команда.
- Проверены вход в кабинет, форма заявки, загрузка файла и получение сообщения в рабочей системе обработки обращений.
- Для магазина отдельно проверены корзина, заказ, оплата и важные обмены; тесты не должны создавать случайные реальные списания или заказы.
- После переключения проверены журналы ошибок и фоновые задания.
Нормально открывающаяся главная страница — ещё не вся приёмка. Ошибка может проявиться только при отправке формы, авторизации, обработке файла или выполнении задачи по расписанию.
Частые вопросы
Если сайт работает нормально, можно ничего не делать?
Нет оснований считать исправление установленным только потому, что посетители не жалуются. Сначала получите подтверждение версии и статуса обеих CVE. Сам факт публикации бюллетеня, в свою очередь, не доказывает, что именно ваш сайт уже был атакован или взломан.
Достаточно обновить PHP только на одном сервере?
Нужно проверить все обработчики, через которые обслуживается проект: дополнительные узлы, контейнеры и фоновые процессы могут иметь свои версии. Объём проверки определяется реальной схемой размещения, а не количеством доменных имён.
Если поставщик обещает backport, обязательно переходить на PHP 8.5?
Не следует переключать рабочий проект на другую ветку вслепую. Сначала подтвердите, какие уязвимости закрыты конкретным пакетом, и проверьте его совместимость. Если проект остаётся на устаревшей ветке, запланируйте переход отдельно: разовое исправление CVE не отменяет накопленные ограничения поддержки.
Когда нужна помощь OpenStart
Если хостинг уже применил исправления и подтвердил их, а ваши основные сценарии проверены, отдельная миграция ради этой новости может не требоваться.
OpenStart полезен, когда непонятно, какая сборка обслуживает сайт, проект зависит от старой CMS или расширений, либо обновление затрагивает формы, кабинет, оплату и интеграции. Мы можем начать с проверки окружения и совместимости, согласовать объём обновления и критерии приёмки. Описание текущей ситуации и ссылка на сайт помогут оценить следующий шаг; пароли в первичном обращении не нужны.
Регулярные обновления можно включить в техническую поддержку сайта. При работе с устаревшим кодом сначала имеет смысл определить границы поддержки PHP-проекта, а не обещать перенос всей системы одним переключением.
Источники
- PHP: сообщение о критических исправлениях от 21 октября 2026 года.
- CVE-2026-109618: официальный security advisory PHP.
- CVE-2026-109619: официальный security advisory PHP.