PHP2Shell: срочное обновление PHP и проверка защиты сайта

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

Проверка актуальна для сайтов на WordPress, Joomla, Drupal, приложений на Laravel и собственного PHP-кода. Ниже — порядок действий для владельца сайта: как выяснить версию обработчика, что запросить у хостинга и чем подтвердить результат. Сведения о выпусках проверены 31 октября 2026 года. Для конкретного сервера важны также сборка поставщика, конфигурация и совместимость приложения.

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

Проверить PHP на сайте

1. Что произошло и какие сайты затронуты

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

PHP указывает среди затронутых способов запуска PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Для mod_php подтверждён сценарий до выполнения кода приложения. Поэтому наличие входа в админку и актуального ядра CMS не подтверждает защищённость окружения. Подробности — в официальном сообщении PHP от 21 октября.

Сайт может нормально открываться и принимать заказы, оставаясь на старом обработчике. Пропавший заголовок X-Powered-By, зелёный значок HTTPS и отсутствие заметных ошибок тоже не показывают, какие исправления установлены. Нужна проверка фактической сборки и работающих процессов.

2. В каких версиях исправлена эта пара уязвимостей

Официальные объявления двух CVE перечисляют следующие первые исправленные выпуски поддерживаемых веток:

Это номера первых исправлений конкретных CVE, а не обещание безопасности любой сборки с таким номером. В Linux исправление может быть перенесено поставщиком в пакет с прежней базовой версией: это называют backport. Подтверждением служат бюллетень поставщика и ревизия установленного пакета. Надписи «PHP 8.2» в панели для такого вывода мало.

Для PHP 8.1 и более старых веток нужно отдельно выяснить наличие поддерживаемого пакета с перенесёнными исправлениями и спланировать переход. Самостоятельно собирать случайный патч из комментариев вместо обновления поставщика для рабочего магазина не стоит.

Уточнения после основного выпуска. 23 октября PHP опубликовал отдельное сообщение о редком сочетании настроек сессий: сериализатор php_binary или php_serialize меняется на php во время запроса перед session_start(), а прогресс загрузки включён. В объявлении о session upload progress рекомендовано session.upload_progress.enabled=0 до следующего исправления. Для Windows 26 октября вышли также пересборки с суффиксом -1 из-за отдельной проблемы Brotli; номер самого PHP при этом не меняется. Учитывайте это уточнение для Windows при выборе пакета.

3. Проверьте PHP сайта, консоли и заданий Cron

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

• Веб-сайт. Установите версию и способ запуска PHP для нужного домена. Проверьте активный пул или модуль, загруженную конфигурацию и действующие ограничения.
• Командная строка. Уточните полный путь к бинарному файлу, версию и набор подключаемых ini-файлов. Для этого полезны php -v и php --ini с нужным путём к интерпретатору.
• Cron и фоновые процессы. Посмотрите команды запуска агентов, обмена и импорта. После замены исполняемых файлов проверьте новые запуски и завершение старых долгоживущих процессов.

Не оставляйте публичный файл phpinfo() ради проверки: он раскрывает лишние сведения об окружении. Версию веб-обработчика можно получить через штатные инструменты администрирования или временную диагностику с ограниченным доступом и последующим удалением. Сравните результат с данными панели хостинга.

4. Как организовать срочное обновление

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

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

1. Зафиксировать окружение. Записать пакеты и ревизии, способ запуска PHP, расширения, активные ini-файлы и команды Cron. Для конфигурации полезны контрольные суммы.
2. Проверить возможность восстановления. Убедиться, что внешняя резервная копия доступна, содержит файлы и базу данных приложения, а порядок восстановления понятен и проверен.
3. Согласовать пакет и совместимость. Выбрать исправление из доверенного источника. Если меняется ветка PHP, отдельно проверить CMS или фреймворк, зависимости и собственный код на тестовой копии.
4. Установить исправления и заменить процессы. Проверить конфигурацию веб-сервера и выполнить предусмотренный для окружения перезапуск. Подтвердить, что старые процессы завершились и больше не используют прежние библиотеки.
5. Пройти приёмку. Сопоставить фактический PHP сайта, настройки, журналы и ключевые сценарии до и после работ.

Временные ограничения запросов и правила WAF согласовывайте с администратором. Они могут уменьшать отдельные риски, но не подтверждают установку исправленного PHP. Настройка session.upload_progress.enabled должна применяться до разбора запроса, например через системный php.ini или конфигурацию пула/Apache, с заменой рабочих процессов. Вызов ini_set() в коде приложения для этой задачи недостаточен. Возможность отключения и влияние на приложение проверяются отдельно.

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

5. Что проверить после установки исправлений

Сообщения «пакет установлен» и «служба работает» описывают только часть результата. Нужны проверка работающего обработчика и приёмка сайта:

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

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

6. Что прислать для оценки работ

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

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

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

Закроет ли PHP2Shell обычное обновление CMS?

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

Обязательно ли сразу переводить старый сайт на PHP 8.5?

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

Если после обновления сайт работает, значит ли это, что его не взломали?

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