OrcaCyber Research — PHP2Shell: как неудачный запрос превратился в удалённое выполнение кода

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

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

Ключевые доказательства на первый взгляд

• Цель — PHP 8.4.26, Apache/mod_php, один воркер, изолированная Docker-лаборатория.

• Журналы сбоев — Один выход рабочего процесса с SIGABRT и три с SIGSEGV в предоставленном фрагменте.

• HTTP-ответ — 819 200 байт в значении PHPSESSID, декодированном из URL.

• Доказательство выполнения — code>uid=33(www-data) gid=33(www-data) groups=33(www-data)/code>.

• Регрессия — В отчёте описаны четыре неудачные попытки на пропатченном PHP 8.4.27; необработанные запуски не прилагаются.

Источник: загруженные файлы REPORT.md, crash_evidence.log, leak_attempt.resp и rce_proof_8426.txt. Описанные ниже экспонаты воспроизводят эти артефакты в виде сверстанных панелей доказательств; это не фотографии и не нативные скриншоты терминала.

1. Уязвимость: нарушение принадлежности на границе запроса

Две связанные проблемы касаются прерванной инициализации запроса и устаревших глобальных указателей времени выполнения. В соответствующей архитектуре PHP обработка multipart/form-data и обратные вызовы прогресса загрузки сессии могут выполняться раньше обычного кода пользовательского приложения. Исключительный переход потока управления, включая code>zend_bailout()/code>, может пропустить ожидаемую очистку и оставить состояние указывающим на память, которая позже будет освобождена или повторно использована.

Инвариант безопасности: ссылка уровня worker (worker-global), доступная запросу B, никогда не должна указывать на память, владение и время жизни которой завершились вместе с запросом A. Сообщённый сбой нарушает этот инвариант.

Продемонстрированный эндпоинт представлял собой минимальную PHP-страницу, которая просто возвращала OK; сценарий эксплойта не зависел от эндпоинтов SQL-инъекции, включения файлов или десериализации на уровне приложения.

2. Техническая последовательность

• A1 — прерывание.Обработка multipart и прогресса загрузки вызывает OOM во время очистки, оставляя устаревшее состояние сессии.

• B1 — утечка. Последующий запрос приводит к тому, что при сериализации cookie сеанса происходит чтение за пределами допустимого идентификатора сеанса.

• Восстановление адресов. Утёкшие значения указателей используются для вывода о соответствующей раскладке библиотек и кучи в этой сборке.

• A2/B2 — повреждение. Еще одна последовательность из двух запросов формирует и перенаправляет устаревшие данные, используемые при завершении работы.

• Результат. Адаптированный публичный эксплойт сообщает о выполнении команд от имени www-data.

Экспонаты доказательств: что на самом деле показывают предоставленные файлы

Доказательство A — завершение воркера по данным журнала Apache

• code>[core:notice] [pid 1:tid 1] AH00051: дочерний процесс с pid 54 завершился по сигналу Abort (6), возможен дамп памяти в /etc/apache2/code>

• code>[core:notice] [pid 1:tid 1] AH00051: дочерний процесс pid 55 завершился по сигналу Segmentation fault (11), возможен coredump в /etc/apache2/code>

• code>[core:notice] [pid 1:tid 1] AH00051: child pid 58 exit signal Segmentation fault (11), possible coredump in /etc/apache2/code>

• code>[core:notice] [pid 1:tid 1] AH00051: дочерний процесс pid 61 завершился по сигналу Segmentation fault (11), возможен coredump в /etc/apache2/code>

Набранный фрагмент из crash_evidence.log (23 октября 2026 г.). Множественные завершения рабочих процессов свидетельствуют о нарушении безопасности памяти; сами по себе падения не доказывают RCE.

Приложение B — HTTP-ответ с аномальным cookie сессии

• code>HTTP/1.1 200 OK/code>, двоичные данные опущены.

• code>Сервер: Apache/2.4.69 (Debian)/code>

• code>X-Powered-By: PHP/8.4.26/code>

• code>Set-Cookie: PHPSESSID=[двоичные данные опущены]/code>

• Длина закодированного cookie: 2 330 754 байта.

• Значение после URL-декодирования: 819 200 байт.

Значение вычислено непосредственно из leak_attempt.resp. Двоичное значение намеренно опущено, чтобы избежать воспроизведения любого утёкшего содержимого процесса.

Приложение C — доказательство исполнения

code>uid=33(www-data) gid=33(www-data) groups=33(www-data)/code>

Точное содержимое файла rce_proof_8426.txt в том виде, в каком он был предоставлен. Оно подтверждает заявленный результат выполнения, но не является полной стенограммой команд/сеанса.

Приложение D — исправление жизненного цикла сессии

• code>static inline void php_rinit_session_globals(void)/code>

• code>@@ -121,6 +120,7 @@ static inline void php_rinit_session_globals(void)/code>

• code>* повторно кодирует сеанс при запуске запроса, до RINIT, когда нет пользователя/code>

