PHP2Shell CVE-2026-109618 и 109619 в HestiaCP и ISPmanager: как закрыть все версии PHP на сервере

На 21 октября 2026 для панелей хостинга главное правило такое: обновляйте не «PHP», а каждую версию отдельно, потому что уязвимой остаётся любая ветка без исправления (8.1 и старше официального патча не имеют). Сначала инвентаризация версий и пулов FPM, затем обновление пакетов с перезапуском сервисов, затем меры в шаблонах панели, чтобы она их не затёрла. Заявления HestiaCP и ISPmanager по этим CVE на сегодня не подтверждены, проверьте у вендоров.

Что известно на 21 октября 2026 и почему панели хостинга — отдельная история

Коротко: 21 октября 2026 PHP выпустил исправления для двух критических уязвимостей, CVE-2026-109618 и CVE-2026-109619 (CVSS v4.0 — 9.2 по оценке PHP). Исправлены ветки 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Для PHP 8.1 и старше официального исправления нет, эти ветки закончили поддержку. Уязвимы mod_php, PHP-FPM, php-cgi и другие способы запуска, атака идёт по сети без аутентификации, а все известные триггеры используют запрос multipart/form-data. Подробный разбор «что делать в первый час» — в статье PHP2Shell CVE-2026-109618 и 109619: план на первый час. Здесь — только сервера с панелью, где одновременно живёт несколько версий PHP.

Почему это отдельная тема. На обычном сервере с одним сайтом вы обновляете один пакет и перезапускаете один сервис. Панель хостинга устроена иначе: у каждого клиента своя версия PHP (старый магазин на 7.4, новый сайт на 8.3, чей-то забытый проект на 5.6), у каждого сайта свой пул PHP-FPM, а конфигурация пулов генерируется панелью из шаблонов. Достаточно обновить php8.3 и решить, что вопрос закрыт, — а пулы на 7.4 и 8.1 продолжат работать уязвимыми. Именно поэтому здесь важнее всего инвентаризация: пока вы не знаете, какие версии стоят и кто на них сидит, вы не знаете масштаб.

Что в этой статье подтверждено, а что нет. Заявления самих вендоров панелей (HestiaCP, ISPmanager, cPanel, Plesk, FastPanel, VestaCP) по этим CVE на момент подготовки статьи мы не нашли: на 21 октября 2026 не подтверждено, проверьте у вендора на его официальной странице и в журнале изменений репозитория. Поэтому ниже описано не «вышло обновление такое-то», а что именно делать средствами системы и панели: как найти все версии и пулы, как обновить пакеты каждой версии, как закрепить меры так, чтобы панель их не затёрла, и как проверить всё скриптом. Пути и команды HestiaCP и ISPmanager сверены с их документацией; места, которые нам подтвердить не удалось, помечены словами «проверьте на своём сервере».

Шаг 1. Инвентаризация: какие версии PHP и какие пулы реально есть на сервере

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

Для Debian и Ubuntu (на них работает HestiaCP, а часто и ISPmanager) первый проход выглядит так: какие пакеты FPM установлены, какие сервисы запущены, какие мастер-процессы реально работают.

