PHP2Shell: Попытки эксплуатации и тенденции устранения уязвимостей

На прошлой неделе мы опубликовали отчет, описывающий две крупные уязвимости в PHP (CVE-2026-109618, CVE-2026-109619). С тех пор команда Wiz Research, наряду со значительной частью индустрии безопасности, ведет мониторинг связанной активности «дикой» природе и изучает общедоступный код эксплойтов. На данный момент в нашей телеметрии зафиксировано лишь ограниченное число попыток эксплуатации, при этом мы не обнаружили общедоступных концептов доказательства уязвимости (PoC), демонстрирующих полную сквозную эксплуатацию против произвольной цели. Тем не менее, некоторые партнеры конфиденциально поделились с нами эксплойтами, работающими против различных целей, и мы продолжаем внутренние эксперименты. Видеозаписи, демонстрирующие успешные результаты нашей эксплуатации, доступны по адресу php2shell.com.

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

Мы продолжим следить за развитием событий и обновлять эту публикацию по мере появления новых данных.

Тенденции наблюдаемой подверженности угрозам

После публичного раскрытия уязвимости PHP2Shell 21 октября 2026 года телеметрия Wiz за последние несколько дней зафиксировала сокращение ежедневного числа уникальных доступных из интернета машин, уязвимых к PHP2Shell, примерно на 67%. Кроме того, среди уязвимых машин, доступных из интернета, доля устройств под управлением PHP версии 7.3 или более ранних снизилась за пятидневный период с 8.3% до 5.7%. Этот показатель отражает долю наблюдаемой совокупности устройств со старыми версиями, для которых не выпускались официальные бэкпорты.

За этот же период количество существенно затронутых организаций (под которыми здесь понимаются компании хотя бы с одним доступным и уязвимым экземпляром) сократилось примерно на 47.9% (см. график ниже). Для справки: наши данные показывают, что сам PHP используется 65% организаций из нашего набора данных.

В совокупности эти наблюдения говорят о том, что организации массово снижают свою подверженность рискам за счет комбинации патчинга, обновления ПО, вывода из эксплуатации затронутых машин и ограничения доступа из интернета (обратите внимание, что эти данные отражают общую тенденцию, но не определяют относительный вклад каждой стратегии устранения уязвимостей; охват сканирования и размер наблюдаемой совокупности также могут влиять на общие показатели с течением времени).

Попытки эксплуатации, зафиксированные исследователями Wiz

На сегодняшний день в этом контексте мы зафиксировали следующие виды активности:

• Попытки использования механизма эксплуатации PHP2Shell с методами, совпадающими с публичными PoC.

Попытки использования механизма эксплуатации PHP2Shell с методами, совпадающими с публичными PoC.

• Инструменты с брендингом PHP2Shell, не связанные с самими уязвимостями, но использующие отравление сессий и отдельную уязвимость локального включения файлов (LFI) в приложении.

Инструменты с брендингом PHP2Shell, не связанные с самими уязвимостями, но использующие отравление сессий и отдельную уязвимость локального включения файлов (LFI) в приложении.

Попытки использования механизма эксплуатации PHP2Shell

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

Вариант 1: устаревшая цепочка

Первый запрос к нашему ханейпоту PHP-CGI поступил с адреса 3.37.227[.]134. Он соответствовал более старой цепочке из набора инструментов, найденной в archive/legacy-8m/exploit.py и сопутствующих скриптах этапов. Первый полный этап эксплойта использовал тело multipart с 1,005 частями, включая поле с именем big, заполненное примерно 12 МБ заполнителя:

Согласно примечаниям к инструментарию, этот этап пытается исчерпать память во время сброса сессии, оставляя состояние сессии доступным для последующего запроса.

На нашем ханейпоте выполнение завершилось с ошибкой до того, как этот код был достигнут. Заявленный размер запроса превысил настроенный лимит post_max_size в 8 МБ, поэтому PHP пропустил обработку тела multipart и записал в лог:

С тех пор автор переместил эту цепочку в архивную директорию инструментария.

Последующая попытка атаки на Roundcube

В ходе более поздней попытки адрес 103.151.172[.]95 отправил более длинную последовательность из устаревшей цепочки. Она включала зависшие соединения, предназначенные для загрузки других воркеров Apache.

Когда был доступен только один воркер, эксплойт попытался сформировать кучу (heap-shaping), отправив запросы, содержащие 1,001 поле размером по 3,000 байт каждое. Эти запросы не вызвали необходимый процесс исчерпания памяти. Таким образом, нет никаких доказательств того, что эта попытка достигла требуемого состояния исчерпания памяти.

Вариант 2: актуальная цепочка

Большинство зафиксированных нами IP-адресов использовали более новую цепочку, состоящую из pure/mk_a1.py и pure/mk_leak_b.py. Мы наблюдали этот вариант в нескольких попытках.

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

Сервер записал фатальную ошибку, указывающую на то, что PHP достиг своего лимита, например:

Удержание запросов на том же воркере

Цепочка зависит от того, чтобы последовательные запросы эксплойта попадали в один и тот же дочерний процесс Apache. Чтобы повысить вероятность этого, набор инструментов пытается занять остальные воркеры незавершенными запросами. Каждое соединение заявляет большое тело, отправляет один байт и зависает:

