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

Эта проблема стала критической после того, как разработчики PHP сообщили о двух уязвимостях удаленного выполнения кода (RCE), получивших идентификаторы CVE-2026-109618 и CVE-2026-109619, которые в совокупности называют PHP2Shell. Проект PHP выпустил исправленные версии 21 октября 2026 года. В бюллетене указано, что под угрозой может находиться любая инсталляция PHP, обрабатывающая веб-запросы, включая PHP-FPM, Apache  mod_php ,  php-cgi , FrankenPHP и LiteSpeed. Наивысший уровень риска проект присвоил  mod_php , где специально сформированный запрос мог привести к эксплуатации уязвимости еще до того, как начнет выполняться код приложения. (Бюллетень безопасности PHP)

История обнаружения требует точного указания авторства. Компания Calif Research заявляет, что обнаружила первые баги PHP2Shell во время собственного аудита. Представители OpenAI утверждают, что модель GPT-5.6 Sol помогла Calif выявить критическую уязвимость, в то время как специалисты Wiz описывают отдельный, более поздний аудит, в котором использовались как Gemini 4 Argon, так и GPT-5.6 Sol. В Wiz отмечают, что модель Argon внесла значительный вклад в открытие. Эти заявления подтверждают более узкий факт: исследование с помощью ИИ помогло выявить данные проблемы. Это вовсе не означает, что искусственный интеллект автономно нашел каждую уязвимость или построил всю цепочку эксплойтов. (Отчет Calif Research, Отчет OpenAI, Отчет Wiz)

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

Начните с точных исправленных версий

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

  • PHP 8.5.12
  • PHP 8.4.27
  • PHP 8.3.36
  • PHP 8.2.35

Дистрибутивы Linux и вендоры ПО с долгосрочной поддержкой (LTS) могут бэкпортировать исправления безопасности, не меняя при этом номер версии вышестоящего (upstream) проекта привычным образом. Разработчики PHP рекомендуют уточнять информацию об обновленных пакетах у вашего дистрибутива. PHP 8.1 и более старые версии больше не поддерживаются проектом PHP, однако дистрибутив или вендор может выпускать собственные бэкпорты. Не делайте выводов о том, уязвима версия или нет, основываясь исключительно на ее строке. Сверьтесь с бюллетенем безопасности вендора пакета или проверьте происхождение сборки (provenance). (Бюллетень PHP)

В этом контексте полезен отчет Национального центра кибербезопасности Нидерландов (NCSC-NL), так как он отслеживает как сам PHP, так и стороннее ПО, которое может поставляться вместе с ним. На 4 ноября в их реестре числилось 948 продуктов, из которых 215 были помечены как уязвимые, а 185 — как исправленные на момент снимка данных. Эти цифры меняются по мере того, как мейнтейнеры обновляют список, поэтому воспринимайте их как срез данных на определенную дату, а не как актуальный универсальный итог. (Трекер PHP2Shell от NCSC-NL)

Почему  php -v  — это еще не полный аудит

Команда  php  обычно сообщает версию интерпретатора командной строки, выбранного в вашей текущей переменной PATH. Однако веб-сайт может использовать PHP-FPM в связке с Nginx, модуль Apache, образ контейнера, панель управления хостингом или PHP, встроенный в стороннее устройство (appliance).

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

Эту задачу можно представить как трехуровневую проблему инвентаризации:

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

Чистый результат на одном уровне не означает безопасность остальных двух. Рекомендации NCSC-NL прямо советуют выявлять приложения на базе PHP и отдельно проверять сторонние образы, устройства и встроенные рантаймы. (Оперативное руководство NCSC-NL)

Шаг 1: Перечислите все места, где может запускаться PHP

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

На каждом администрируемом вами хосте под управлением Linux полезные подсказки дадут следующие команды (выполняемые только для чтения):

 command -v php || true