# установленные версии PHP-FPM
dpkg -l | awk '/^ii/ && $2 ~ /^php[0-9.]+-fpm$/ {print $2, $3}'
# каталоги конфигураций версий
ls -d /etc/php/*/
# запущенные сервисы FPM
systemctl list-units 'php*fpm*' --no-legend
# мастер-процессы (видно и то, что запущено не через systemd)
ps -eo pid,lstart,args | grep '[p]hp-fpm: master'
# все бинарники php в системе, включая /opt
find / -xdev -type f \( -name 'php' -o -name 'php-fpm*' -o -name 'php-cgi' \) -perm -u+x 2>/dev/null | grep -v '^/proc'

Второй вопрос — у кого какая версия. Пул — это файл с секцией в квадратных скобках, user, group и listen. Список пулов вместе с версией (она берётся из пути каталога) собирается одной командой.

for f in /etc/php/*/fpm/pool.d/*.conf; do
  v=${f#/etc/php/}; v=${v%%/*}
  printf '%s\t%s\t%s\t%s\n' "$v" "$(basename "$f")" \
    "$(grep -m1 -E '^\[' "$f")" "$(grep -m1 -E '^user *=' "$f" | tr -d ' ')"
done | column -t -s $'\t'

HestiaCP. В нём версию PHP выбирает шаблон бэкенда домена, поэтому у двух доменов одного пользователя версии могут отличаться. Список установленных в панели версий даёт v-list-sys-php, а добавляются они командой v-add-web-php VERSION (пример из документации — v-add-web-php 8.0). Какой шаблон бэкенда привязан к каждому домену, видно в v-list-web-domains USER json (поле с шаблоном бэкенда; точные имена полей проверьте на своей версии панели). Шаблоны пулов лежат в /usr/local/hestia/data/templates/web/php-fpm/, а имена по документации строятся по схеме ИМЯ-PHP-X_Y.tpl, где X_Y — версия, например YOURNAME-PHP-8_1.tpl. Файл пула домена обычно лежит в /etc/php/X.Y/fpm/pool.d/ и называется по домену — проверьте на своём сервере.

# версии, известные HestiaCP
v-list-sys-php
# какой шаблон бэкенда у доменов пользователя (JSON, дальше фильтруйте jq)
v-list-web-domains USER json
# переключить домен на другую версию (пример из документации)
v-change-web-domain-backend-tpl USER DOMAIN PHP-8_3

ISPmanager. Здесь, по документации вендора, помимо PHP из репозитория ОС («родного») панель умеет работать с альтернативными версиями из репозитория ispmanager: для режима «FastCGI (Nginx + PHP-FPM)» нужно включить соответствующую опцию, после чего версия становится доступной в настройках сайта или пользователя. Альтернативные версии живут в каталогах вида /opt/phpXY, а php.ini альтернативной версии — в /opt/<версия>/etc/php.ini. Пулы сайтов, по статье базы знаний ISPmanager, лежат в каталоге пулов выбранной версии: для альтернативной версии это путь вида /opt/php81/etc/php-fpm.d/pool.d/test.com.conf, для родной на Debian и Ubuntu — каталог /etc/php/<версия>/fpm/pool.d/. В примере статьи для Debian путь содержит повторяющийся pool.d, похожий на опечатку, поэтому реальный путь сверяйте командой find.

# альтернативные версии ISPmanager
ls -d /opt/php* 2>/dev/null
# пулы сайтов всех версий
find /etc/php /opt -path '*pool.d*' -name '*.conf' 2>/dev/null
# версия каждого найденного бинарника FPM
for b in $(find /opt /usr/sbin -name 'php-fpm*' -type f -perm -u+x 2>/dev/null); do echo "$b"; $b -v | head -1; done

Теперь про расхождения, которые мы специально ищем. Версия на домене и версия в командной строке — разные вещи: сайт может работать на PHP 8.2 через FPM, а cron-задача пользователя запускается через /usr/bin/php, то есть через системную альтернативу (update-alternatives --display php). Обновлять нужно обе линии. Отдельно ищем «осиротевшие» версии: пакеты php7.x-fpm, которые остались после переезда клиента, а сервис продолжает работать и слушать сокет. Если в ls /etc/php есть версия, на которую не ссылается ни один пул, её нужно либо удалить, либо хотя бы остановить.

Для cPanel, Plesk, FastPanel и VestaCP мы руководствуемся тем же принципом, а конкретные команды берём только из документации вендора, поэтому в статье не приводим то, что не смогли подтвердить. У cPanel есть официальная страница с описанием настроек PHP-FPM (docs.cpanel.net, раздел Configuration Values of PHP-FPM); по Plesk известно из его утилит, что пул сайта создаётся с тем же именем, что и сайт, и включает пользовательские настройки php.ini. Остальное — проверьте у вендора.

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

Шаг 2. Обновляем пакеты каждой версии и перезапускаем всё нужное

Порядок такой. Сначала смотрим, что вообще можно обновить, потом обновляем все версии разом, потом перезапускаем сервисы и проверяем, что в памяти не осталось старого кода. Версии исправленных пакетов зависят от репозитория: у Ubuntu 22.04 это php8.1 8.1.2-1ubuntu2.28, у 24.04 — php8.3 8.3.6-0ubuntu0.24.04.13, у Debian 12 — 8.2.35-1~deb12u1, у Debian 13 — 8.4.27-1~deb13u1. Полный перечень по дистрибутивам есть в статье про обновление PHP на Debian и Ubuntu через Sury и PPA, а для RPM-систем — в разборе про CentOS, RHEL, Alma и Remi, EOL.

Если версии на сервере ставятся из репозитория Sury, это нужно проверить, а не предполагать: apt-cache policy php7.4-fpm php8.1-fpm php8.3-fpm покажет источник и кандидата для каждой версии. Ондржей Сури заявил, что бэкпорты появятся для всех версий его репозитория (5.6–8.1), но на момент проверки подтверждения, что сборки для 7.4 и 8.1 уже вышли, не было. Если кандидат не изменился, а исправления для нужной версии нет, версия остаётся уязвимой, и дальше действует раздел о временных мерах.

apt update
# что обновится из пакетов php
apt list --upgradable 2>/dev/null | grep -E '^php'
# все установленные пакеты php всех версий, одной командой
apt install --only-upgrade $(dpkg -l 'php*' | awk '/^ii/ {print $2}')
# источник и кандидат по каждой версии
apt-cache policy php7.4-fpm php8.1-fpm php8.2-fpm php8.3-fpm php8.4-fpm

На Ubuntu 20.04 и старше исправления доступны только по подписке Ubuntu Pro (ESM): sudo pro fix CVE-2026-109618. На RHEL-семействе проверяем dnf updateinfo list --security | grep php и rpm -q --changelog php-fpm | head. У Remi 21 октября обновлений не ожидается, рекомендация — пакеты дистрибутива или сборка из исходников. Для альтернативных версий ISPmanager (каталоги /opt/phpXY) ставить исправление нужно тем способом, которым панель их поставила, то есть из репозитория ispmanager; наличие нужного обновления на 21 октября 2026 не подтверждено, проверьте на странице вендора и командой dnf check-update или apt list --upgradable по именам пакетов, которые покажет rpm -qa | grep -i php.

Теперь перезапуск, который чаще всего забывают. Обновлённый пакет не вытесняет из памяти уже запущенный мастер-процесс. Для каждой версии FPM перезапускаем свой сервис; если Apache работает в режиме mod_php, нужен именно restart, reload и graceful недостаточны. У ISPmanager на RHEL-семействе альтернативные версии называются по схеме php-fpm82.service, поэтому список сервисов берём из systemctl, а не из головы.

# перезапуск всех экземпляров FPM, какие есть в systemd
systemctl list-units --no-legend 'php*fpm*' | awk '{print $1}' | xargs -r -n1 systemctl restart
# mod_php
systemctl restart apache2   # httpd на RHEL
# проверка: нет ли процессов со старыми удалёнными библиотеками
sudo grep -lE ' /(usr|lib|opt).*\(deleted\)$' /proc/[0-9]*/maps
sudo needrestart -b -r l

