PHP2Shell: что делать владельцам сайтов на PHP и WordPress

Что произошло

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

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

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

В область проверки входят PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. В официальном уведомлении PHP наибольший риск выделен для mod_php: продемонстрирована атака до выполнения кода приложения. Переходить от этого к выводу «на nginx с PHP-FPM безопасно» нельзя. Рекомендации NCSC-NL.

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

Что означает PHP2Shell

Обе уязвимости связаны с обработкой памяти и состояния запросов. CVE-2026-109618 затрагивает завершение запроса при нехватке памяти. CVE-2026-109619 связана с состоянием, которое остаётся после освобождения памяти одного запроса и затем используется другим запросом в том же рабочем процессе. Для обеих указан критический уровень CVSS 4.0: 9,2. Успешность конкретной атаки зависит от сборки, расширений и конфигурации. Описание CVE-2026-109618, описание CVE-2026-109619.

Термин «веб-шелл» обозначает инструмент, который злоумышленник может использовать для управления взломанным сайтом. PHP2Shell: название конкретной пары уязвимостей. Наличие неизвестного PHP-файла не устанавливает, каким способом проникли на сервер.

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

Первые исправленные релизы PHP от 21 октября:

Устанавливайте актуальный исправленный пакет для своей ветки. Таблица относится к релизам проекта PHP; дистрибутивы Linux и поставщики длительной поддержки могут включать патчи, сохраняя более старую основу номера версии. Оперативные рекомендации NCSC-NL.

Для официальных Windows-пакетов 26 октября вышли пересборки 8.2.35-1, 8.3.36-1, 8.4.27-1 и 8.5.12-1 с исправлением отдельной уязвимости Brotli CVE-2026-111497. Выбирайте обновлённый пакет. Суффикс -1 обозначает пересборку зависимостей; номер PHP в работающем интерпретаторе остаётся прежним. Это отдельное обновление, а не обход исправлений PHP2Shell. Уведомление PHP от 26 октября.

Например, Ubuntu указывает исправленный пакет 8.3.6-0ubuntu0.24.04.13 для Ubuntu 24.04. Он выглядит старше PHP 8.3.36, но содержит исправления. Сверяйте полный номер пакета и бюллетень его поставщика, а не только первые три числа. Таблица исправлений Ubuntu.

PHP 8.1 и более старые ветки уже не получают обычных обновлений от проекта PHP. Для 7.4, 8.0 и 8.1 подготовлены исключительные минимальные исходные патчи; отдельные поставщики выпускают собственные исправленные пакеты. Это не возобновляет полноценную поддержку старых веток. Если сайт от них зависит, запросите у хостера подтверждение исправлений и согласуйте переход на поддерживаемую версию. Сведения NCSC-NL о старых ветках и backport-патчах.

Как проверить PHP в WordPress

Откройте в панели WordPress: Инструменты → Здоровье сайта → Информация → Сервер. В английском интерфейсе: Tools → Site Health → Info → Server. Найдите версию PHP и сопоставьте её с данными хостинга. Инструкция WordPress.

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

Не оставляйте общедоступную диагностическую страницу с полным phpinfo(): она раскрывает сведения о сервере. Если администратор использует временную проверку через веб, доступ к ней нужно ограничить и убрать её после проверки.

Что написать хостингу

Если сервер обслуживает хостер или подрядчик, отправьте ему конкретный запрос:

Ответ «у нас включён антивирус» не подтверждает обновление PHP. Сообщение «поставили PHP 8.3» тоже недостаточно: нужны полный номер или сведения об исправленной сборке. При backport-патчах номер может выглядеть прежним. Например, Plesk сообщает об исправленных Linux-сборках PHP 7.4.33, 8.0.30 и 8.1.34 с датой сборки 21 октября. Пояснение Plesk.

Как провести обновление и проверить сайт

Последовательность работ для владельца и администратора:

1. Составьте список установок.

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

2. Подготовьте восстановление.

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

3. Установите исправленные пакеты.

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

4. Замените работающие процессы.

   Администратор должен убедиться, что веб-запросы обрабатывает обновлённый код. Установка пакета на диск не доказывает замену уже запущенных процессов. Для Apache с mod_php Ubuntu прямо указывает необходимость перезапуска Apache. Рекомендации Ubuntu.

