21 октября разработчики PHP выпустили исправления для двух критических уязвимостей — CVE-2026-109618 и CVE-2026-109619, известных как PHP2Shell. Обе затрагивают сам интерпретатор PHP и при определенных условиях позволяют выполнить код на сервере без авторизации. Для атаки необязательно находить ошибку в WordPress, Laravel или другом приложении, так как проблема находится уровнем ниже.

О механике этих уязвимостей уже достаточно написано. Мы сосредоточимся на обновлении работающего сервера: что проверить до установки патча, как обновить PHP через ispmanager или пакетный менеджер Linux и убедиться, что исправленная версия действительно обслуживает сайт.

Заодно разберем, как использовать WAF для дополнительной защиты, пока обновление готовится или проверяется.

Навигация по тексту:

• Какие версии PHP нужно обновить

• Перед обновлением: проверяем окружение и готовим откат

• Обновляем PHP через ispmanager

• Обновляем PHP без панели управления

• Подключаем дополнительную защиту через WAF

• Что делать, если исправленного пакета пока нет

• Как убедиться, что обновление прошло успешно

• Итоговый чек-лист для администратора

21 октября вышли исправления для четырех поддерживаемых веток:

PHP 8.1 и более старые версии уже не поддерживаются основным проектом PHP. Для веток 7.4, 8.0 и 8.1 разработчики опубликовали минимальные исправления исходного кода, но не полноценные новые релизы. При этом сопровождающие Linux-дистрибутивы могут включать исправления в собственные пакеты.

Здесь важно различать версию PHP из официального релиза и версию пакета операционной системы. Например, для Ubuntu 24.04 LTS исправления PHP2Shell входят в пакет 8.3.6-0ubuntu0.24.04.13, хотя официальный исправленный релиз PHP 8.3 имеет номер 8.3.36. Поэтому проверять нужно не только номер интерпретатора, но и сведения об исправлениях от поставщика пакета.

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

Для первичной проверки подключитесь по SSH и выполните:

php -v

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

Посмотреть запущенные PHP-FPM и веб-серверы можно так:

ps -eo pid,args | grep -E '[p]hp-fpm|[a]pache2|[h]ttpd'

Для серверов с systemd также полезно проверить активные службы:

systemctl list-units --type=service --all | grep -E 'php.*fpm|apache2|httpd'

В ispmanager дополнительно проверьте версию PHP, назначенную каждому сайту, и режим его работы: модуль Apache, CGI, PHP-FPM или другой обработчик. 

Перед установкой исправления нужно подготовить:

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

• Список зависимостей. Зафиксируйте версию PHP, активные расширения, конфигурацию PHP-FPM, CMS, плагины и используемые библиотеки.

• План проверки. Определите несколько критичных пользовательских сценариев: вход в личный кабинет, оформление заказа, отправка форм, загрузка файлов, работу API и фоновых задач.

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

Если обновление затрагивает только патч-релиз текущей поддерживаемой ветки, объем изменений обычно меньше, чем при переходе с PHP 7.4 на PHP 8.4. Но даже патч-релиз стоит проверить на staging, если такая возможность есть.

Важно: резервная копия помогает восстановить данные после неудачного обновления. Однако возвращать уязвимую сборку PHP в публичный production без временного ограничения доступа небезопасно.

Если на сервере используется ispmanager, начать можно с интерфейса панели.

Откройте «Конфигурация ПО», нажмите «Обновить» и отметьте параметры «Обновить список доступного ПО» и «Обновить ПО».

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

Если используете несколько альтернативных PHP, проверьте наличие исправлений для каждой установленной версии, обслуживающей веб-запросы.

В ispmanager альтернативные версии PHP могут поставляться отдельными пакетами. Например, isp-php82 — имя пакета PHP 8.2, а не команда, которую нужно самостоятельно запускать в терминале.

Для адресного обновления через SSH используйте пакетный менеджер своей ОС. Например, в Debian-подобной системе можно предварительно проверить наличие обновления пакетов isp-php82 и связанных с ним компонентов, а затем установить исправленную сборку из подключенного репозитория.

