PHP2Shell: что делать, если у вас сайт на PHP

21 октября 2026 PHP закрыл две критичные уязвимости — CVE-2026-109618 и CVE-2026-109619. В СМИ и у исследователей связка называется PHP2Shell (или php2shell).

Суть: при определённых HTTP-запросах злоумышленник без логина может выполнить код на сервере или прочитать память процесса (пароли, токены). Ломается сам интерпретатор PHP, а не «кривой» плагин.

Затронуты установки, которые отдают веб-запросы: PHP-FPM, Apache mod_php (по оценке PHP — самый рискованный вариант), php-cgi, FrankenPHP, LiteSpeed. Даже простой «Hello World» на уязвимой версии опасен.

Публичные эксплойты уже есть. У исследователей и в honeypot фиксировали попытки эксплуатации; CISA призывает патчить немедленно. Это не повод паниковать «нас уже взломали» — но и ждать «пока не придут» нельзя.

Почти любой сайт на PHP в интернете: корпоративные витрины, лендинги, интернет-магазины, админки, API на Laravel/Symfony, Битрикс, WordPress, Joomla, Drupal, самопис.

Версии PHP с 5.4 до актуальных веток до патча — в зоне риска. PHP 8.1 и старше официально не получают фикс от проекта: нужен бэкпорт от дистрибутива/хостера или апгрейд на поддерживаемую ветку.

Отдельный риск — staging, «временный» VPN-хост и копии магазина на поддоменах: их часто забывают обновлять.

См. также: Битрикс на периметре, новые поддомены.

Официальные исправления (обновите минимум до указанной сборки в своей ветке):

• PHP 8.5.x → 8.5.12 или новее
• PHP 8.4.x → 8.4.27 или новее
• PHP 8.3.x → 8.3.36 или новее
• PHP 8.2.x → 8.2.35 или новее
• PHP 8.1 и старше → бэкпорт вендора/хостера или переход на поддерживаемую ветку; иначе CISA советует снять с интернета до патча

WAF может снизить часть известных паттернов атаки, но не заменяет обновление runtime. Обновление плагинов и темы WordPress/Битрикс само по себе PHP2Shell не закрывает.

1. Узнайте версию PHP на проде (панель хостинга, `phpinfo` только во внутренней сети, или ответ сервера — если версия светится снаружи).

2. Если ниже безопасной сборки — обновите PHP в панели / у хостера / через образ контейнера. Согласуйте с подрядчиком по Битрикс: смена минорной версии обычно безопаснее прыжка через major.

3. Проверьте копии магазина: `dev.`, `stage.`, `test.`, старые поддомены агентства. Их тоже нужно обновить или закрыть с улицы.

4. После патча перезапустите php-fpm / пул воркеров и убедитесь, что в проде реально новая версия.

5. Посмотрите логи на странные POST, всплески ошибок и неизвестные файлы в document root.

Быстрый внешний взгляд без доступа к серверу: проверка сайта в Радаре и гайд Битрикс на периметре.

CMS тут ни при чём как первопричина: уязвим PHP под ними. Обновление WordPress core / плагинов ≠ патч PHP2Shell.

На shared-хостинге: откройте панель → версия PHP → выберите безопасную сборку из списка выше. Если выбора нет — тикет хостеру со ссылкой на CVE-2026-109618 / CVE-2026-109619 и просьбой обновить runtime.

На managed WordPress / «коробочном» тарифе спросите поддержку явно: «какая версия PHP на моём сайте и пропатчена ли она под php2shell?»

Несколько сайтов в одном аккаунте — проверьте каждый: разные виртуальные хосты часто на разных ветках PHP.

Пока патча нет, часть провайдеров включает WAF-правила; это временная подушка, не финал.

Обновите пакеты дистрибутива или базовый образ до безопасной сборки PHP, пересоберите и задеплойте контейнеры заново (старый слой образа может тащить старый PHP).

Проверьте все окружения: prod, staging, preview, CI-раннеры, которые крутят PHP на публичном порту.

mod_php на Apache — приоритет №1 по риску по оценке самого PHP; PHP-FPM тоже нужно обновить.

Временные меры до патча (не полная защита): ограничить multipart-загрузки, если приложение это переживёт; усилить WAF; сузить доступ к админкам. Полное закрытие — только обновлённый runtime.

После обновления: `php -v` на хосте и проверка, что веб-пул смотрит на тот же бинарник.

Именно здесь чаще всего «забыли про PHP». Staging агентства, старая витрина на `old.`, демо Битрикс, phpMyAdmin на отдельном хосте.

Снимите с интернета то, что не нужно; остальное — тот же патч, что и прод.

Инвентарь и алерт на новое: новые поддомены и shadow IT.

Вопрос не «существует ли CVE», а «есть ли у нас PHP на периметре и видна ли уязвимая версия».

• Добавьте корневой домен в signalfort и подтвердите владение (TXT в DNS)
• Дождитесь обнаружения хостов и сверки стека
• Если PHP/версия видны снаружи и совпали с сигналом — появится находка (сначала как совпадение)
• «Подтверждено» — только после безопасной проверки на платном плане; не путайте с «нас уже взломали»

Подробнее про статусы: как понять, касается ли CVE вас. Старт: бесплатная проверка.

Не копируйте PoC из интернета на боевой сайт «чтобы проверить» — так вы сами создаёте риск.

• Не считать, что «обновили Битрикс/WordPress — значит PHP тоже закрыт»
• Не оставлять PHP 8.1 и старше без ответа вендора, если сайт смотрит в интернет
• Не гонять публичные эксплойты на прод
• Не забывать контейнеры и стенды рядом с основным доменом

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

Просмотрите логи веб-сервера и PHP на аномалии около дат раскрытия (с 17–21 октября 2026 попытки уже фиксировали в телеметрии).

Ищите неожиданные файлы в корне сайта, новые админ-пользователи, странные cron-задачи.

Если есть подозрение на компрометацию — изолируйте хост и работайте по своему IR-процессу; signalfort помогает с экспозицией и совпадениями, но не заменяет разбор инцидента на сервере.