php2shell (CVE-2026-109618 / 109619) не определить через php -v: где номера версий расходятся в FPM, Docker и дистрибутивах

Если PHP, который обрабатывает веб-запросы (PHP-FPM, mod_php в Apache, php-cgi, FrankenPHP, LiteSpeed), старше 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12, он подвержен уязвимостям CVE-2026-109618 и CVE-2026-109619, известным как php2shell. Исправление — обновиться до одной из этих версий (а для пакетов дистрибутива — до исправленного пакета) и перезапустить процессы. Проверять нужно не локальный php -v, а «PHP, который реально обслуживает веб» и «версию установленного пакета».

В статье разобраны четыре места, где суждение только по номеру версии приводит к неверному выводу. Все цифры и статусы приведены по состоянию на 2026-10-22, источники по каждому пункту перечислены в конце.

Что известно на 2026-10-22

В бюллетене PHP сказано, что «единственное полное исправление — обновление». Меры смягчения на период до обновления описаны ниже.

Ловушка 1: php -v и веб-PHP могут быть разными

php -v, набранный по SSH, показывает версию PHP для CLI. Веб-запросы обрабатывают процессы PHP-FPM или mod_php, загруженный в Apache, — это отдельные бинарные файлы и отдельные пакеты. Если новый PHP установлен только для CLI, если рядом стоит несколько версий или пул FPM указывает на другую версию, веб-сторона может остаться старой, даже когда php -v показывает исправленную версию.

Увидеть реальную версию на веб-стороне можно несколькими способами.

# FPM в Debian / Ubuntu (имя зависит от версии)
php-fpm8.3 -v

# FPM в семействе RHEL
php-fpm -v

# Проверить, загружен ли mod_php в Apache
apachectl -M | grep -i php

Надёжнее всего заставить PHP, который реально выполняется через веб, сообщить свою версию. Разместите временный файл с трудно угадываемым именем и удалите его сразу после проверки.

<?php echo PHP_VERSION, ' ', PHP_SAPI;

Если PHP_SAPI равен fpm-fcgi, PHP работает под FPM; apache2handler означает mod_php; cgi-fcgi — CGI. Не оставляйте phpinfo() открытым: это само по себе раскрывает информацию.

Перезапуск — ещё один легко упускаемый шаг. Даже после замены пакета уже запущенные процессы php-fpm или Apache могут продолжать работать на старом коде. В одних конфигурациях перезапуск при обновлении пакета происходит автоматически, в других — нет. После обновления перезапустите FPM / Apache и ещё раз проверьте версию на веб-стороне описанными выше способами.

Ловушка 2: в Docker по названию тега судить нельзя

У официального образа php есть «плавающие теги», например 8.3 и 8.3-fpm, содержимое которых заменяется, и закреплённые теги, например 8.3.30, фиксирующие версию.

• Даже если плавающий тег на Docker Hub переключён на исправленную версию, ваша локальная копия остаётся старым образом, пока вы не сделаете pull заново. Запущенные контейнеры тоже продолжают работать на старом образе, пока их не пересоздадут. Dockerfile с FROM php:8.3-fpm по-прежнему соберётся на старой базе, если она осталась в кеше сборки.
• Закреплённый тег остаётся старым навсегда, пока вы сами не поменяете номер.

Опубликованы ли теги с исправленными версиями, можно проверить через API Docker Hub.

curl -s "https://hub.docker.com/v2/repositories/library/php/tags?name=8.3.36&page_size=100"

Результаты запроса по четырём линейкам релизов на 2026-10-22 (время в UTC).

Эта проверка выявила три места, где суждение по номерам может ввести в заблуждение.

1. «Недавно обновлён» не значит «исправлен». Закреплённый тег 8.3.35 был пересобран в течение 2026-10-21, но PHP_VERSION внутри по-прежнему был 8.3.35. Смотрите на версию внутри образа, а не на время обновления.
2. Разные digest могут скрывать одинаковое содержимое. У 8.3 и 8.3.36 были разные digest тегов (значение мультиархитектурного индекса), но образ для amd64 был идентичным, и в обоих было PHP_VERSION=8.3.36. Так же для 8.3-fpm / 8.3.36-fpm, 8.4-apache / 8.4.27-apache, latest / 8.5.12, 8.5-fpm и 8.2-fpm значение PHP_VERSION в образе amd64 было исправленным.
3. Исправленных официальных образов для 8.1 и старше нет. Последнее обновление 8.1-fpm — 2025-12-31.

Проверка локальных образов и запущенных контейнеров:

# Версия PHP в локально загруженном образе
docker image inspect php:8.3-fpm --format '{{range .Config.Env}}{{println .}}{{end}}' | grep PHP_VERSION

# Загрузить заново и пересоздать контейнеры
docker compose pull
docker compose up -d

# Если вы собираете свой образ, обновите базовый образ и затем выполните сборку
docker compose build --pull

# Версия внутри запущенного контейнера
docker compose exec app php -r 'echo PHP_VERSION, PHP_EOL;'

Замените app в последней команде на имя своего сервиса. Каждый официальный образ собирается с единственным PHP_VERSION, поэтому версия CLI внутри контейнера совпадает с версией FPM / Apache в этом контейнере (ловушка 1 относится к случаю, когда PHP установлен прямо на хосте).

FrankenPHP встраивает PHP, поэтому версия FrankenPHP и версия встроенного PHP — это разные номера. В примечаниях к выпуску FrankenPHP 1.13.2 от 2026-10-21 сказано, что образы Docker собраны с PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12, а статические бинарные файлы — с PHP 8.5.12.

Ловушка 3: пакеты дистрибутивов «исправлены под старыми номерами»

Ubuntu и RHEL переносят в старые версии только исправления (бэкпорты). Номер, который показывает php -v, остаётся старым, поэтому числовая проверка вроде «меньше 8.3.36, значит уязвим» пометит уже исправленную систему как уязвимую. И наоборот, успокаиваться по номеру тоже нельзя. Выводы делайте по версии пакета и трекеру безопасности своего дистрибутива.

Исправленные пакеты, указанные в трекерах по состоянию на 2026-10-22 (одинаково для обоих CVE):

Эта таблица прямо показывает, почему одних номеров недостаточно. Исправленный PHP в Ubuntu 24.04 — это версия, начинающаяся с 8.3.6, намного ниже апстримной 8.3.36. PHP по умолчанию в RHEL 9 исправлен, оставаясь на 8.0.30, хотя апстрим больше не выпускает исправления для 8.0. Debian перешёл на те же номера, что и апстрим (8.2.35 / 8.4.27).

Некоторые пакеты ещё не исправлены (по состоянию на 2026-10-22).

• Модуль php 8.4 в RHEL 9 помечен как «затронут, исправления нет».
• В Debian forky (testing) php8.4 8.4.26-1 помечен как «vulnerable». php8.4 в sid (unstable) — 8.4.27-1, он исправлен.

Примеры команд для проверки собственного сервера:

# Debian / Ubuntu: установленная и доступная версии
apt-cache policy php8.3-fpm libapache2-mod-php8.3

# Ubuntu: исправлена ли эта CVE на данном сервере
pro fix CVE-2026-109618
pro fix CVE-2026-109619

# Семейство RHEL: есть ли обновление, исправляющее эту CVE, и установленная версия
dnf updateinfo list --cve CVE-2026-109618
rpm -q php-fpm php-cli

Подставьте имя пакета (php8.3-fpm и т. д.) под свою среду. Сравните показанную версию с «исправленной версией» в таблице выше или в трекере; если она такая же или выше, исправление установлено. Затем выполните перезапуск и проверку веб-стороны, описанные в ловушке 1.

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

Ловушка 4: на виртуальном хостинге и в управляемых средах PHP самому не обновить

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

Самостоятельно можно сделать три вещи.

1. Проверьте версию на веб-стороне. С помощью временного файла из ловушки 1 выведите PHP_VERSION и PHP_SAPI, затем сразу удалите его. Если в панели управления есть выбор версии PHP, отметьте и выбранную там версию.
2. Прочитайте уведомление провайдера, а если его нет — спросите. Вопрос: «Для каких версий PHP на моём тарифе и когда будут применены (или уже применены) исправления CVE-2026-109618 и CVE-2026-109619?» Если спрашивать по номеру CVE, а не по номеру версии, ответ учтёт и бэкпорты.
3. Если выбрана версия без поддержки, обновитесь. Проект PHP не выпускает исправлений для 8.1 и старше, а поддержка 8.2 заканчивается 2026-12-31. Если провайдер не сделал бэкпорты исправлений, надёжный путь — сменить версию.

Статус по хостинг-провайдерам (на 2026-10-22)

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

В таблице ниже приведено только то, что написано на официальных страницах провайдеров (объявления и информация о техработах), с пересказом формулировок уведомлений. Уведомления обновляются по ходу работ, поэтому фактический статус всегда сверяйте на указанной официальной странице.

Там, где я не смог найти или открыть официальное уведомление, в таблице написано «не удалось подтвердить» или «не нашёл». Отсутствие информации там не означает, что провайдер не отреагировал. Уточняйте напрямую в объявлениях и поддержке своего провайдера.

Меры смягчения, пока нельзя сразу обновиться

В бюллетене PHP перечислены настройки, уменьшающие поверхность атаки до обновления. Однако сам бюллетень прямо указывает, что они «не делают вас защищёнными». Основные из них:

• Для CVE-2026-109619: задайте session.upload_progress.enabled=0 в php.ini, в пуле FPM или в конфигурации сервера и перезапустите все рабочие процессы (ini_set() и .user.ini в FPM для этого не работают). В PHP 8.5 также задайте fatal_error_backtraces=0.
• Для CVE-2026-109618: задайте memory_limit=-1 так, чтобы приложение не могло это переопределить, и уменьшите post_max_size (8M, если загрузок нет, и 32M, если есть). Не используйте RLIMIT_AS / RLIMIT_DATA вместо этого.

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

Источники (проверено 2026-10-22)

• php.net: Security advisory: Critical remote code execution vulnerabilities, update now (2026-10-21)
• php.net: Upcoming Critical PHP Security Release (2026-10-20)
• php.net: анонсы выпусков PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
• GitHub: GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GitHub: GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• Docker Hub: официальный образ php
• Примечания к выпуску FrankenPHP 1.13.2
• Debian Security Tracker: CVE-2026-109618 / CVE-2026-109619
• Ubuntu: CVE-2026-109618 / CVE-2026-109619 / USN-8948-1 / USN-8948-2
• Red Hat: CVE-2026-109618 / CVE-2026-109619 (версии исправленных пакетов — из данных VEX Red Hat)
• NCSC: Critical security issue affecting PHP