Пустой вывод первой проверки означает, что запущенные процессы работают на новых файлах. Отдельно проверьте cron: задача, запущенная вчера и работающая до сих пор, тоже держит старый код. И учтите, что unattended-upgrades сам не перезапускает сервисы PHP, поэтому ночное автообновление без перезапуска ничего не защищает.

Шаг 3. Меры в пулах и шаблонах панели, которые она не затрёт

Меры из этого раздела временные и частичные, они не заменяют обновление. По разбору Patchstack и Sansec, к ним относятся: отключение session.upload_progress.enabled, выставление лимитов и, как осознанный компромисс, memory_limit = -1. Gina Peter Banyard из команды PHP прямо говорит, что одного отключения upload_progress мало и надёжной обходной меры нет, единственное исправление — патч. Для PHP 8.5 дополнительно предлагают fatal_error_backtraces=0. Поэтому мы используем меры как «мост» для версий, у которых исправления пока нет, и для окна между обнаружением и обновлением.

Почему в пул, а не в php.ini и не в .user.ini. Значения, заданные через php_admin_value и php_admin_flag, приложение не может переопределить через ini_set(), а .user.ini читается позже и для этой задачи не годится. Параметр session.upload_progress.enabled нужно задавать на уровне пула или серверной конфигурации, а затем перезапускать все воркеры. Строки в пул добавляются так:

