Уязвимости PHP2Shell: как проверить сайт и установить патч PHP

PHP2Shell — название двух критических уязвимостей PHP: CVE-2026-109618 и CVE-2026-109619. При успешной атаке они позволяют постороннему выполнить код на сервере без авторизации. Проблема находится в самом интерпретаторе: обновление CMS или смена пароля администратора не заменяют установку исправлений PHP. 

21 октября 2026 года разработчики выпустили экстренные обновления безопасности: PHP 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Это первые исправленные выпуски соответствующих веток. Для пакетов Linux с перенесенными исправлениями нужно проверять бюллетень поставщика и номер сборки: прежний номер базовой версии еще не доказывает наличие уязвимости. 

Что делать владельцу сайта:

• Выяснить, какая сборка PHP обрабатывает веб-запросы именно его сайта.

• Установить исправление из доверенного источника и перезапустить PHP-процессы.

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

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

Как работают уязвимости PHP2Shell и чем они опасны

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

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

CVE-2026-109619 — обращение к уже освобожденной памяти. Рабочий процесс PHP может сохранить ссылку на данные завершенного запроса, хотя память под них уже освобождена. При обработке следующего запроса тот же процесс способен использовать устаревшую ссылку. Это ошибка класса use-after-free; при подходящих условиях она также позволяет выполнить посторонний код. 

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

Авторизация в CMS не перекрывает проблему. Разработчики PHP отдельно выделяют Apache с mod_php: для него продемонстрирована атака, запускаемая до выполнения кода приложения. Следовательно, проверка пароля, CAPTCHA и защитный плагин CMS могут еще не участвовать в обработке запроса, когда уязвимый механизм уже сработал. Проверять и исправлять необходимо серверную среду, а не только сам сайт.

Какие версии PHP затронуты и где искать уязвимый сервер

Проверять нужно все установки PHP, обслуживающие веб-запросы. В официальном уведомлении перечислены PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Поэтому связка Nginx + PHP-FPM тоже требует внимания: отсутствие Apache не исключает риск PHP2Shell.

Для поддерживаемых веток ориентиром служат следующие выпуски:

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

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

Инвентаризацию проводите по сайтам и обработчикам, а не только по физическим серверам. На одном VPS основной сайт может работать на PHP 8.3, старый поддомен — на PHP 7.4, а тестовая копия — в отдельном контейнере. Исправление одной установки не обновит остальные.

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

Как проверить PHP на своем сайте

Команда php -v не подтверждает безопасность сайта. Она показывает версию запущенной консольной программы PHP. Веб-сервер при этом может передавать запросы другому обработчику — например, отдельному пулу PHP-FPM. На сервере с несколькими версиями эти значения могут различаться. 

Начните с панели хостинга: откройте настройки нужного домена и найдите выбранную версию PHP. Затем уточните у провайдера статус исправлений. Вместо общего вопроса «PHP обновлен?» отправьте конкретный запрос:

Подтвердите, пожалуйста, устранены ли CVE-2026-109618 и CVE-2026-109619 в сборке PHP, которая обслуживает мой домен. Укажите версию пакета или сборки и подтвердите перезапуск рабочих процессов после установки исправлений.

Если сервер администрирует ваша команда, нужно сопоставить настройки домена с фактическим обработчиком. Для дополнительной проверки можно временно разместить в каталоге сайта небольшой PHP-файл, предварительно ограничив доступ к нему своим IP средствами веб-сервера:

<?php
header('Content-Type: text/plain; charset=utf-8');
header('Cache-Control: no-store');

echo 'PHP: ', phpversion(), PHP_EOL;
echo 'SAPI: ', php_sapi_name(), PHP_EOL; 

Откройте файл через адрес проверяемого сайта. Функция phpversion() вернет версию интерпретатора, выполнившего запрос, а php_sapi_name() — используемый интерфейс, например fpm-fcgi или apache2handler. После проверки удалите файл. Для этой задачи не требуется публиковать полный вывод phpinfo() с подробностями конфигурации. 

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

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

Как установить патч PHP и не нарушить работу сайта

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

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

Для срочного исправления обычно разумнее сначала обновить текущую поддерживаемую ветку. Переход между ветками, например с PHP 7.4 на 8.4, требует отдельной проверки совместимости CMS, модулей и собственного кода.

Порядок установки зависит от окружения:

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

После установки перезапустите соответствующие службы или пересоздайте контейнеры. Замена файлов на диске и запуск сайта на исправленном коде — разные этапы. Убедитесь, что старые рабочие процессы завершены, а новые используют обновленную сборку.

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

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

Что делать, если обновить PHP сразу невозможно

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

Если приложение допускает перерыв в работе, временно закройте доступ к нему на уровне веб-сервера, прокси или межсетевого экрана. Для внутреннего сервиса можно оставить подключения только через VPN или с доверенных адресов. Обычная страница «Технические работы», сформированная средствами CMS, не гарантирует изоляцию: запросы по-прежнему могут поступать в PHP.

Если используется WAF, уточните у поставщика наличие правил именно для CVE-2026-109618 и CVE-2026-109619. Проверьте, что трафик действительно проходит через защиту и сервер нельзя обойти прямым обращением к его IP. Это дополнительный барьер, а не подтверждение безопасности установленной сборки.

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

Не переносите рекомендации по памяти без оценки последствий. Параметр memory_limit=-1 снимает лимит памяти PHP; это не универсальное «безопасное значение». Его применение требует отдельного ограничения ресурсов и контроля доступности сервера. Настройку должен выбирать администратор с учетом архитектуры приложения.

Для каждой временной меры зафиксируйте ответственного и срок установки исправления. Критерий завершения работ — запуск исправленной сборки, а не отсутствие новых предупреждений WAF или ошибок в журнале.

Как проверить сайт на взлом после обновления PHP

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

• Файлы сайта: неизвестные PHP-скрипты, изменения конфигурации и отличия от доверенной копии.

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

• Сервер: незнакомые процессы, задания cron и необычные исходящие соединения.

• Журналы: сбои PHP и подозрительные запросы, совпадающие по времени с изменениями системы.

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

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

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

Нужно ли обновлять WordPress или 1С-Битрикс для защиты от PHP2Shell?

Обновления CMS нужны для устранения ее собственных уязвимостей, но PHP2Shell требует исправления интерпретатора PHP. Даже актуальная CMS может работать на уязвимой серверной сборке.

Защищает ли HTTPS от эксплуатации этих уязвимостей PHP?

Нет. HTTPS шифрует соединение между клиентом и сервером, но не исправляет ошибки обработки запросов. Специально сформированный запрос может поступить и по защищенному соединению.

Можно ли проверить сайт онлайн-сканером?

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

Нужно ли покупать отдельный патч PHP?

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

Что означает shell в названии PHP2Shell?

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