PHP выпустила экстренные обновления 8.5.12, 8.4.27, 8.3.36 и 8.2.35, закрывающие две критические уязвимости PHP2Shell с оценкой 9,2 по CVSS v4.0. Они позволяют неавторизованному атакующему выполнить код на веб-сервере ещё до запуска логики сайта — неприятный сценарий для любого проекта, где PHP живёт не только в старом WordPress, но и в платёжных, корпоративных и клиентских системах.
Проблемы получили идентификаторы CVE-2026-109618 и CVE-2026-109619. Как пишет The Hacker News, уязвимы практически все ветки PHP, начиная с PHP 5.4, а ранние попытки эксплуатации уже фиксировали Cloudflare и watchTowr. Под ударом находятся не отдельные CMS или фреймворки, а сам рантайм: обновление Laravel, WordPress или собственного приложения не закроет дыру, если сервер продолжает исполнять старый PHP.
PHP2Shell затрагивает установки, обрабатывающие веб-запросы через PHP-FPM, Apache mod_php, php-cgi, FrankenPHP и LiteSpeed. Наиболее опасным вариантом разработчики PHP называют Apache с mod_php: для него продемонстрирован сценарий, в котором один HTTP-запрос без учётной записи приводит к выполнению кода ещё до того, как приложение успеет отработать маршрутизацию, аутентификацию или собственные проверки. Иными словами, качественно написанный код сайта не даёт здесь привычной страховки: проблема находится уровнем ниже.
У атакующего есть и менее шумный путь. Исследователи показали возможность читать память рабочего процесса PHP. В ней могут оказаться пароли, токены сессий, API-ключи и сертификаты, оставшиеся от других запросов. Для такого чтения памяти не обязательно сначала добиваться удалённого выполнения кода. Для многопользовательских сервисов, внутренних порталов и систем с длинным списком интеграций это отдельный повод относиться к инциденту не как к очередной записи в changelog.
Патчить рантайм, а не приложение
Полная защита одна: установить исправленную версию PHP и перезапустить Apache, PHP-FPM и другие долгоживущие PHP-процессы. Без рестарта сервер может продолжать обслуживать запросы старыми воркерами. Для ветки 8.5 безопасной названа версия 8.5.12, для 8.4 — 8.4.27, для 8.3 — 8.3.36, для 8.2 — 8.2.35. PHP 8.1 и более старые ветки официально уже не поддерживаются; для 7.4, 8.0 и 8.1 опубликованы исходные бэкпорты, но это скорее аварийный мост для тех, кто собирает PHP самостоятельно или ждёт пакет от поставщика.
Администраторам Linux-серверов не стоит ориентироваться только на привычный номер пакета. Дистрибутивы и поставщики LTS нередко переносят патч в старую ветку, сохраняя её внешнюю версию. Проверять нужно changelog пакета и наличие в нём CVE-2026-109618 и CVE-2026-109619. В контейнерной инфраструктуре задача ещё прозаичнее: обновить базовый образ, пересобрать сервис, развернуть новую версию и убедиться, что в проде не остался старый образ с уязвимым интерпретатором.
Временные меры уменьшают риск только для отдельных путей атаки. Для CVE-2026-109618 команда PHP рекомендует запретить приложениям переопределять лимит памяти через memory_limit=-1, ограничить post_max_size и размер запроса на уровне веб-сервера или прокси. Использовать RLIMIT_AS или RLIMIT_DATA вместо этого нельзя: они способны задействовать тот же уязвимый путь. Для CVE-2026-109619 можно отключить session.upload_progress.enabled; в PHP 8.5 также предлагается выключить fatal_error_backtraces. Но эти настройки не делают сервер безопасным: отключение progress-индикатора загрузки блокирует подтверждённые сессионные сценарии, а не все варианты эксплуатации.
Утечка ускорила релиз, атаки уже начались
Планировалось раскрыть детали 22 октября, однако информация о двух CVE утекла 20 октября. PHP опубликовала предупреждение и перенесла выпуск исправлений на 21 октября, около 14:00 UTC. Уязвимости нашли Wiz Research, Calif и команда Codex Security компании OpenAI; в подготовке исправления также участвовала команда Google Gemini. Исследователи утверждают, что ИИ-модели помогли превратить старые дефекты в рабочие эксплойты быстрее: работа, которая раньше могла потребовать месяцы и команду специалистов, заняла у одного исследователя около недели. Это не история о «магическом взломе по запросу», а о снижении цены на рутинную и сложную исследовательскую работу.
До выхода патча Cloudflare сообщала о первых попытках атак и включила правила веб-защиты по умолчанию в 03:02 UTC 21 октября. Позже watchTowr также заявила, что наблюдает активные попытки эксплуатации обеих уязвимостей PHP2Shell. Подтверждённых сообщений о компрометации конкретного сервера на момент публикации не было, но некоторые организации временно отключали сервисы из предосторожности. В числе заметных примеров — BambooHR, а в Нидерландах временные ограничения затронули государственные и образовательные ресурсы.
После установки патча имеет смысл проверить телеметрию за предыдущие сутки: необычные multipart-запросы перед ошибками лимита памяти, повторяющиеся HTTP 500, аномально крупные cookie PHPSESSID и неожиданные перезапуски PHP-воркеров заслуживают отдельного разбора. Исправление добавляет жёсткий лимит памяти: при его достижении процесс завершается без запуска shutdown-обработчиков, поэтому параметры memory_limit и post_max_size стоит сверить с реальной нагрузкой приложения.
Главный вывод для команд здесь скучный, зато полезный: учёт PHP-версий должен быть частью управления инфраструктурой, а не разовой задачей при миграции фреймворка. Когда RCE живёт в движке и доступна до кода приложения, WAF и настройки могут лишь выиграть время. Реальную границу безопасности в этом случае проводит только обновлённый рантайм.