php -v 2>/dev/null || true
php --ini 2>/dev/null || true
ps -eo pid,comm,args | grep -E '[p]hp-fpm|[p]hp-cgi|[a]pache2|[h]ttpd|[l]itespeed'
systemctl --type=service --state=running | grep -Ei 'php|apache|httpd|nginx|litespeed'
 

Это вспомогательные средства обнаружения, а не полноценный сканер. Имена процессов различаются в зависимости от операционной системы и пакета. Обратный прокси (например, Nginx) может перенаправлять запросы в PHP-FPM, поэтому наличие одного лишь Nginx мало что говорит о версии PHP. Аналогичным образом, список процессов может показывать службу без указания образа или пакета, из которого был установлен ее бинарный файл.

Для хостов на базе Debian или Ubuntu в качестве второй точки контроля проверьте установленные пакеты:

 dpkg-query -W -f='${Package} ${Version}\n' 'php*' 2>/dev/null
 

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

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

Шаг 2: Проверьте контейнеры и поставляемые в комплекте продукты

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

 docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'
 

Эта команда выводит информацию только о контейнерах, видимых тому демону Docker, к которому вы обратились. Повторите процедуру для каждого кластера, аккаунта и окружения, а для Kubernetes или других платформ используйте инвентаризационные данные вашего оркестратора. Для каждого PHP-образа определите его базовый образ и выполните пересборку на основе образа с исправленным вендором рантаймом. Наличие тега вроде  latest  не доказывает, что развернутый образ изменился; сравнивайте неизменяемые дайджесты образов (image digests) или метаданные сборки в вашем реестре.

Также проверьте продукты, в которые PHP встроен напрямую, а не поставляется в виде отдельного пакета. Трекер NCSC-NL содержит названия софта нижнего уровня и ссылки на бюллетени поставщиков. Продукту может потребоваться обновление прошивки или аппаратного модуля (appliance), даже если на нем нельзя запустить  php -v . Для хостинговых сервисов уточните у провайдера, был ли патч применен к соответствующему пулу серверов или компоненту службы, и запросите версию затронутого продукта или статус развертывания обновлений. (Реестр продуктов NCSC-NL)

Именно здесь подход «проверки только версии» часто дает сбой. Утверждение «на сервере стоит PHP 8.4» оставляет без ответа вопросы: какая именно это сборка, какой хост и какой процесс. Более полезная запись выглядит так: «В публичном веб-слое работает пропатченный вендорский пакет; служба FPM была перезапущена; запущенный процесс теперь сообщает об ожидаемой сборке».

Шаг 3: Установите патч через владельца рантайма

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

Не копируйте команду установки пакета из другой операционной системы или панели. Успешно выполнившаяся на вид команда может обновить не тот поток PHP или оставить обслуживающую службу нетронутой. На официальном сайте PHP указано, что дистрибутивы Linux и LTS-вендоры получили патчи заранее, поэтому статус пакета от конкретного вендора имеет решающее значение. (Бюллетень безопасности PHP)

После развертывания перезапустите или перечитайте конфигурацию (reload) соответствующих процессов PHP и веб-сервера, используя системный менеджер и процедуры вашей платформы. Убедитесь, что старые воркеры завершили работу. В инструкциях NCSC-NL также подчеркивается необходимость перезапуска воркеров при использовании временных мер защиты. Замены исполняемого файла на диске недостаточно, если долго работающий процесс все еще держит в памяти старый код. (Оперативное руководство NCSC-NL)

Шаг 4: Проверяйте обслуживающий процесс, а не только пакет

Используйте специфичную для вашей платформы проверку работоспособности (health check), которая определяет версию PHP через путь обслуживания веб-запросов. Например, приложение может предоставить временный диагностический эндпоинт с ограниченным доступом, который возвращает только версию рантайма и SAPI. Удалите его сразу после проверки. Не публикуйте общедоступную страницу  phpinfo() : она может раскрыть детали конфигурации и окружения, не связанные с данным патчем.

