PHP2Shell: критические уязвимости PHP — что делать владельцу сайта

Что такое PHP2Shell и что произошло

PHP — язык программирования, на котором работают WordPress и многие другие системы управления сайтами. PHP2Shell — название двух уязвимостей в среде выполнения PHP. При определённых условиях они позволяют выполнить посторонний код на сервере без входа в аккаунт.

21 октября 2026 года команда PHP выпустила исправления. Обе проблемы получили оценку 9,2 из 10 по CVSS 4.0 — критический уровень серьёзности. Это оценка уязвимостей, а не вероятность взлома конкретного сайта. Официальный бюллетень PHP.

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

Атаки уже начались или это теоретическая угроза?

Amazon Threat Intelligence сообщила о попытке эксплуатации PHP2Shell, зафиксированной 17 октября 2026 года в сети ловушек MadPot — за четыре дня до публичного раскрытия. Компания также наблюдала последующие попытки атак.

При этом Amazon отдельно оговаривает: для описанных попыток до раскрытия не установлено, были бы они успешны против реальных систем. Эти наблюдения подтверждают необходимость срочных действий, но не доказывают взлом вашего сайта. Исследование Amazon Threat Intelligence.

Какие сайты нужно проверить

Команда PHP относит к группе риска установки, обслуживающие веб-запросы: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Наибольший риск в официальном сообщении отмечен для mod_php. Официальный бюллетень PHP.

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

Если сайт работает на WordPress

Откройте «Инструменты → Здоровье сайта → Информация → Сервер» и найдите версию PHP. Эти сведения также могут быть доступны в панели хостинга.

WordPress выпустил отдельное предупреждение: специальное обновление WordPress для устранения этих двух уязвимостей не требуется и не планируется. Проверять нужно PHP на сервере. Официальная инструкция WordPress.

Если сайт работает на другой CMS

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

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

21 октября проект PHP выпустил следующие исправленные версии:

Источник: Официальный бюллетень PHP. Это версии, в которых появились исправления; при обновлении нужно учитывать и последующие выпуски выбранной ветки.

У пакетов операционной системы нумерация может отличаться. Например, Ubuntu указала исправленный пакет PHP 8.3 для Ubuntu 24.04 LTS как 8.3.6-0ubuntu0.24.04.13. По короткому номеру «8.3.6» нельзя определить, установлено ли исправление: нужно учитывать полную сборку и бюллетень поставщика. Ubuntu USN-8948-1.

Если используется PHP 8.1 или старше, уточните наличие исправлений у поставщика. Некоторые дистрибутивы поддерживают собственные пакеты; например, в том же бюллетене Ubuntu есть исправление для PHP 8.1 в Ubuntu 22.04 LTS. Дальнейшую поддержку такой установки следует согласовать отдельно.

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

Предлагаем следующий порядок взаимодействия с ответственным специалистом.

Для последнего случая ENISA рекомендует рассмотреть изоляцию доступных извне приложений до установки исправлений. Решение нужно принимать с учётом устройства сайта и доступности услуг для клиентов. Совместное заявление ENISA.

Готовое обращение к хостингу

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

Здравствуйте! Прошу проверить сайт [укажите домен] в связи с PHP2Shell — CVE-2026-109618 и CVE-2026-109619.

Подтвердите, пожалуйста:

• какая версия и полная сборка PHP обслуживает сайт;
• установлены ли исправления обеих уязвимостей;
• применены ли изменения к работающему окружению;
• нужны ли действия с моей стороны.

Если исправления ещё не установлены, сообщите срок обновления и временные меры защиты. После завершения прошу подтвердить результат.

Достаточно ли Cloudflare или защитного плагина?

Cloudflare сообщила о развёртывании правил WAF — защитного экрана для веб-приложений — против PHP2Shell. При этом компания прямо рекомендует обновить PHP даже при включённой защите.

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

Как понять, что работа завершена

Для приёмки обновления владельцу сайта удобно использовать короткий список:

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

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

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

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

Установка исправлений закрывает уязвимость, но сама по себе не устанавливает, что происходило на сервере до обновления. При подозрительных событиях нужна отдельная проверка. Исследование Amazon Threat Intelligence.

Нужно ли переделывать сайт после PHP2Shell?

Сам факт обнаружения уязвимости ещё не обосновывает полную переделку. Первое действие — организовать исправление текущего окружения.

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

Если каждый такой вопрос остаётся без ответа, полезно составить план модернизации. При расчёте бюджета учитывайте дальнейшее обслуживание — подробнее об этом в статье «Сколько стоит сайт: как рассчитать бюджет».

Если вы уже планируете новый сайт или переработку существующего, расскажите о задаче Vasiura. Бесплатный первый шаг — идея, структура и прототип первого экрана. Разработка начинается после согласования объёма, сроков и стоимости.

Материал подготовлен по открытым сообщениям разработчиков, поставщиков инфраструктуры и организаций по кибербезопасности. Факты проверены 22 октября 2026 года. Это не результат проверки конкретного сайта. Иллюстрации созданы с помощью ИИ.