Как обновить PHP после PHP2Shell: закрываем RCE-уязвимости CVE-2026-109618 и CVE-2026-109619

PHP2Shell — две критические уязвимости (CVE-2026-109618 и CVE-2026-109619) в среде выполнения PHP: они позволяют неавторизованному злоумышленнику удалённо выполнять код. Исправления вышли 21 октября 2026 года в 14:00 UTC. Чтобы закрыть уязвимости, обновите PHP до 8.5.12, 8.4.27, 8.3.36 или 8.2.35 (либо до исправленного пакета вашего дистрибутива) и перезапустите процессы. После этого проверьте сервер на следы компрометации: первые попытки эксплуатации уже зафиксированы.

Модель угроз

Для эксплуатации CVE-2026-109618 и CVE-2026-109619 не нужна авторизация. Достаточно, чтобы уязвимый PHP обрабатывал запросы, пришедшие извне. Успешная атака даёт выполнение произвольного кода в веб-окружении, то есть с правами процесса, который обслуживает PHP.

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

Угрозы и уровень их реальности

CVE-2026-109618 и CVE-2026-109619 (PHP2Shell): удалённое выполнение кода без аутентификации (Remote Code Execution, RCE). Уровень реальности: зафиксированы первые попытки эксплуатации. О масштабе кампаний, используемых индикаторах и публичных эксплойтах в исследованных материалах данных нет, поэтому мы не оцениваем их.

Вторичное закрепление: если сервер был атакован до обновления, на нём могли остаться веб-шеллы и другие следы. Обновление PHP их не удаляет. Это следствие того, как работает патч, а не подтверждённый факт о конкретных случаях.

Что понадобится

• Доступ администратора (root или sudo) к своим серверам и панели хостинга.
• Список всех сред, где работает PHP: продакшен, тест (staging), контейнеры, образы и раннеры CI, панели хостинга.
• Резервные копии кода, базы данных и конфигурации перед обновлением, а также план отката.
• Окно обслуживания: перезапуск PHP-FPM или Apache прервёт текущие запросы.

Шаг 1. Определите, какие из ваших систем затронуты

Составьте инвентаризацию всех PHP на узле: на одном сервере часто стоит несколько версий. Начните с версии CLI:

php -v
# версия CLI; она может отличаться от версии, под которой работает сайт

Версия CLI не показывает, какой PHP обслуживает сайт. Определите режим запуска. Для Apache проверьте, подключён ли mod_php:

sudo apache2ctl -M 2>/dev/null | grep -i php || sudo httpd -M 2>/dev/null | grep -i php
# если вывод содержит php_module (или phpN_module), используется mod_php: это самый рискованный вариант

Для PHP-FPM найдите исполняемый файл работающего мастер-процесса и спросите версию именно у него:

for p in $(pgrep -f 'php-fpm: master'); do sudo readlink -f /proc/$p/exe; done
# выводит путь к бинарному файлу каждого запущенного пула PHP-FPM; затем выполните: <путь> -v

Сверьте результат с установленными пакетами: dpkg -l | grep -i php (Debian/Ubuntu) или rpm -qa | grep -i php (RHEL-подобные системы). Не создавайте для проверки публичный скрипт с phpinfo() или PHP_VERSION: пока файл существует, его может запросить любой посетитель сайта. Если без такого скрипта не обойтись, заранее ограничьте доступ к нему на уровне веб-сервера только локальным адресом, а после теста удалите файл и убедитесь, что он исчез.

Затем найдите забытые установки: другие версии PHP на том же сервере, Docker-образы, старые виртуальные хосты, CI-раннеры. Расставьте приоритеты: сначала серверы, доступные из интернета, и все узлы с mod_php. Общие подходы к проверке сайта описаны в материале о том, как проверить безопасность своего web-сайта.

Шаг 2. Обновите PHP до исправленной версии

Цель — исправленная сборка вашей ветки: 8.5.12, 8.4.27, 8.3.36 или 8.2.35. Обновляйтесь внутри своей ветки, чтобы снизить риск несовместимости.