Для PHP-FPM проверьте пакет или образ пула, убедитесь в перезапуске службы и осмотрите список запущенных процессов. Для Apache  mod_php  проверьте модуль Apache и загружаемую им сборку PHP. Для контейнеризированных сервисов проверьте дайджест развернутого образа, а также рантайм внутри работающего контейнера. Для аппаратных устройств и управляемых сервисов используйте отчет о версии от вендора или его письменное подтверждение.

Ведите краткий журнал учета по каждому активу:

  • Пакет, дайджест образа, сборка устройства или обновление от вендора, содержащие исправление.
  • Служба или развертывание, которые были перезапущены или обновлены.
  • Результат пост-проверки, подтверждающий, что рабочий рантайм соответствует ожидаемой сборке.
  • Любые исключения, ответственные лица и дедлайны, если актив не удалось обновить.

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

Если обновление задерживается

Проект PHP описал временные меры по смягчению последствий, включая отключение прогресса загрузки сессий (session upload progress) и проверку таких параметров, как  memory_limit ,  post_max_size  и  fatal_error_backtraces  в PHP 8.5. В руководстве NCSC-NL прямо указано, что эти шаги не являются полноценным решением. Информационный бюллетень PHP от 23 октября также рекомендует задействовать  session.upload_progress.enabled=0  до выхода следующего регулярного багфикс-релиза для защиты от маловероятного дополнительного вектора RCE — CVE-2026-115560. В нем отмечается, что риск зависит от необычного сочетания настроек обработчика сессий и поведения приложения. (Бюллетень и обновление PHP, Руководство NCSC-NL)

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

Важен еще один оперативный нюанс: 3 ноября 2026 года Агентство кибербезопасности Сингапура выпустило предупреждение об активных атаках на выбранные сетевые продукты и продукты безопасности, включая сообщения о том, что злоумышленники объединяют PHP2Shell с отдельной уязвимостью в ядре Linux. Это не говорит о том, что каждая инсталляция PHP была скомпрометирована. Это повод изучить рекомендации конкретных производителей и проанализировать логи систем, которые могли подвергнуться воздействию. (Предупреждение CSA Сингапура)

Что меняет искусственный интеллект, а что — нет

В публичных отчетах упоминается более одного аудита с участием разных исследователей и различных моделей. Calif заявляет, что ее аудит выявил первые баги PHP2Shell. OpenAI утверждает, что GPT-5.6 Sol помогла идентифицировать критическую уязвимость. Позже Wiz сообщает об отдельном исследовании с использованием Gemini 4 Argon и GPT-5.6 Sol, причем модель Argon внесла существенный вклад. Это собственные заявления организаций об их исследованиях, а не независимые метрики объема работы, проделанной моделями. (Calif Research, OpenAI, Wiz)

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

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

Краткий контрольный список (чек-лист)

  •  Инвентаризация: охватите хосты, контейнеры, стейджинг, рантаймы панелей управления и аппаратные устройства.
  •  Определение режима работы: одна лишь версия CLI не указывает на PHP-FPM,  mod_php  или встроенный рантайм.
  •  Использование данных вендора: подтвердите наличие исправленных версий вышестоящего проекта или бэкпортов от производителя.
  •  Развертывание и перезапуск: обновите артефакт, обрабатывающий запросы, а затем убедитесь, что старые воркеры завершили работу.
  •  Проверка: проверяйте рабочий рантайм или вендорскую сборку, а не только сообщение об успешном завершении от пакетного менеджера.
  •  Учет исключений: назначьте ответственное лицо и дедлайн для всего, что осталось неизвестным или неисправленным.
  •  Анализ рисков: следите за бюллетенями для конкретных продуктов и расследуйте подозрительную активность там, где это необходимо.

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

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

А вы находили рантайм PHP там, где ваша обычная инвентаризация его не замечала? Какая проверка помогла его обнаружить?

Сохраните этот чек-лист для вашего следующего цикла установки патчей.

Источники: