PHP Foundation раскрыла детали устранения уязвимостей PHP2Shell

PHP Foundation опубликовала технический отчёт о двух критических уязвимостях PHP2Shell — CVE-2026-109618 и CVE-2026-109619. Обе проблемы связаны с ошибками управления памятью и потенциально позволяют добиться удалённого выполнения кода без аутентификации. Уязвимости получили оценку CVSS 9.2.

Проблема затронула все версии PHP начиная с PHP 5, если они используются для обработки веб-запросов. В группу риска входят PHP-FPM, Apache mod_php, php-cgi, FrankenPHP и LiteSpeed. Разработчики оценили ситуацию как максимально опасную и призвали администраторов установить обновления: полное устранение уязвимостей возможно только после обновления PHP.

Две ошибки в работе с памятью

CVE-2026-109618 возникает при исчерпании доступной процессу памяти. Обработчик нехватки памяти с помощью longjmp может прервать интерпретатор в момент, когда внутренние структуры запроса инициализированы лишь частично. При последующем завершении обработки PHP обращается к этим структурам так, будто они уже существуют, что создаёт условия для выполнения произвольного кода.

Основным вектором атаки считаются специально сформированные multipart-запросы, провоцирующие исчерпание памяти. В частности, злоумышленник может передавать большое количество HTTP-заголовков без указания Content-Length или воздействовать на операции приложения, потребляющие значительный объём памяти. Наличие рабочего эксплойта подтверждено для mod_php. В PHP-FPM дочерний процесс обычно завершается после сбоя, поэтому атака затруднена, хотя полностью исключить её нельзя.

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

Для эксплуатации этой проблемы могут использоваться multipart-запросы и механизм session.upload_progress. Подтверждённый сценарий также связан с обработчиком fatal_error_backtraces в PHP 8.5, который не сбрасывает состояние трассировки при завершении запроса. В первом случае атака возможна на mod_php и PHP-FPM, во втором — только на mod_php. Отдельные потенциальные сценарии с ранним выводом предупреждений пока не подтверждены.

Почему исправление заняло два года

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

В середине 2026 года исследователи из компаний Calif и Wiz независимо друг от друга, используя системы GPT-5.6 и Gemini 4 Argon, нашли практические методы эксплуатации. Calif сообщила разработчикам PHP об одной из проблем 11 августа, а Wiz — 24 августа. После этого исправления получили высший приоритет.

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

Утечки и отсутствие массовых атак

Изначально публикацию исправлений планировали на 22 октября 2026 года, но после утечки 20 октября сведений о CVE-идентификаторах и времени релиза дату перенесли на 21 октября. Дополнительные сведения появились после того, как Calif по ошибке опубликовала видеоролик с демонстрацией эксплойта. Видео удалили, однако исследователи успели изучить его и начать создавать собственные прототипы атак.

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

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

Исследователи также обнаружили множество фиктивных эксплойтов, сгенерированных ИИ. Часть из них лишь имитировала атаку, другие зависели от ошибок конфигурации или работали только при наличии дополнительных критических уязвимостей. Для пользователей PHP основным способом защиты остаётся установка корректирующих выпусков: PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35, а также подготовленных патчей для веток PHP 7.4, 8.0 и 8.1.