5. Проверьте бизнес-функции.

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

6. Сохраните результат.

   Зафиксируйте пакет, обработчик домена, время обновления и результаты проверок. Если возникла несовместимость, устраните её или ограничьте доступ на время работ; возвращение уязвимого PHP снова открывает риск.

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

Дополнение от 23 октября про session.upload_progress

После исходного релиза PHP опубликовал уведомление об отдельной CVE-2026-115560. Она требует необычного сочетания: включённого отслеживания загрузки, исходного сериализатора сессий php_binary или php_serialize и его переключения на php через ini_set() перед session_start().

До следующего обычного исправляющего релиза PHP рекомендует session.upload_progress.enabled=0. Уже применённую настройку нужно сохранить. Для приложений, которые не переключают сериализатор во время выполнения, уведомление допускает сохранение функции. Это отдельное условие проверки, а не основание отказываться от исправлений двух исходных CVE. Настройку должен проверить администратор в конфигурации, действующей до разбора запроса. Уведомление PHP от 23 октября.

Помогут ли Cloudflare и защитный плагин

Cloudflare развернула WAF-защиту от известных вариантов атак, в том числе для бесплатного плана. В сообщении её технического директора, прочитанном через публичное зеркало, подчёркивается временный характер этой меры. Оригинал X напрямую проверить не удалось. Сам провайдер продолжает рекомендовать обновление PHP. Пост Dane Knecht в X, публичное зеркало, официальное описание защиты Cloudflare.

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

Защитный плагин WordPress полезен для своих задач, но не заменяет исправление PHP. Некоторые подтверждённые пути срабатывают до загрузки приложения. Отключение session.upload_progress также перекрывает лишь часть путей исходной пары уязвимостей. Бюллетень PHP о stale global state.

Если установить патч немедленно нельзя, администратор должен выбрать временные меры по официальному бюллетеню и оценить ограничение публичного доступа. В некоторых случаях безопаснее временно отключить систему. Страница обслуживания, реализованная плагином внутри WordPress, сама по себе не исключает обработку запроса уязвимым PHP. Рекомендация WordPress.

Что известно об атаках

AWS сообщила о попытке эксплуатации в сети ловушек MadPot 17 октября, до публичного раскрытия, и о последующих попытках. При этом компания отдельно оговорила неопределённость успешности ранних попыток против реальных систем. Эти наблюдения подтверждают необходимость срочных действий, но не означают, что каждый доступный PHP-сайт уже взломан. Отчёт AWS.

24 октября исследователь Adel Karimi опубликовал отчёт с сопоставлением сетевых запросов и запуска процессов на PHP-ловушках. Он описывает успешное выполнение кода на Apache/mod_php с PHP 8.4.26. Область этого свидетельства: специально развёрнутые honeypot-серверы; это не отчёт о взломе клиентских production-сайтов. Первичный отчёт исследователя.

Часть ранних сообщений была исправлена. Sophos отозвала первоначальную оценку успешного взлома: её телеметрия показывала сканирование и неуспешные попытки. Unit 42 позднее отозвала связь первоначального доступа к европейскому госоргану именно с PHP2Shell. Поэтому числа запросов, попыток атаки и взломанных сайтов нельзя подменять друг другом. Исправление Sophos от 22 октября, исправление Unit 42 от 25 октября.

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

Неизвестный администратор, новый плагин, посторонние файлы, неожиданные перенаправления или запуск процессов требуют расследования. По одному признаку нельзя установить PHP2Shell как причину. Рекомендации WordPress при взломе.

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

Попросите проверить неожиданные изменения файлов, пользователей и заданий, а также процессы веб-сервера. AWS рекомендует рассматривать период как минимум с 17 октября. Если журналы за это время уже удалены, это ограничивает выводы проверки. Отсутствие совпадения с одним IP или сигнатурой не устанавливает отсутствие атаки. Рекомендации AWS.

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

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

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

Результат должен включать работающее исправленное окружение и проверенный пользовательский сценарий. Одного сообщения «всё обновлено», открытия главной страницы или чистого отчёта одного сканера недостаточно, чтобы подтвердить оба результата.