Учтите: дистрибутивы нумеруют пакеты по-своему и могут выпускать исправление как backport, без совпадения с номером upstream-релиза. Поэтому сверяйте номер пакета с бюллетенем безопасности именно вашего выпуска дистрибутива или репозитория, а не с номерами выше.

Debian и Ubuntu — обновите все установленные пакеты PHP, а не только основные:

sudo apt update
sudo apt install --only-upgrade $(dpkg -l | awk '/^ii +php/ {print $2}')
# обновляет только уже установленные пакеты PHP из подключённых репозиториев

RHEL, AlmaLinux, Rocky Linux (и репозиторий Remi, если он у вас подключён):

sudo dnf upgrade 'php*'
# обновляет установленные пакеты PHP до версий из ваших репозиториев

После обновления проверьте фактическую версию пакета и бинарного файла активного SAPI, как в шаге 1.

Контейнеры: недостаточно перезапустить существующий контейнер. Сначала обновите в Dockerfile базовый образ до исправленной сборки; если образ или пакеты закреплены по тегу, версии или digest, обновите и эти закрепления. Флаг --no-cache отключает только кеш сборки, а свежий базовый образ подтягивает --pull:

docker compose build --pull --no-cache app
docker compose up -d --force-recreate app
docker compose exec app php -v
# пересобирает образ со свежей базой, пересоздаёт контейнер и проверяет версию PHP внутри нового образа

systemctl list-units 'php*fpm*' --type=service
sudo systemctl restart php8.3-fpm   # имя службы возьмите из списка выше
sudo systemctl restart apache2      # для mod_php; в RHEL-подобных системах — httpd
# перезапускает процессы, чтобы они загрузили обновлённые файлы

Shared-хостинг: доступа к пакетным менеджерам нет. Проверьте селектор версии PHP в панели управления (cPanel, ISPmanager, FastPanel) и переключите сайт на исправленный релиз. Если его в списке нет, обратитесь в поддержку провайдера и запросите статус исправления CVE-2026-109618 и CVE-2026-109619.

Шаг 3. Обновите зависимости и проверьте совместимость

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

php -m
# выводит список загруженных модулей PHP (для CLI; у веб-SAPI набор может отличаться)

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

sudo journalctl -u php8.3-fpm -n 50
# последние записи журнала службы PHP-FPM

Если приложение не работает на исправленной сборке своей ветки, проверьте совместимость на тестовом контуре и составьте план миграции. Если вы используете ветку, которой нет в списке исправленных (8.5, 8.4, 8.3, 8.2), сверьтесь с бюллетенем безопасности поставщика вашей сборки: в исследованных материалах для таких версий исправления не указаны, а затронутость не подтверждена.

Шаг 4. Поищите следы компрометации на своём сервере

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

Начните с журналов веб-сервера за весь период, пока уязвимый сервер был доступен из сети (команда захватывает и ротированные архивы):

sudo zgrep -Ei 'session|multipart|upload' /var/log/nginx/access.log*
# выбирает запросы к загрузкам и сессиям; совпадения не означают взлом, а их отсутствие не доказывает чистоту

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

sudo find /var/www/example.com -type f -name '*.ph*' -mtime -30 -ls
sudo -u www-data find /var/www -type d -writable
# первая команда ищет PHP-файлы, изменённые за 30 дней; вторая — каталоги, куда может писать веб-пользователь

Сверьте код с доверенным эталоном: чистым релизом или артефактом сборки.

cd /var/www/example.com && git status --porcelain
# показывает отличия от локального HEAD; сам HEAD мог быть изменён, поэтому сравнение с доверенным источником надёжнее

Проверьте установленные соединения и процессы. Исходящие соединения процессов PHP или веб-сервера на неизвестные внешние адреса могут говорить о reverse shell или вредоносном боте. Часть соединений легитимна (например, к базе данных), поэтому сопоставляйте адреса с вашей схемой сети. Учтите, что для вывода процессов нужны права root.