В RHEL-подобных системах аналогичные операции выполняются через dnf или yum.

Конкретная команда зависит от того, какие пакеты установлены на сервере. Не стоит копировать название isp-php82 из инструкции, если сайт работает на другой версии или PHP установлен из другого репозитория.

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

Обновленный PHP должен начать обслуживать новые запросы. Для этого необходимо перезапустить соответствующие процессы.

В зависимости от конфигурации сервера это могут быть:

• apache2 — для Debian/Ubuntu;

• httpd — для RHEL-подобных систем;

• php-fpm, php8.2-fpm, php-fpm82 и другие службы PHP-FPM — в зависимости от версии и способа установки.

В ispmanager это можно сделать через раздел управления службами.

Не нужно перезапускать все службы подряд. Сначала определите, какие обработчики обслуживают обновленные сайты.

Также проверьте длительно работающие фоновые процессы, например обработчики очередей. Если они используют PHP, их может потребоваться перезапустить отдельно.

На сервере без ispmanager обновление выполняется штатным пакетным менеджером операционной системы.

Сначала обновите сведения о доступных пакетах:

sudo apt update

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

apt list --upgradable 2>/dev/null | grep -i php

Если исправленные пакеты опубликованы в подключенных репозиториях, установите их. Для стандартного системного обновления используется:

sudo apt upgrade

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

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

В Debian доступность исправлений может различаться между релизами и репозиториями. Если пакет всё ещё помечен как уязвимый, сам запуск apt upgrade проблему не решит. Проверьте трекер безопасности Debian.

Проверить доступные обновления можно с помощью:

sudo dnf check-update

Для установки исправлений системных PHP-пакетов, если они доступны в подключенных репозиториях:

sudo dnf upgrade 'php*'

На системах, где используется yum, применяется соответствующая команда yum update.

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

Например, на Ubuntu с PHP 8.3 служба обычно называется php8.3-fpm:

sudo systemctl restart php8.3-fpm

sudo systemctl status php8.3-fpm --no-pager

Если используется Apache с mod_php, перезапускают Apache:

sudo systemctl restart apache2

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

Если PHP работает в Docker, обновление интерпретатора на хостовой ОС не исправит PHP внутри контейнера. Потребуется обновить базовый образ, пересобрать приложение и развернуть новые контейнеры.

Пока вы устанавливаете и проверяете обновления, можно дополнительно защитить сайт с помощью фильтрации HTTP-трафика перед приложением. Еще это актуально, если не получается оперативно поставить исправленную версию PHP: WAF поможет блокировать известные попытки эксплуатации уязвимости до того, как запросы достигнут сайта.

В облачном WAF Рег.облака мы добавили специальное правило для блокировки известных попыток эксплуатации PHP2Shell.

Для новых приложений, которые подключаются к защите, рекомендуем использовать «Базовый профиль безопасности». В нем предусмотрены блокирующие правила для известных векторов эксплуатации веб-уязвимостей.

Для приложений с ранее созданными собственными профилями безопасности правило PHP2Shell также добавлено в режиме «Блокировка». 

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

Подключить облачный WAF Рег.облака можно в личном кабинете. Сервис доступен для бесплатного тестирования.

После подключения важно проверить сетевую схему. Если исходный сервер продолжает принимать HTTP- и HTTPS-запросы напрямую, атакующий сможет обойти WAF, обращаясь к публичному IP сервера.

Для серверов, весь публичный веб-трафик которых должен проходить через WAF, доступ к портам 80/443 следует ограничить доверенными IP-адресами WAF. Перед применением правил проверьте список адресов, IPv4/IPv6, служебные проверки доступности и возможные дополнительные маршруты трафика.

Настраивать ограничения лучше последовательно: сначала убедиться, что сайт корректно работает через WAF, затем закрыть прямой доступ и проверить его отсутствие извне. Отдельно протестируйте авторизацию, загрузку файлов, формы и API. Даже подходящее защитное правило может потребовать настройки под особенности приложения. Важно понимать, что WAF не устраняет уязвимости PHP. Он помогает блокировать известные варианты атак на уровне HTTP, но не исправляет ошибки внутри runtime и не гарантирует защиту от всех способов эксплуатации.