Один адрес, 178.249.214[.]6, открыл 399 таких соединений наряду с 400 GET-запросами перед отправкой этапов эксплойта. Этот адрес является выходным узлом VPN, что ограничивает возможности выводов об источнике.

Этап A1: вызов исчерпания памяти

A1 представляет собой многочастный (multipart) запрос с фрагментированной передачей (chunked), содержащий идентификатор сессии с нулевым байтом, 860 пустых файловых частей с длинными именами в виде глубоко вложенных массивов и несколько групп полей заполнения:

Запрос разработан для исчерпания памяти во время обработки сеанса в момент, когда идентификатор сессии может указывать на освобожденную память.

Каждый перехваченный нами запрос A1 возвращал ошибку HTTP 500, сопровождаемую ошибкой PHP следующего вида:

Это подтверждает, что A1 достиг намеченного состояния исчерпания памяти на нашем ханейпоте. Само по себе это не подтверждает, что устаревшее состояние сессии, необходимое для следующего этапа, было сохранено.

Этап B1: попытка утечки памяти

B1 последовал примерно секунду спустя. Был отправлен еще один многочастный запрос с фрагментацией, содержащий PHPSESSID=a, PHP_SESSION_UPLOAD_PROGRESS=k0 и два крупных поля заполнения.

Если этот запрос достигает того же воркера до того, как PHP сбросит устаревшее состояние сессии, PHP может записать содержимое восстановленной кучи в ответный cookie PHPSESSID. Затем набор инструментов извлекает из этого cookie адреса кучи и libphp для подготовки финального этапа эксплойта.

Мы не зафиксировали подобной утечки. Во всех запусках, кроме одного, соединение закрывалось без ответа. Оставшийся запуск вернул обычный 32-символьный файл cookie сеанса. Ни один из источников не отправил финальный этап эксплойта.

Почему утечки могли не удасться

Неудавшиеся утечки подчеркивают более широкую проблему: создать обобщенный эксплойт, который надежно работает в разных версиях PHP и конфигурациях развертывания, сложно. Макет B1 эксплойт-кита был рассчитан на официальный образ php:8.4.26-apache с лимитом памяти 128 МБ. Другие экземпляры, такие как наш ханипот Roundcube, запускали ту же версию PHP из другой сборки, с дополнительными расширениями и лимитом памяти 64 МБ. Эти различия могут влиять на структуру кучи (heap layout) и повторное использование памяти, потенциально мешая утечке работать должным образом.

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

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

Другие попытки

Мы также зафиксировали неудачные попытки эксплойтации с IP-адресов 15.204.59[.]70 и 162.35.99[.]94, однако эти сканеры успешно взломали ханипот Аделя Карими (Adel Karimi), что, вероятно, стало одним из факторов, повлиявших на решение CISA include PHP2Shell in their KEV list.

Инструменты под брендом PHP2Shell, не связанные с уязвимостями

Мы также наблюдали инструменты с пометкой PHP2Shell, которые на самом деле не пытались использовать ни одну из уязвимостей. Самый ранний подобный трафик с адреса 85.11.187[.]35 соответствовал порту на Go для «Цепочки A» из WoYinDao/CVE-2026-109618-CVSS-9.2-Critical.

Инструмент использовал давнюю технику отравления сессий (session-poisoning), пытаясь записать PHP-код в файл сессии с помощью функции upload-progress. Приведенный ниже запрос сокращен:

Затем он попытался выполнить этот код путем включения (include) файла сессии:

Что особенно важно, lfi_sink.php — это уязвимая конечная точка, предоставляемая лабораторной средой PoC. Инструмент предполагает, что эта конечная точка существует на цели; без нее или эквивалентной уязвимости локального включения файлов (LFI) цепочка не сможет выполнить код.

Вариант с выравниванием (padded variant) спровоцировал срабатывание нашего детектора исчерпания памяти, однако успешного выполнения кода мы не зафиксировали. Несмотря на брендинг PHP2Shell, эта активность опиралась на несвязанную технику и уязвимую конечную точку приложения.

Заключение

В нашей телеметрии мы пока не наблюдали успешной сквозной эксплойтации PHP2Shell. Тем не менее, публичный отчет Аделя Карими и сопутствующие данные предоставляют самые надежные публичные доказательства из всех, что мы видели на сегодняшний день, связывая воедино трафик эксплойта, раскрытие памяти и последующее выполнение кода на его ханипотах. Примечательно, что те цели использовали благоприятную конфигурацию Apache mod_php с одним воркером, поэтому полученные результаты не гарантируют надежность в других средах развертывания.

Наши наблюдения показывают, что само по себе исчерпание памяти не является достаточным для завершения цепочки эксплойта. Различия в сборках PHP, лимитах памяти и поведении воркеров могут помешать работе последующих этапов. Проблема для оппортунистических злоумышленников заключается в превращении доступных в настоящее время публичных PoC в столь же надежный рабочий инструментарий или в разработке такового своими силами. По нашему мнению, PHP2Shell остается риском как в краткосрочной, так и в долгосрочной перспективе, поэтому применение обновлений безопасности PHP или устранение уязвимостей другими средствами по-прежнему остается необходимым.

Индикаторы компрометации (IOC)