sudo ss -tpn state established | grep -E 'php|apache|httpd|nginx'
# показывает установленные TCP-соединения процессов веб-стека с PID

Проверьте планировщик и учётные записи: задания cron и новых пользователей. Подробнее о том, как развивается атака после первичного проникновения, см. материал о методике взлома крупных компаний через web.

sudo crontab -u www-data -l
ls -la /etc/cron.d /etc/crontab
awk -F: '$3 >= 1000 {print $1}' /etc/passwd
# показывает задания пользователя веб-сервера, системные задания и обычные учётные записи

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

Проверка результата

• Пакет и бинарный файл активного SAPI (php-fpm -v по найденному пути, модуль Apache) показывают исправленную сборку вашей ветки: 8.5.12, 8.4.27, 8.3.36 или 8.2.35 либо пакет из бюллетеня дистрибутива.
• Процессы перезапущены после обновления. Проверьте время запуска: ps -eo pid,lstart,args | grep -E '[p]hp-fpm|[a]pache2|[h]ttpd'. Если readlink /proc/<PID>/exe показывает (deleted), процесс всё ещё работает со старого файла.
• Контейнеры, резервные узлы и раннеры CI используют ту же исправленную сборку.
• В инвентаризации или мониторинге настроена повторная проверка версий PHP.

Как защититься на будущее

Патч закрывает конкретные уязвимости, остальные меры снижают ущерб от следующих. Ни одна из них не заменяет своевременное обновление.

• Подпишитесь на рассылки безопасности PHP и поставщика вашей ОС. Где допустимо, включите автоматические обновления безопасности (например, unattended-upgrades в Debian и Ubuntu). Автообновление не перезапускает процессы само по себе, поэтому проверяйте результат.
• Рассмотрите переход с mod_php на PHP-FPM с отдельными пулами и минимальными правами. Это снижает риск, но не избавляет от необходимости патча.
• Запретите веб-пользователю запись в каталоги с кодом, используйте отдельного пользователя для PHP. В каталогах загрузок запретите выполнение скриптов на уровне веб-сервера. Флаг noexec при монтировании не поможет: PHP читает файл как данные и исполняет его сам, а не запускает через ОС. Пример для nginx (правило должно срабатывать раньше общего обработчика .php; проверьте тестовым запросом в staging):

location ~* ^/uploads/.*\.php$ { return 403; }
# запрещает отдавать и исполнять PHP-файлы из каталога загрузок

• Отключите неиспользуемые функции и расширения. Если загрузка файлов с отслеживанием прогресса вам не нужна, оставьте session.upload_progress.enabled = 0 как элемент базового харденинга. Директива disable_functions может сломать приложения, которые используют эти функции, и не считается полной границей безопасности.
• Включите мониторинг логов и оповещения об изменении файлов в каталоге приложения.
• WAF можно использовать как дополнительный слой, но он не заменяет обновление: возможны ложные срабатывания и обход правил.

Защита самой CMS — отдельная задача; см. материал о том, как защитить wordpress сайт.

Ограничения и остаточные риски

Обновление до 8.5.12, 8.4.27, 8.3.36 или 8.2.35 устраняет CVE-2026-109618 и CVE-2026-109619, но не защищает от уязвимостей в самом веб-приложении, например от SQL-инъекций. Если атакующий успел установить веб-шелл до обновления, патч его не удалит и не прервёт его работу. Ручные проверки из шага 4 не доказывают отсутствие взлома. Номера пакетов в вашем дистрибутиве могут отличаться от номеров upstream-релизов.

Что не вошло в материал

Мы не разбираем механизм эксплуатации и reverse engineering уязвимых функций, а также индикаторы компрометации: в исследованных материалах их нет. Не вошли и настройки контейнерной изоляции (AppArmor, SELinux) из-за разнообразия дистрибутивов.

Материал подготовлен на основе публикаций The Hacker News и актуален на 22 октября 2026 года. Номера пакетов и команды сверяйте с бюллетенями вашего дистрибутива. Применяйте инструкции только на своих серверах или с разрешения их владельца.

Источник: The Hacker News