PHP2Shell на HestiaCP: как мы закрыли 50 версий PHP за ночь

21 октября 2026 года вышли исправления для PHP2Shell — двух критических уязвимостей в ядре PHP, которые позволяют выполнить чужой код на сервере без логина и пароля. Мы обслуживаем серверы с панелью HestiaCP, на которых одновременно стоят от двух до двенадцати версий PHP. За одну ночь мы пропатчили 50 установок PHP на шести серверах, и почти на каждом шаге «успешное» обновление могло оставить сервер уязвимым. Рассказываем, где подвох, и делимся скриптом, который всё это учитывает.

Что случилось

PHP2Shell — это CVE-2026-109618 и CVE-2026-109619. Одна ошибка связана с обработкой нехватки памяти, вторая — с состоянием, которое «зависает» между запросами одного рабочего процесса. Команда PHP оценила обе в 9.2 балла из 10 по CVSS 4.0 (ранние сообщения про 10.0 оказались ошибочными).

• Исправленные версии: 8.5.12, 8.4.27, 8.3.36 и 8.2.35.
• Ветки 7.4–8.1: официальных релизов нет, только исправления от поставщиков пакетов.
• Атаки: по данным watchTowr и Tenable, попытки эксплуатации идут, первые — ещё до публичного раскрытия. По оценке Palo Alto Networks, открытых установок PHP — более 22,6 млн.

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

Практически всех, у кого сайт работает на PHP: 1С-Битрикс, WordPress, MODX, самописные проекты. Источники расходятся в точных границах уязвимых версий, поэтому безопасно исходить из простого правила: уязвимы все версии до исправленных.

Особенно внимательными стоит быть владельцам VPS с панелями вроде HestiaCP. Панель позволяет держать на сервере несколько версий PHP, и за годы их накапливается много: под старый сайт поставили 5.6, под новый — 8.3, под тест — 8.4. Забытая версия с одним-единственным сайтом открывает весь сервер.

Что получилось у нас

Приятная неожиданность: в репозитории Ondřej Surý, откуда HestiaCP ставит PHP на Ubuntu, исправленные сборки пришли не только для свежих веток, но и для старых — вплоть до 5.6. Мы проверили это на своих серверах.

Подводные камни: «обновилось», а сервер уязвим

Это главное, ради чего мы пишем статью. Каждый пункт мы встретили сами, и каждый может оставить сервер уязвимым при формально успешном обновлении.

Как проверить и закрыть: порядок работы

1. Инвентаризация. Какие версии PHP стоят на сервере и сколько сайтов на каждой.
2. Проверка без изменений. Смотрим, какие версии уязвимы, — по changelog, а не по номеру версии.
3. Патч сначала на одном сервере. Проверяем сайты, и только потом обновляем остальные.
4. Поиск следов атаки за период до патча, начиная с 17 октября: падения воркеров PHP, веб-шеллы, новые задания cron и SSH-ключи.
5. Отдельный план для серверов без исправления: переезд или собственная сборка PHP.

Чтобы не делать всё это руками на каждом сервере, мы написали скрипт php2shell.sh и выложили его на GitHub. Он для Debian/Ubuntu с PHP от Surý — именно так PHP ставит HestiaCP, но панель не обязательна. Скрипт:

• проверяет исправление CVE для каждой версии PHP по changelog пакета;
• обновляет только уже установленные пакеты php* и hestia-php, не перезаписывая конфиги;
• останавливается, если репозиторий PHP не обновился, — вместо «успешного» обновления, которого не было;
• перезапускает php-fpm, Apache и панель;
• снимает ответы всех сайтов до и после и показывает, если что-то изменилось;
• пишет подробный лог в /var/log/php2shell/.

Пошаговая инструкция с командами и ответами на частые вопросы — в разделе советов: «Как закрыть PHP2Shell на HestiaCP».

Что делать, если патча нет

Если сервер работает на ОС без поддержки — например, CentOS 7, — исправленной сборки PHP для него нет ни у кого. Варианты:

• переезд на актуальную ОС (Rocky Linux или AlmaLinux 9, Debian, Ubuntu) — самый надёжный путь;
• собственная сборка PHP из исходников с патчем — требует квалификации и дальнейшей поддержки;
• коммерческая расширенная поддержка (ELS) для старой ОС.

Пока решения нет, стоит закрыть сайты на таком сервере фильтрацией трафика (WAF) и усилить наблюдение за логами. Это снижает риск, но не устраняет его.

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

Поможем закрыть уязвимость

Если не хотите разбираться сами, мы проверим ваш сервер, обновим все версии PHP, найдём следы атаки, если они есть, и подготовим план для серверов, которые обновить нельзя. А серверы на техподдержке мы закрываем сами, без участия клиента. Оставьте заявку — начнём с проверки сервера.