Такая ситуация возможна на старых ОС, неподдерживаемых ветках PHP или при использовании отдельных сборок из сторонних репозиториев.

Сначала проверьте, не выпустил ли поставщик дистрибутива исправленный пакет с перенесенным патчем. Сравнение только с номерами официальных PHP-релизов здесь недостаточно.

Если патч недоступен, можно временно ограничить некоторые известные способы эксплуатации. В официальных рекомендациях PHP, например, рассматривается отключение session.upload_progress.enabled. Но эта настройка блокирует не все варианты атак и требует применения на уровне конфигурации PHP или PHP-FPM с последующим перезапуском обработчиков.

Другой вариант — ограничить обработку multipart/form-data на уровне веб-сервера. Он требует осторожности: могут перестать работать загрузка файлов и формы, использующие этот формат. Подробнее временные меры описаны в материале OpenNET.

Такие ограничения нельзя считать полноценным исправлением. Для критичных сервисов, которые невозможно обновить, стоит также рассмотреть временное ограничение внешнего доступа до установки безопасной сборки.

Если используется PHP 7.4, 8.0 или 8.1, одновременно нужно подготовить план перехода на поддерживаемую версию. Перед сменой ветки проверьте совместимость CMS, плагинов, Composer-зависимостей, расширений и собственного кода.

Ответ пакетного менеджера «обновлено» — только первый этап проверки.

Версия и источник PHP. Убедитесь, что сайт обслуживает исправленный интерпретатор. Если используется сборка с backport, проверьте ее по бюллетеню безопасности поставщика. Не ограничивайтесь php -v, если консольный PHP отличается от веб-обработчика.

Состояние служб. Проверьте, что соответствующие PHP-FPM-пулы или веб-серверы перезапущены, а в журналах нет ошибок загрузки расширений и запуска новых процессов.

Пользовательские сценарии. Пройдите несколько критичных операций: авторизацию, отправку форм, загрузку файлов, API-запросы, оформление заказа. Проверьте фоновые задачи, если они используют тот же PHP.

Журналы ошибок. Посмотрите логи приложения, PHP-FPM и веб-сервера. Особое внимание — ошибкам совместимости, отсутствующим расширениям, изменениям параметров PHP и проблемам с подключением к базе данных.

WAF и сетевой доступ. Если подключена фильтрация, проверьте журнал событий, блокировку тестовых нежелательных запросов в рамках согласованной проверки и отсутствие прямого публичного доступа к origin-серверу.

Результат обновления. Зафиксируйте, какую сборку PHP использует каждый сайт, какие пакеты обновлены и кто отвечает за последующее сопровождение. Если на сервере несколько сайтов и версий PHP, такую инвентаризацию полезно сохранить для следующих обновлений.

• Проверены все версии PHP, реально обслуживающие сайты.

• Найдены используемые PHP-FPM-пулы, модули Apache и контейнеры.

• Подготовлены резервные копии файлов, базы данных и конфигурации.

• Проверена доступность исправленных пакетов в используемых репозиториях.

• Установлены исправления PHP2Shell.

• Перезапущены нужные службы и фоновые PHP-процессы.

• Подтверждено, что веб-приложение использует исправленную сборку.

• Проверены ключевые функции сайта и журналы ошибок.

• При использовании WAF проверены профиль, режим блокировки и маршрут трафика.

• Для неподдерживаемых версий подготовлен план перехода на актуальную ветку PHP.

PHP2Shell затрагивает интерпретатор, поэтому обновить только CMS или плагины недостаточно. Если сайт остается на PHP, важно установить исправления именно в той среде, где обрабатываются HTTP-запросы, и проверить работу приложения после перезапуска. WAF можно использовать для дополнительной фильтрации трафика, в том числе на время обновления. Но закрывает PHP2Shell именно исправленная сборка PHP.