php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 2M

Про memory_limit честно: значение -1 предложено Sansec, потому что триггер связан с исчерпанием лимита памяти, но один запрос получает возможность съесть всю память сервера. На сервере с десятками пулов без ограничений на уровне cgroup (например, через MemoryMax в override-файле сервиса) это опасно, следите за RAM и OOM-killer. Patchstack отдельно советует не использовать RLIMIT_AS и RLIMIT_DATA и держать post_max_size на уровне 8M, если загрузок нет, и 32M, если они есть.

HestiaCP: меры кладём в шаблон. Документация предупреждает: конфигурации доменов перезаписываются новыми шаблонами при пересборке пользователя или домена, после обновления панели, при запуске администратором и при изменении настроек пользователем. Править стандартные шаблоны не рекомендуется, их надо копировать. Поэтому для каждой версии создаём свою копию шаблона пула с именем по схеме ИМЯ-PHP-X_Y.tpl в /usr/local/hestia/data/templates/web/php-fpm/, добавляем в неё строки php_admin_*, привязываем домены к новому шаблону и пересобираем пользователя.

cd /usr/local/hestia/data/templates/web/php-fpm/
ls
# копия вместо правки оригинала (имя оригинала смотрите в ls)
cp PHP-8_3.tpl ITF-PHP-8_3.tpl
# после правки копии: привязать домен и пересобрать
v-change-web-domain-backend-tpl USER DOMAIN ITF-PHP-8_3
v-rebuild-user USER

Нюансы. Шаблон бэкенда в команде указывается без расширения .tpl (в примере документации — PHP-7_4). Копию шаблона сначала проверьте на тестовом домене: документация предупреждает, что ошибка в шаблоне может помешать перезагрузке или запуску служб, а значит, можно уронить все сайты разом. Если нужны индивидуальные настройки одного сайта, документация допускает .user.ini в public_html либо изменение конфигурации пула, но для мер безопасности .user.ini не подходит по описанной выше причине.

ISPmanager: по статье базы знаний вендора, умолчания для новых пулов PHP-FPM задаёт файл шаблона /usr/local/mgr5/etc/templates/fpm_site_pool.conf. Изменения в нём касаются только новых сайтов; уже существующие подхватят их после смены режима или версии PHP. Для существующих сайтов настройки правятся прямо в файле пула, после чего перезапускается соответствующий сервис FPM. Там же вендор предупреждает, что смена версии или обработчика перезаписывает конфигурации Nginx и Apache сайта и может нарушить его работу. Значит, меру нужно держать в шаблоне, а после любой смены версии пула вручную проверять, что строки на месте. Будет ли панель сохранять ваши правки в шаблоне при собственном обновлении, мы не подтверждали: проверьте после обновления панели и держите копию файла вне каталога панели.

# резервная копия шаблона ISPmanager вне каталога панели
cp -a /usr/local/mgr5/etc/templates/fpm_site_pool.conf /root/backup/fpm_site_pool.conf.$(date +%F)
# затем добавить в шаблон строки php_admin_* (см. выше) и перезапустить сервис пула

