Исследователи VulnCheck научились эксплуатировать критическую уязвимость PHP2Shell даже на серверах с включённой защитой памяти ASLR. Новый инструмент позволяет удалённо выполнять код без авторизации и работает сразу с несколькими версиями PHP, существенно расширяя возможности потенциальных атакующих.
Главным достижением стал обход защиты ASLR на 64-битных серверах x86-64. Механизм ASLR случайным образом меняет расположение программного кода и данных в оперативной памяти, мешая злоумышленникам заранее определить нужные адреса. Ранее подобная защита заметно осложняла создание надёжного эксплойта для PHP2Shell, особенно на обычных рабочих серверах.
Специалисты VulnCheck решили проблему с помощью цепочки из двух действий. Сначала эксплойт извлекает адреса из памяти уязвимого процесса, раскрывая информацию, которую ASLR должна скрывать. Затем полученные сведения помогают добиться удалённого выполнения произвольного кода. Первоначальную демонстрацию провели на PHP 8.4.26 с типовыми настройками рабочего сервера, включая отключённый вывод ошибок через display_errors=off.
К вечеру 22 октября исследователи расширили возможности инструмента. Обновлённый эксплойт успешно работал с PHP от 8.4.10 до 8.4.26 включительно без изменений под каждую отдельную версию. Результат принципиально отличается от демонстраций, рассчитанных на строго определённую конфигурацию памяти. При этом подтверждённая работоспособность пока ограничена указанным диапазоном PHP и проверенными условиями эксплуатации.
Отдельно VulnCheck проверила процессоры ARM64. Исследователи смогли воспроизвести утечку адресов памяти, однако добиться полноценного удалённого выполнения кода на такой архитектуре пока не удалось. Команда также обнаружила в открытом доступе демонстрационный эксплойт, который обходил ASLR на x86-64, но только с PHP 8.4.26 и стандартной конфигурацией динамической памяти. В других проверенных условиях публичный прототип не сработал.
Собственный более универсальный инструмент VulnCheck предоставила ограниченному кругу клиентов сервиса Initial Access Intelligence. Свободно скачать разработку нельзя. Исследователи предупреждают, что GitHub уже заполнили сотни репозиториев с якобы работающими эксплойтами PHP2Shell, хотя лишь небольшая часть опубликованного кода действительно использует уязвимости. Появление полноценного инструмента повышает вероятность разработки новых рабочих вариантов атак.
Масштаб потенциальной угрозы показывает отдельное исследование доступных из интернета серверов. VulnCheck обнаружила 2 608 039 узлов с признаками использования PHP. Из них 2 607 985, или 99,998%, специалисты сочли уязвимыми либо вероятно уязвимыми к PHP2Shell. Выборка охватывает инфраструктуру, которую исследовательская система смогла обнаружить и идентифицировать, поэтому не отражает точное количество всех PHP-серверов в интернете.
Из общего числа обнаруженных узлов 1 474 985 раскрывали версию PHP, которая оказалась старше соответствующего исправленного выпуска. Ещё 1 133 000 серверов не показывали номер версии, поэтому исследователи отнесли их к предположительно уязвимым. Такой подход не позволяет утверждать, что каждый сервер действительно можно взломать. Кроме того, поставщики Linux иногда переносят исправления в старые сборки PHP без изменения основного номера версии.
Особенно тревожная ситуация сложилась с устаревшими ветками PHP. Более 1,1 млн обнаруженных серверов, около 42% выборки VulnCheck, используют версии, для которых основной проект больше не выпускает стандартные исправленные релизы. Свыше 700 тысяч узлов работают на PHP от 3.x до 7.3, ещё почти 400 тысяч используют неподдерживаемые ветки 7.4, 8.0 и 8.1. Для последних трёх разработчики подготовили исправления исходного кода, однако администраторам необходимы соответствующие сборки от поставщиков либо самостоятельная установка патчей.
Самая опасная часть PHP2Shell связана с ошибками непосредственно в интерпретаторе PHP, а не в коде отдельных сайтов. Уязвимость CVE-2026-109618 возникает при неправильной обработке нехватки памяти. Специально сформированный запрос способен прервать работу PHP, когда внутренние структуры ещё не полностью подготовлены. Последующая очистка обращается к некорректным данным, что при определённых условиях позволяет атакующему перехватить управление процессом.
Вторая уязвимость, CVE-2026-109619, связана с сохранением ссылок на уже освобождённую память между запросами. Обе ошибки получили критическую оценку 9,2 балла по CVSS 4.0 и допускают удалённое выполнение кода без предварительной авторизации. Наибольший подтверждённый риск разработчики связывают с Apache и модулем mod_php, где вредоносный запрос может вызвать опасное состояние ещё до запуска кода самого сайта.
Практические попытки эксплуатации PHP2Shell начались до появления нового инструмента VulnCheck. Ещё 21 октября исследовательские ловушки компании зафиксировали сканирование серверов специально сформированными запросами. В одном случае с IP-адреса китайского провайдера попытались разместить на сервере веб-шелл, позволяющий выполнять команды через интернет. Атака завершилась неудачей, поскольку злоумышленник не смог прочитать подготовленный файл.
Другие системы наблюдения также фиксировали массовые попытки эксплуатации PHP2Shell. Однако результаты VulnCheck подтверждают техническую возможность обхода ASLR, а не массовые успешные взломы новым эксплойтом. Количество реально скомпрометированных серверов остаётся неизвестным. Разница между автоматическим сканированием, попыткой эксплуатации и успешным проникновением особенно существенна при оценке такой масштабной угрозы.
Разработчики PHP выпустили исправления 21 октября. Уязвимости устранены в PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Обновления необходимы не только серверам Apache с mod_php, но и системам с PHP-FPM, php-cgi, FrankenPHP и LiteSpeed. Владельцам сайтов на WordPress, Drupal, Joomla и других PHP-платформах недостаточно обновить движок или плагины, поскольку уязвимый компонент находится непосредственно на сервере.
Администраторам, которые не могут немедленно установить исправления, команда PHP предложила временные меры снижения риска. Для CVE-2026-109618 рекомендуется пересмотреть ограничения памяти и размеры входящих запросов, а для CVE-2026-109619 отключить отдельные механизмы обработки сессий и перезапустить рабочие процессы. Однако разработчики предупреждают, что подобные настройки перекрывают лишь известные пути эксплуатации и не заменяют полноценного обновления. После появления эксплойта, преодолевающего ASLR, рассчитывать только на штатную защиту памяти уже нельзя.