PHP2Shell: экстренные патчи для двух критических уязвимостей в PHP — что делать прямо сейчас

21 октября 2026 года команда PHP выпустила экстренные обновления для двух критических уязвимостей удалённого выполнения кода (RCE), получивших общее название PHP2Shell. Уязвимости CVE-2026-109618 и CVE-2026-109619 находятся в самом движке PHP, а не в каком-либо приложении, поэтому уязвим любой сервер, обрабатывающий веб-запросы через PHP — включая PHP-FPM, Apache mod_php, php-cgi, FrankenPHP и LiteSpeed. Обе уязвимости оценены в 9,2 балла по CVSS v4.0 и позволяют неаутентифицированному атакующему выполнить произвольный код. Исправления доступны в версиях PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35 — обновление рантайма является единственным полноценным решением.

Технические детали уязвимостей

Обе уязвимости относятся к классу Use After Free (CWE-416), но эксплуатируют разные механизмы внутри PHP.

CVE-2026-109618 — RCE через повреждение памяти при обработке ошибки нехватки памяти (OOM). Согласно официальному advisory, PHP использует longjmp() для обработки OOM-ошибок, и в определённых контекстах запрос может быть прерван, когда внутренние данные ещё не полностью инициализированы. При этом процедура завершения запроса обрабатывает невалидные данные как корректные. В конфигурации Apache mod_php это особенно опасно: процедура shutdown вызывается безусловно даже при неудачном старте запроса, а автоматический парсинг тела запроса может исчерпать лимит памяти до того, как начнёт выполняться код приложения.

CVE-2026-109619 — RCE через устаревшее глобальное состояние. Как указано в advisory, внутреннее состояние, принадлежащее запросу, может сохраниться после освобождения памяти. Последующий запрос, обработанный тем же воркером, может использовать это устаревшее состояние до того, как штатная инициализация его сбросит. Подтверждено выполнение кода через путь fatal backtrace на mod_php и через жизненный цикл сессий как на mod_php, так и на PHP-FPM.

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

Затронутые версии и конфигурации

Уязвимы все версии PHP ниже 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Уязвимый код присутствует в PHP более десяти лет, затрагивая версии вплоть до PHP 5.4. PHP выделяет Apache mod_php как конфигурацию с наивысшим подтверждённым риском: для CVE-2026-109618 продемонстрирован эксплойт, срабатывающий до выполнения любого кода приложения. PHP-FPM также подвержен: для CVE-2026-109619 подтверждён путь эксплуатации через жизненный цикл сессий.

Реакция отрасли

Ещё до выхода патчей Cloudflare, по данным CTO компании Дейна Кнехта, зафиксировала ранние попытки эксплуатации и развернула экстренные правила WAF, назвав их временной мерой. При этом ни один источник не подтвердил успешного взлома. Компания watchTowr, воспроизводившая CVE-2026-109618, по состоянию на 11:26 UTC 21 октября не зафиксировала эксплуатации в дикой природе. По данным Huntress, публичный код эксплойта на момент публикации их отчёта также не был доступен.

Ряд организаций превентивно отключил сервисы. BambooHR приостановил работу в США, Канаде и Ирландии, предупредив о перебоях в обработке зарплат. В Нидерландах были отключены государственные порталы MijnOverheid, DigiD, сайт нижней палаты парламента, национальный центр кибербезопасности и ряд образовательных систем.

Почему настройка session.upload_progress.enabled — не защита

До выхода патчей в сообществе активно распространялась рекомендация установить session.upload_progress.enabled=0 как обходное решение. Токийская компания GMO Flatt Security первоначально предложила эту меру, но позднее отозвала рекомендацию, заявив, что настройка сама по себе не является полноценным исправлением и ожидаются способы её обхода.

Разработчик ядра PHP Джина Питер Банъярд написала прямо: «Единственное, что я могу сказать — единственная мера защиты — это обновление PHP. К сожалению, я знаю слишком много».

Выпущенные advisory подтвердили: отключение session.upload_progress.enabled блокирует лишь подтверждённые пути эксплуатации CVE-2026-109619 через сессии, но не покрывает другие варианты и никак не влияет на CVE-2026-109618. Компания watchTowr оценивает изменения INI-файлов как неэффективные для предотвращения эксплуатации.

Рекомендации по обновлению и временным мерам

Обновление рантайма PHP — единственное полноценное решение. Необходимо обновить именно тот PHP, который обслуживает веб-запросы (PHP-FPM, mod_php или CGI), а затем перезапустить Apache, PHP-FPM и все долгоживущие воркеры. Обновление приложений (WordPress, Laravel и т.д.) не обновляет PHP-рантайм.

Если немедленное обновление невозможно, согласно официальному advisory PHP, следующие меры снижают риск по конкретным путям атаки, но не делают сервер безопасным:

• Для CVE-2026-109618: установить memory_limit=-1 так, чтобы приложения не могли переопределить значение; держать post_max_size низким; применить ограничения размера запросов на уровне веб-сервера или прокси. PHP предупреждает: не используйте RLIMIT_AS или RLIMIT_DATA как замену — они могут активировать тот же уязвимый путь.
• Для CVE-2026-109619: установить session.upload_progress.enabled=0 и перезапустить все воркеры; на PHP 8.5 дополнительно установить fatal_error_backtraces=0.
• Изоляция: CERT-EU рекомендует рассмотреть изоляцию интернет-доступных PHP-приложений от публичных сетей до установки патча — через VPN, списки разрешённых клиентов или аутентификацию на периметре.
• Минимизация последствий компрометации: сократить объём данных на сервере, убрать сохранённые учётные данные и облачные роли, снизить привилегии, обеспечить ведение логов в защищённом хранилище.

Неподдерживаемые версии PHP

PHP 8.1 и старше не получают обновлений от проекта PHP. Однако, учитывая критичность уязвимостей, команда безопасности PHP опубликовала минимальные бэкпорты исходного кода для PHP 7.4, 8.0 и 8.1. Дистрибутивы Linux и LTS-вендоры могут предоставить собственные исправления — проверяйте changelog пакета на наличие CVE, а не номер версии, как рекомендует Debian.

Обнаружение и мониторинг

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

Исследователи, обнаружившие уязвимости, рекомендуют после обновления проверить логи на наличие: необычных multipart-запросов, сопровождаемых ошибками лимита памяти или повторяющимися HTTP 500; аномально больших cookie PHPSESSID в ответах; необъяснимых перезапусков PHP-воркеров.

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