Перейти к содержимому

PHP2Shell: как защитить сайт и безопасно обновить PHP

PHP2Shell — название двух критических уязвимостей в PHP, которые могут позволить выполнить код на сервере без авторизации. Исправлять нужно сам PHP, а не только WordPress, Битрикс или плагины. Разбираем, что спросить у хостинга, как обновиться без лишнего риска и что проверить после работ.

PHP2Shell: обновление PHP и защита сайта — иллюстрация Сайтрепорта
Проверить сборку PHP → установить исправления → проверить работающий сайт.

Что такое PHP2Shell

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

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

В официальном предупреждении PHP перечислены PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Для mod_php команда отдельно отмечает особенно высокий риск: продемонстрирована атака до выполнения кода приложения.

Какие версии содержат исправления

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

Выпуски PHP с исправлениями двух основных уязвимостей PHP2Shell
Ветка Выпуск с исправлениями
PHP 8.5 8.5.12
PHP 8.4 8.4.27
PHP 8.3 8.3.36
PHP 8.2 8.2.35

Выбирайте актуальный исправленный пакет своего поставщика. У Linux-дистрибутивов и хостингов исправление бывает перенесено в более старую версию — это называется бэкпорт. Поэтому одного номера вида «PHP 8.1» или «PHP 8.2» недостаточно ни для подтверждения уязвимости, ни для подтверждения защиты. Нужны точная сборка и информация поставщика об исправлении CVE.

PHP 8.1 и более старые ветки больше не получают обычные обновления от проекта PHP. При этом команда предоставила минимальные исходные бэкпорты для 7.4, 8.0 и 8.1; отдельные дистрибутивы и LTS-поставщики выпускают свои пакеты. Это не делает старую ветку снова поддерживаемой: уточните наличие исправлений и запланируйте переход на поддерживаемую версию. PHP 8.2 достигает конца поддержки проекта 31 декабря 2026 года.

Для Windows: 26 октября опубликованы пересобранные пакеты 8.5.12-1, 8.4.27-1, 8.3.36-1 и 8.2.35-1 с исправлением отдельной уязвимости Brotli. Суффикс -1 обозначает пересборку зависимостей, а версия самого PHP при этом остаётся прежней. При обновлении Windows-сервера учитывайте и это сообщение поставщика.

Если сайт находится на виртуальном хостинге

Владелец сайта обычно не может заменить системные пакеты. Переключатель «PHP 8.3» в панели выбирает ветку, но сам по себе не подтверждает установку нужного патча. Напишите в поддержку и попросите проверить конкретный домен:

Здравствуйте! Прошу проверить PHP для сайта example.ru.

1. Какая точная сборка PHP и какой способ запуска обслуживают домен?
2. Установлены ли исправления CVE-2026-109618 и CVE-2026-109619?
   Если это бэкпорт, пришлите ссылку на описание пакета или подтверждение поставщика.
3. Используют ли все рабочие процессы PHP исправленную сборку?
4. Учтено ли дополнительное сообщение PHP от 23.10.2026
   о session.upload_progress и CVE-2026-115560?
5. Если работы ещё не выполнены, когда они будут завершены?

После обновления я проверю основные функции сайта.

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

Если у вас VPS или свой сервер

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

  1. Составьте карту окружения. Определите ОС, источник пакетов, установленные ветки, веб-сервер, PHP-FPM-пулы и контейнеры. Сопоставьте каждый сайт с его фактическим обработчиком.
  2. Проверьте сообщение поставщика. Уточните, какие пакеты закрывают нужные CVE. Для контейнера обновление PHP на хосте не заменяет пересборку и развёртывание образа приложения.
  3. Подготовьте восстановление. Нужны резервные копии файлов, базы и конфигурации, а также понятный порядок возврата к рабочему состоянию. Старый уязвимый образ — не безопасный долгосрочный откат.
  4. Проверьте совместимость. По возможности установите патч в текущей поддерживаемой ветке. Переход между крупными ветками предварительно проверьте на тестовом окружении с нужными расширениями и настройками.
  5. Обновите и замените рабочие процессы. Выполните предписанный поставщиком перезапуск или развёртывание. Убедитесь, что не осталось старых воркеров и соседних сайтов на непроверенной сборке.
  6. Проверьте веб-путь. Версия PHP в терминале может отличаться от версии PHP-FPM. Подтверждать результат нужно для реальных запросов сайта, а не только командой php -v.

Если обновление прямо сейчас невозможно

Полноценной заменой патча временные настройки не являются. Официальное предупреждение описывает частичные меры для отдельных путей атаки: отключение session.upload_progress.enabled до разбора запроса с заменой всех воркеров, ограничения запросов и другие настройки. Применение через ini_set() или FPM .user.ini не закрывает подтверждённые ранние пути, о которых говорит команда PHP.

Не копируйте без разбора совет memory_limit=-1: он снимает ограничение памяти PHP и увеличивает риск исчерпания ресурсов. Такая мера требует отдельного анализа и ограничений на уровне инфраструктуры. Для владельца сайта правильнее срочно согласовать действия с администратором, чем менять лимиты наугад.

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

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

Что проверить после обновления

  • Главную, типовые страницы каталога, карточки товаров и публикации: ответы сервера, верстку, изображения и ссылки.
  • Авторизацию, поиск, отправку форм и загрузку файлов. В интернет-магазине — оформление заказа и интеграции, не создавая лишних реальных оплат.
  • Фоновые задачи, очереди, cron, почтовые уведомления и обмен с внешними системами.
  • Журналы PHP и веб-сервера: не появились ли новые ошибки, 500/502 и отказы расширений.
  • Редиректы, canonical, robots.txt и sitemap.xml: техническое обновление не должно случайно закрыть сайт от поиска или изменить URL.

После ручной проверки полезно повторить технический аудит в Сайтрепорте и сравнить состояние страниц с предыдущим отчётом. Это поможет заметить проблемы доступности, ссылок и индексации. SEO-аудит не является проверкой эксплуатации PHP2Shell, поиском всех бэкдоров или доказательством отсутствия взлома.

Если есть подозрение на взлом

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

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

Итог: обновить — и подтвердить результат

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

Источники и дополнительные материалы

Под лупой

Где действительно исправляется PHP

Учебная схема. Не результат сканирования вашего сайта.

Обновить WordPress недостаточно

CMS работает поверх PHP. Исправление ошибки интерпретатора устанавливают в пакет PHP или образ, который запускает приложение.

Обсудить материал

Ваш адрес email не будет опубликован. Обязательные поля помечены *