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

Что такое 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 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, контейнеры и отдельные пулы для разных сайтов. Безопасный порядок такой:
- Составьте карту окружения. Определите ОС, источник пакетов, установленные ветки, веб-сервер, PHP-FPM-пулы и контейнеры. Сопоставьте каждый сайт с его фактическим обработчиком.
- Проверьте сообщение поставщика. Уточните, какие пакеты закрывают нужные CVE. Для контейнера обновление PHP на хосте не заменяет пересборку и развёртывание образа приложения.
- Подготовьте восстановление. Нужны резервные копии файлов, базы и конфигурации, а также понятный порядок возврата к рабочему состоянию. Старый уязвимый образ — не безопасный долгосрочный откат.
- Проверьте совместимость. По возможности установите патч в текущей поддерживаемой ветке. Переход между крупными ветками предварительно проверьте на тестовом окружении с нужными расширениями и настройками.
- Обновите и замените рабочие процессы. Выполните предписанный поставщиком перезапуск или развёртывание. Убедитесь, что не осталось старых воркеров и соседних сайтов на непроверенной сборке.
- Проверьте веб-путь. Версия 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: предупреждение о двух критических RCE, 21 октября 2026.
- PHP: дополнительное сообщение о session upload progress, 23 октября 2026.
- PHP: обновлённые Windows-сборки с исправлением Brotli, 26 октября 2026.
- Calif: исследование PHP2Shell.
- Cloudflare: защитные правила WAF и ограничения мер.
- Материал Optimism о PHP2Shell, послуживший отправной точкой. Текст Сайтрепорта переработан и дополнен по первоисточникам.
