PHP2Shell: что проверить владельцу сайта

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

Если ваш сайт работает на WordPress, MODX, Drupal, OpenCart или 1С-Битрикс, проверьте не только версию CMS. Важно, какая сборка PHP действительно обрабатывает запросы посетителей. Обновлённая система управления содержимым может использовать уязвимый PHP; возраст и популярность CMS сами по себе ничего не доказывают.

PHP2Shell — повод срочно проверить обновления, но не причина ночью менять платформу. Сначала нужно защитить действующий сайт. Решение о миграции принимают отдельно: по состоянию проекта, стоимости поддержки и задачам бизнеса. Материал проверен 24 октября 2026 года с учётом дополнительного предупреждения PHP от 23 октября.

• Что произошло и кто под угрозой

• Что проверить владельцу сайта прямо сейчас

• Почему поддержка старой CMS дорожает

• Что меняет переход на Progressive CMS

• Как перенести сайт без поспешного отключения

• Ответы на частые вопросы

• Первоисточники

21 октября 2026 года команда PHP выпустила экстренные исправления для CVE-2026-109618 и CVE-2026-109619. Обе уязвимости получили оценку 9,2 из 10 по CVSS 4.0. В публикациях их обсуждают под названием PHP2Shell; в официальных рекомендациях надёжнее ориентироваться на номера CVE и конкретную сборку PHP.

Первая ошибка связана с обработкой нехватки памяти: прерванная операция может оставить внутренние данные запроса в некорректном состоянии. Вторая — с состоянием, которое переживает завершённый запрос и используется позднее, хотя связанная память уже освобождена. Это ошибки среды исполнения PHP, а не одной темы WordPress или отдельного плагина.

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

В предупреждении PHP от 21 октября перечислены разные способы запуска PHP, включая PHP-FPM и Apache mod_php. Наивысшим команда считает риск для mod_php: подтверждён сценарий, в котором атака начинается до выполнения кода самого сайта. Поэтому обновление WordPress не заменяет исправление PHP. Детали эксплуатации зависят от конфигурации; наличие демонстрации не доказывает, что конкретный сайт уже взломан.

1. Узнайте, какой PHP обслуживает именно ваш сайт. Попросите хостинг или администратора назвать версию, пакет, поставщика и способ запуска: например, PHP-FPM или mod_php. На сервере могут одновременно работать несколько версий. Версия в командной строке не обязательно совпадает с версией веб-сайта; открывать общедоступную страницу со всей конфигурацией сервера ради проверки не стоит.

2. Проверьте наличие исправлений. Upstream-релизы с исправлениями двух CVE — 8.2.35, 8.3.36, 8.4.27 и 8.5.12 для соответствующих веток. Используйте подходящий исправленный или более новый поддерживаемый выпуск. У поставщиков Linux возможен backport: патч включён в пакет, номер основной версии остался прежним. В таком случае подтверждение — уведомление поставщика и точная версия пакета, а не только сравнение цифр с PHP.net.

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

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

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

Для PHP 8.1 и более старых веток обычная upstream-поддержка завершена. Уточните у своего поставщика наличие сопровождаемого исправления и план обновления. Временные ограничения запросов и настройки из advisory закрывают лишь отдельные пути атаки. Не переносите их вслепую на рабочий сервер: полноценное исправление требует обновления.

Отдельное сообщение PHP от 23 октября рекомендует установить session.upload_progress.enabled=0 до следующего регулярного исправляющего релиза, чтобы закрыть дополнительный маловероятный путь RCE. Команда связывает его с CVE-2026-115560 и обещает полное advisory в следующем выпуске.

Речь о необычном сочетании настроек: приложение использует обработчик сериализации сессий php_binary или php_serialize, затем переключает его на php через ini_set() перед session_start(), а отслеживание загрузки остаётся включённым. Это не утверждение об уязвимости любого сайта при любых настройках.

Передайте предупреждение администратору вместе с номерами первых двух CVE. Если отключение уже применили по предыдущей рекомендации, PHP предлагает оставить его в силе. Администратору следует проверить настройку до обработки запросов, перезапустить соответствующие процессы и оценить влияние на функции сайта. Исправление двух CVE от 21 октября и дополнительная рекомендация от 23 октября — разные пункты проверки.

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

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

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

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

Progressive CMS позволяет сохранить понятное ручное управление и добавить работу с AI-агентами. Сотрудник редактирует материалы в административной панели, а агент получает поручения через REST API, CLI и MCP: готовит страницы, обновляет содержание и проверяет результат в пределах выданного доступа.

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

Использование агента не делает сайт зависимым от обязательного внешнего AI-сервиса. Опубликованные страницы работают как сайт на CMS, а содержание доступно людям в админке. Для новых агентных задач нужны выбранные вами инструменты и соответствующий доступ.

У Progressive CMS, как у любого программного продукта, могут обнаруживаться уязвимости. Ей также нужны обновления, контроль доступа, резервные копии и сопровождение. Обсуждать переход стоит ради подходящей архитектуры и понятной работы с проектом, а не обещания «безопасности навсегда».

Аудит → карта содержимого и URL → перенос материалов → оформление → проверка форм, SEO и интеграций → согласованное переключение.

Сначала составляют перечень страниц, изображений, документов, форм и подключений. Фиксируют действующие адреса, поисковые заголовки, описания, canonical и важные ссылки. Это исходная карта, с которой затем сравнивают новую версию. Объём работ и способы выгрузки зависят от исходной CMS и её доработок.

Новую версию готовят отдельно: прежний сайт продолжает работать. Тексты и фотографии переносят с проверкой полноты; существующий дизайн можно сохранить или переработать. При миграции с WordPress, MODX, Drupal, OpenCart или 1С-Битрикс отдельно проверяют специфические функции. Если есть каталог, корзина или оплата, нельзя считать их перенесёнными вместе с обычными страницами.

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

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

Проверено 24 октября 2026 года. Технические выводы основаны на публикациях команды PHP и её security advisories:

• PHP: критические уязвимости и обновление от 21 октября.

• CVE-2026-109618: RCE via OOM corruption.

• CVE-2026-109619: RCE via stale global state.

• PHP: дополнительное предупреждение о Session upload progress от 23 октября.

• Карточки идентификаторов в NVD: CVE-2026-109618 и CVE-2026-109619.

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