Для кого-то из клиентов вместо правки пулов проще временно закрыть multipart/form-data на уровне веб-сервера: в nginx if ($http_content_type ~* "multipart/form-data") { return 403; }, в Apache — условие RewriteCond %{HTTP:Content-Type} multipart/form-data [NC] и RewriteRule ^ - [F]. Это ломает загрузку файлов и часть форм (корзину и оформление заказа), поэтому после включения тестируйте заказ. На панели такой конфиг тоже надо класть в то место, откуда панель его не удалит, например в отдельный файл включения, который подключается шаблоном. Режимы обслуживания CMS не помогают: PHP разбирает запрос раньше кода приложения.

Шаг 4. Массовая проверка: один скрипт на все версии и все пулы

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

#!/bin/bash
# read-only проверка всех пулов PHP-FPM (Debian/Ubuntu)
echo '== версии бинарников =='
for b in /usr/sbin/php-fpm*; do [ -x "$b" ] && { echo -n "$b: "; $b -v | head -1; }; done
echo '== проверка синтаксиса =='
for b in /usr/sbin/php-fpm*; do [ -x "$b" ] && $b -t 2>&1 | tail -1; done
echo '== меры в пулах =='
for f in /etc/php/*/fpm/pool.d/*.conf; do
  v=${f#/etc/php/}; v=${v%%/*}
  up=$(grep -cE 'session\.upload_progress\.enabled\] *= *off' "$f")
  ml=$(grep -hE 'php_admin_value\[memory_limit\]' "$f" | tr -d ' ')
  echo "$v $(basename "$f") upload_progress_off=$up ${ml:-memory_limit=не задан в пуле}"
done
echo '== процессы со старым кодом =='
grep -lE ' /(usr|lib|opt).*\(deleted\)$' /proc/[0-9]*/maps 2>/dev/null

Что делаем с результатом. Если у пула в колонке upload_progress_off стоит 0 — мера не применена. Если версия бинарника старше исправленной для её ветки — обновляем. Если вывод последней секции не пустой — перезапускаем сервис. Для проверки по нескольким серверам прогоняем тот же скрипт через SSH и складываем вывод в общую таблицу: так видно и версии, и отстающие хосты. Для HestiaCP дополнительно сверяем список v-list-sys-php с реальным ls /etc/php, а для ISPmanager находим пулы и в /etc/php, и в /opt.

Для проверки по трафику ищем следы эксплуатации, о чём подробнее написано в разборе признаков взлома в логах nginx и Apache. Среди признаков, которые называет Patchstack: необычные multipart-запросы с последующей ошибкой memory_limit или повторяющимися ответами 500, аномально большие или битые куки PHPSESSID, необъяснимые перезапуски воркеров PHP. Это не доказательство ни в ту, ни в другую сторону, но повод остановиться. При признаках обновляем PHP, считаем сервер возможно скомпрометированным и передаём владельцу список ключей, паролей и токенов, которые на нём хранились, на ротацию; сами пароли живых учёток мы не меняем.

Ловушки, на которых мы чаще всего видим ошибки

Панель перезаписала конфиг. Самая частая история: админ вставил php_admin_flag в готовый файл пула, а через неделю пользователь сменил версию PHP на сайте, или администратор запустил v-rebuild-user, и мера исчезла. Лечение описано выше: правим шаблон, пулы правим после, а после каждой операции в панели прогоняем скрипт проверки.

Версия на домене и версия в CLI не совпадают. Сайт обновлён, но cron, скрипты синхронизации и Composer работают через /usr/bin/php другой версии. По обсуждениям на форуме HestiaCP, домены одного пользователя делят общую CLI-версию, поэтому командную строку проверяем отдельно: php -v, update-alternatives --display php.

Забытые старые версии. 5.6, 7.0–7.4, 8.0 и 8.1 уязвимы по определению: официального исправления для 8.1 и старше нет, а в Debian 11 LTS закончился 31 августа 2026. Мы смотрим не только в панель, но и на систему: пакеты php7.*-fpm и каталоги /opt/php*. Если клиенту нужна старая версия, это отдельный разговор о переезде приложения, а не о заплатках: Patchstack пишет, что минимальные бэкпорты для 7.4, 8.0 и 8.1 существуют только при сборке из исходников.

Конфликт при обновлении пакета. Если вы правили /etc/php/X.Y/fpm/php.ini или основные конфигурационные файлы вручную, apt спросит, какой файл оставить, и при неудачном ответе или в неинтерактивном режиме может перезаписать ваше значение или оставить старое. В автоматике используйте -o Dpkg::Options::=--force-confold и держите свои значения в пулах и отдельных файлах conf.d, а не в основном php.ini.

Обновление панели одновременно с PHP. Не совмещайте: если после обновления что-то перестало работать, вы не поймёте, виновата панель или пакет. Сначала PHP и перезапуск, потом проверка, потом любые операции с панелью.

Недокументированные правки форума. В обсуждениях HestiaCP встречаются советы по ручной правке файлов вроде upgrade.conf и v-run-cli-cmd для добавления новой версии PHP. Они неофициальные и могут слететь при обновлении панели. Новые версии добавляйте штатной командой v-add-web-php. Так же Patchstack предостерегает от «плагинов-заплаток» и сниппетов с форумов.

Контейнеры и встроенный PHP. NCSC советует инвентаризировать все PHP, включая встроенные в продукты. На сервере с панелью могут жить Docker-контейнеры с собственным PHP, которые панель не видит; их разбор — в статье про Docker-образы с PHP-FPM. А если на панели стоит 1С-Битрикс, смотрите отдельный разбор для Битрикса.

Как это выглядит на практике и что делать, если обновить нельзя

Мини-кейс, условный. Веб-студия «Пиксель-Фабрика» (9 рабочих мест) держит один VPS с панелью, на котором размещены сайты десяти заказчиков. Три сайта работают на PHP 8.3, четыре на 8.2, два на 8.1 и один, о котором все забыли, на 7.4. Админ студии обновил php8.3 и успокоился. Мы начинаем с инвентаризации (раздел выше), и сразу видны два пула на 8.1 и один на 7.4: для них официального исправления нет. Для 8.3 и 8.2 обновляем пакеты, перезапускаем FPM, проверяем needrestart и скриптом убеждаемся, что в шаблоне и в пулах стоят меры.

Для 8.1 и 7.4 решение принимает владелец, и мы называем ему варианты: перенос сайта на поддерживаемую ветку (8.2 или 8.3) после проверки совместимости, сборка исправленной версии из исходников с бэкпортом (трудоёмко и требует сопровождения) либо временная изоляция сайта. Пока выбор не сделан, ставим меры в пул и блокируем multipart/form-data на веб-сервере там, где на сайте нет загрузок и форм заказа. Если даже это невозможно, NCSC допускает крайнюю меру: рассмотреть отключение системы, предварительно проверив на следы компрометации.

Cloudflare. Он выкатил аварийные правила WAF во всех тарифах, включая бесплатный, но это лишь временная мера: она работает, только если сервер принимает трафик исключительно от Cloudflare. Прямое обращение по IP сервера обходит защиту. Sansec Shield RCE и утечку памяти не закрывает.

Если вы не хотите разбираться самостоятельно, мы берём это на себя в рамках услуги по обслуживанию серверов и сайтов: инвентаризация версий и пулов, обновление, перезапуск, внесение мер в шаблоны, повторная проверка и отчёт владельцу с перечнем того, что осталось уязвимым и почему. Если у вас установлены CMS, перейдите к статье про WordPress, Joomla, OpenCart и другие CMS — они не защищают вас сами по себе: Sansec подтвердил RCE без логина на WordPress, Joomla, Drupal, Magento, Roundcube, phpMyAdmin, Nextcloud и других при чистом коде приложения. Обновление плагинов проблему не решает, нужно обновлять PHP.

Частые вопросы