PHP часто воспринимают скорее как зависимость приложения, чем как среды выполнения, обращённую в интернет. Октябрьский релиз PHP2Shell 2026 года показывает, почему такое разграничение рушится. Две критические уязвимости в интерпретаторе PHP при определённых условиях могут привести к неаутентифицированному удалённому исполнению кода (RCE), а уязвимый компонент может присутствовать в контейнерах, шаред-хостинге, бессерверных (serverless) образах и долгоживущих виртуальных машинах.

21 октября 2026 года проект PHP выпустил исправления в версиях PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Этими двумя уязвимостями являются CVE-2026-109618 и CVE-2026-109619. Обе актуальны для веб-приложений, поскольку интерпретатор обрабатывает данные запроса ещё до того, как сработает собственная логика авторизации приложения.

CVE-2026-109619 описывается как проблема устаревшего глобального состояния (stale-global-state): внутреннее состояние, принадлежащее запросу, может сохраняться после освобождения выделенной под него памяти. CVE-2026-109618 связана с повреждением памяти при обработке ошибок нехватки памяти (out-of-memory). Точные условия для эксплойта не являются универсальными для каждого PHP-запроса, но последствия для безопасности достаточно серьезны, чтобы затронутые рантаймы требовали приоритетной обработки.

26 октября 2026 года CISA добавила обе уязвимости — CVE-2026-109618 и CVE-2026-109619 — в свой каталог известных эксплуатируемых уязвимостей (Known Exploited Vulnerabilities). Статус активно эксплуатируемой уязвимости меняет формат реагирования с плановой установки патчей на активное предотвращение инцидентов.

Патчите интерпретатор, а не только приложение

Самая распространенная ошибка — обновить плагин для CMS, оставив при этом старый рантайм PHP. PHP может быть установлен на уровне операционной системы, входить в состав базового образа контейнера, предоставляться хостинг-провайдером или быть скомпилирован в кастомный образ. В инвентаризации приложений может быть указано, что запущен WordPress, Drupal или кастомный сервис, но неизвестно, какой именно бинарник PHP выполняет запрос.

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

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

Третья проблема не входит в состав этого же исправления

23 октября 2026 года проект PHP опубликовал информационный бюллетень по CVE-2026-115560, касающейся отслеживания прогресса загрузки файлов в сессиях (session upload progress). В канадских и европейских бюллетенях отмечается, что эта проблема не устраняется обновлениями от 21 октября. Это различие имеет значение. Система может быть полностью пропатчена против CVE-2026-109618 и CVE-2026-109619, но при этом требовать отдельной конфигурации или более позднего обновления для проблемы с session upload progress.

Для CVE-2026-115560 опубликованное решение заключается в установке  session.upload_progress.enabled=0 , если приложению не требуется эта функция. Примените это изменение ко всем соответствующим пулам PHP-FPM и перезапустите воркеры. Следуйте текущим рекомендациям проекта PHP, прежде чем решать, достаточно ли этой настройки для конфигурации вашей организации.

Обнаружение и реагирование

Проверьте логи веб-сервера и PHP-FPM на предмет сбоев (crashes), перезапусков воркеров, аномальных тел запросов и необычного поведения дочерних процессов во временном окне публичного раскрытия информации. Логи приложений могут показывать, что запрос доходит до участка кода, которым он не должен управлять. Телеметрия среды выполнения контейнеров может зафиксировать неожиданный запуск shell, запись файлов или сетевое соединение со стороны воркера PHP.

Если есть подозрение на компрометацию хоста, сохраните артефакты процессов, памяти, контейнеров и сети перед его пересборкой. Смените секреты приложений, учетные данные баз данных, ключи сессий и любые облачные учетные данные, доступные процессу PHP. Проверьте систему на наличие закрепления (persistence) в задачах cron, юнитах systemd, файлах auto-prepend в PHP, веб-шеллах и слоях контейнеров.

Отбросьте аргументы о том, что приложение находится «за авторизацией». Эти уязвимости могут быть активированы до того, как приложение аутентифицирует пользователя. Лучшими мерами оперативного контроля являются пропатченный рантайм, маршрут запроса, исключающий выполнение уязвимого кода с недоверенными данными, и мониторинг правил исходящего трафика (egress policy), ограничивающий возможности скомпрометированного воркера.

Источники