PHP2Shell на сервере с ispmanager и Ubuntu 20.04

21 октября 2026 года разработчики PHP выпустили экстренное обновление, закрывающее две критические уязвимости - CVE-2026-109618 и CVE-2026-109619 (CVSS v4.0 - 9.2, удалённое выполнение кода без авторизации). В сети их называют «PHP2Shell». Эксплойт опубликован почти одновременно с анонсом.

Кого касается

Уязвимость находится в самом интерпретаторе, в механизме session.upload_progress, а не в CMS или коде сайта. Уязвимы все версии начиная с PHP 5.4 в конфигурации по умолчанию - и mod_php, и PHP-FPM.

Атака идёт через запрос multipart/form-data, который PHP разбирает до того, как начинает выполняться код приложения. Поэтому:

• уязвим любой сайт на PHP, даже если в нём нет загрузки файлов и не используются сессии;
• защититься на уровне приложения (ini_set(), .user.ini, режим обслуживания CMS) нельзя.

Почему на Ubuntu 20.04 обновления недостаточно

ispmanager выпустил исправленные сборки isp-php* (7.4–8.5) - но только для Ubuntu 22.04, 24.04 и 26.04. Для Ubuntu 20.04 (focal) в репозитории остались мартовские сборки без исправления. apt upgrade пройдёт без ошибок, версия пакета может даже вырасти, но уязвимость останется.

Проверить можно по номеру сборки пакета и дате файла в репозитории ispmanager: исправленные сборки датированы 21 октября 2026.

Временная мера

Отключить session.upload_progress.enabled во всех php.ini на сервере - и в общих (для каждой установленной версии PHP), и в пользовательских, которые ispmanager создаёт для каждого пользователя. Настройка должна стоять именно в php.ini, а после изменения нужно перезапустить Apache и PHP-FPM.

Важно:

• это не исправление, а снижение риска - по данным исследователей, одной этой настройки недостаточно;
• ispmanager может перезаписать пользовательские php.ini при изменении настроек PHP через панель - после таких изменений настройку стоит перепроверить;
• дополнительно можно включить WAF или временно запретить multipart/form-data на уровне веб-сервера, но последнее сломает загрузку файлов на сайтах.

Обновление PHP

Исправленные версии от разработчиков PHP: 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Для 8.1 и старше официальных релизов нет - только минимальные патчи в исходниках для 7.4–8.1, для тех, кто собирает PHP сам.

Важно: в дистрибутивах исправление обычно бэкпортируют, и номер версии PHP (php -v) не меняется. Проверять нужно версию пакета или его changelog, а не вывод php -v.

Ubuntu / Debian (пакеты дистрибутива)

apt update
apt install --only-upgrade $(dpkg-query -W -f='${Package}\n' 'php[0-9]*' 'libapache2-mod-php*' 2>/dev/null)

Проверка - в changelog пакета должны упоминаться CVE:

zgrep -m2 -E 'CVE-2026-10961[89]' /usr/share/doc/php*-common/changelog.Debian.gz

Исправленные версии в Ubuntu (по данным Canonical):

Для 20.04 исправление приходит только через ESM. Ubuntu Pro бесплатен для личного использования (до 5 машин): pro attach <токен>, затем apt update && apt upgrade.

Если PHP стоит из репозитория Ondřej Surý (ppa:ondrej/php, packages.sury.org) - обновление делается так же через apt; по сообщениям, исправленные сборки для amd64 там уже вышли, для arm64 - с задержкой. Проверять стоит по версии: она должна быть не ниже исправленной для своей ветки.

RHEL / AlmaLinux / Rocky

dnf upgrade 'php*'
rpm -q --changelog php-common | grep -m2 -E 'CVE-2026-10961[89]'

Если пустой вывод - исправления в установленном пакете нет, нужно ждать сборку от дистрибутива или Remi.

ispmanager

ispmanager ставит свои сборки PHP в /opt/phpXX пакетами isp-phpXX, и они не обновляются вместе с системным PHP.

apt update
apt install --only-upgrade $(dpkg-query -W -f='${Package}\n' 'isp-php*')

Для RHEL-систем - yum update 'isp-php*'. Также можно через панель: «Конфигурация ПО» → «Обновить».

Проверка:

dpkg -l 'isp-php*' | awk '/^ii/{print $2, $3}'

Номер сборки - число после версии PHP, например 7.4.33-1782-ubuntu22. На момент написания исправленные сборки в репозитории ispmanager - 1782 от 21 октября 2026, и только для Ubuntu 22.04, 24.04 и 26.04. Сборка 1529 (март 2026) уязвима. Посмотреть, что лежит в репозитории, можно прямо в браузере: http://download.ispmanager.com/repo/ubuntu/pool/main/p/php74/ (вместо php74 - нужная версия).

После обновления

Работающие процессы продолжают использовать старый код, пока их не перезапустить:

systemctl restart apache2   # mod_php
systemctl list-units --type=service --no-legend | awk '{print $1}' | grep -E 'php.*fpm' | xargs -r systemctl restart

Сайты, работающие через CGI (в ispmanager - режим «CGI»), подхватывают новый бинарник со следующего запроса, перезапуск не нужен.

Варианты исправления

1. Ждать исправленную сборку для Ubuntu 20.04

Минимум работы, но неизвестно, выйдет ли сборка вообще. Ubuntu 20.04 уже вне стандартной поддержки, так что подобные ситуации будут повторяться.

2. Перевести сайты на системный PHP 7.4 с исправлением из Ubuntu Pro

Не проверено на практике. Canonical выпустил исправление для системного PHP 7.4 в Ubuntu 20.04 через ESM. Если сайты работают на isp-php74, их можно переключить в панели на «нативную» версию PHP 7.4 - это тот же PHP 7.4, но из пакетов Ubuntu. Нужно заранее проверить, что установлены все расширения, которые нужны сайту (пакеты php7.4-*), и что совпадают настройки php.ini. Подходит только для сайтов на 7.4; это способ выиграть время, а не замена обновлению ОС.

3. Обновить систему на месте до Ubuntu 22.04

У ispmanager есть инструкция для этого перехода, хотя сам он помечает её как экспериментальную. Исправленные сборки для 22.04 уже есть. Минусы: простой сайтов на время обновления и то, что стандартная поддержка 22.04 заканчивается в апреле 2027 - обновляться придётся снова.

4. Обновить систему на месте до Ubuntu 24.04

Два последовательных шага (20.04 → 22.04 → 24.04). Официально ispmanager обновление ОС не поддерживает, а для второго шага инструкции нет вовсе. Простой - от нескольких часов до дня, риск поломки панели и служб, откат только из снимка. Системный PHP сменится с 7.4 на 8.3, что может сломать сайты, которые работают на нём.

5. Перенести сайты на новый сервер с Ubuntu 24.04

У ispmanager есть штатный импорт пользователей с другого сервера и инструкция по переносу панели с лицензией. Новый сервер готовится и проверяется, пока старый работает. Простой - только на финальную синхронизацию данных (минуты), откат - возврат DNS. Минусы: больше времени по календарю, временно два сервера, смена IP-адреса.

Отдельная задача - не потерять данные (заказы, остатки и т.п.), которые появятся на старом сервере за время переноса, и не получить «раздвоение» базы, пока у посетителей обновляется DNS. Решается коротким окном обслуживания и проксированием со старого сервера на новый до переключения DNS.

Источники

• Sansec: PHP2Shell
• PHP 8 ChangeLog
• Ubuntu: php2shell vulnerability fixes available
• ispmanager: обновление Ubuntu 20.04 → 22.04 с ispmanager 6
• ispmanager: перенос ispmanager на новый сервер
• ispmanager: импорт данных

Статья будет пополняться конкретикой по мере проверки вариантов на практике.