• code>/* Выполняется до RINIT: пользовательский код не должен вызываться, см. php_session_unserialize_init() *//code>

• code>/* Это выполняется до RINIT, поэтому нам нужно очистить их заранее *//code>

• code>php_rinit_session_globals();/code>

Выбранные строки диффа исходного кода из session.c.diff. Это изменение явно сбрасывает глобальное состояние сессии раньше, чем обычный RINIT.

3. Почему доказательства важны

Раскрытие памяти обеспечивает мост между падением процесса и цепочкой эксплуатации. Значение сессии аномального размера со встроенными бинарными данными согласуется с тем, что среда выполнения интерпретирует недопустимую память как строку Zend. В исследовательском отчёте далее описывается извлечение адресов кода и кучи из окна утечки. Набор доказательств содержит необработанный ответ, но не отдельный скрипт, доказывающий каждый восстановленный адрес.

Артефакт RCE показывает контекст безопасности www-data. Он не означает получение root-доступа, компрометацию продуктивной среды или полную переносимость на произвольные развертывания PHP. Лабораторная конфигурация с одним воркером важна, поскольку последовательность запросов и привязка к воркеру влияют на механизм.

4. Исправление самой проблемы жизненного цикла, а не только её симптома

Представленный исходный diff для коммита PHP-патча 01a40e89fbfc («Avoid state corruption via bailout») показывает раннюю инициализацию глобальных переменных сессии, изменения в обработке OOM в аллокаторе и более широкую логику сброса/очистки. Эти изменения направлены на то, чтобы нативное состояние не оставалось в недопустимом состоянии после прерывания запроса. Исправление только пути кодирования cookie само по себе не восстановило бы эту гарантию владения памятью.

В исследовательском отчёте утверждается, что попытки в отношении PHP 8.4.27 в четырёх испытаниях не дали аномального cookie, сбоя или доказательства RCE. Фактические записи исправленной версии отсутствуют в этом пакете, поэтому это сравнение приводится как наблюдение исследователя, а не как независимо проверяемый экспонат.

5. Защитные действия

• Немедленно. Обновите затронутую поддерживаемую ветку PHP до выпуска с исправлениями безопасности и используйте уведомления поставщика, чтобы подтвердить точный статус пакета.

• Снижение риска воздействия. Рассмотрите возможность ограничения multipart-входных данных и отключения code>session.upload_progress/code>, если они не используются; эти меры не заменяют патч.

• Обнаружение. Проверяйте сбои при инициализации запроса, неожиданные ошибки 500 и слишком большие code>Set-Cookie/code> заголовки ответа.

• Гарантия. Повторно протестируйте с пулами воркеров, репрезентативными для продакшена, и убедитесь, что старое состояние сессии не может сохраняться между запросами.

6. Методология исследования OrcaCyber

Ценная исследовательская задача заключается не только в выявлении отдельных небезопасных операций; она состоит в прослеживании полного нарушения инварианта через разбор запросов, поведение аллокатора, постоянные нативные глобальные переменные, сериализацию и завершение работы. OrcaCyber Zero и OrcaCyber Ultra использовались для создания PoC в этом исследовании, как указано исследовательской группой. Публичный набор артефактов поддерживает техническое воспроизведение, но не предоставляет трассировки выполнения по каждой модели и не доказывает автономное обнаружение уязвимостей.

Лестница доказательств: гипотеза об исходном коде → достижимый триггер → сбой во время выполнения → раскрытие информации → доказательство выполнения → регрессия на исправленной версии. Такая последовательность даёт более высокую степень уверенности, чем описание уязвимости или результат, ограничивающийся только падением. Она также побуждает чётко сообщать о неопределённости, когда исходные файлы или журналы выполнения в сыром виде отсутствуют.

7. Область применения и ограничения

В этой публикации описывается авторизованная изолированная лаборатория Docker. Эксплойт основан на ранее опубликованном исследовании PHP2Shell; локальная адаптация задокументирована в предоставленном отчёте. Пакет включает скрипты, диффы, байты ответов, журналы и вывод доказательств, но не содержит полной рабочей копии upstream-эксплойта, нативных скриншотов и полных необработанных стенограмм регрессионного тестирования патчей. Никаких заявлений о компрометации реальных жертв или клиентов не делается.

Источники и артефакты

Основное: предоставлен php2shell-report-bundle.tar.gz (REPORT.md; report-CVE-2026-109618.md; report-CVE-2026-109619.md; crash_evidence.log; leak_attempt.resp; rce_proof_8426.txt; диффы исходного кода PHP). Публичный контекст: рекомендации по безопасности PHP GHSA-w8hw-w9fx-j79w и GHSA-6wmf-4rv5-p3rp; анонсы релизов безопасности PHP. Публичная атрибуция эксплойта: 9bie/php2shell-bypass-aslr-exp. Исследовательский репозиторий: orcacyber-php2shell-research.

Вывод: один запрос завершился неудачно; указатель сохранился; следующий запрос доверился ему. Самое сложное в понимании этой уязвимости — установить эту связь с помощью наблюдаемых доказательств.