Мы уже рассказывали о критических уязвимостях PHP2Shell и выпущенных исправлениях. После публикации патчей исследователи раскрыли дополнительные детали, сообщили о новом способе эксплуатации и обнаружили ещё одну уязвимость в PHP. Далее обо всем подробнее.
Новые детали об уязвимостях PHP2Shell
Один из векторов атаки связан с исчерпанием памяти при обработке multipart-запросов. Обработчик нехватки памяти может прервать работу интерпретатора с помощью longjmp() до полной инициализации внутренних структур запроса. При последующем завершении обработки PHP обращается к ним как к уже созданным, что может привести к удалённому выполнению кода.
Для обхода post_max_size атакующий может отправлять запрос без заголовка Content-Length и передавать большое количество HTTP-заголовков. Возможны и точечные атаки на приложения, потребляющие значительный объём памяти.
Подтверждённая эксплуатация CVE-2026-109618 продемонстрирована для mod_php. В PHP-FPM дочерний процесс обычно завершается при сбое, поэтому атака сложнее, но полностью не исключена.
К уже опубликованным рекомендациям добавляются следующие меры:
- для PHP 8.5 установить
fatal_error_backtraces=0; - ограничить память на уровне
cgroupили контейнера через memory.max; - не использовать для этого
RLIMIT_AS и RLIMIT_DATA; - при необходимости ограничить число запросов на один процесс с помощью
pm.max_requests=1в PHP-FPM иMaxRequestsPerChildв Apache; - устранить настройки и участки кода, вызывающие ранние диагностические сообщения, тайм-ауты и фатальные ошибки;
- дополнительно уменьшить
max_input_nesting_levelи при необходимости заблокироватьmultipart-запросы.
Нарушения эмбарго осложнили выпуск исправлений PHP
Проблему, связанную с исчерпанием памяти, выявили ещё в ходе внешнего аудита в 2024 году, но тогда её сочли теоретической. Подготовка исправления затянулась из-за споров о возможном влиянии на обратную совместимость и сторонние расширения.
В августе 2026 года Calif и Wiz независимо подтвердили рабочие способы эксплуатации. После этого уязвимостям присвоили высший приоритет.
Публикацию патчей перенесли с 22 на 21 октября после утечки сведений о CVE и дате релиза. Дополнительные детали стали доступны после ошибочной публикации Calif видеоролика с демонстрацией эксплойта. Позже Chainguard досрочно выпустила сборки с исправленной версией PHP, нарушив эмбарго.
На момент первоначального раскрытия универсального эксплойта не было: опубликованные прототипы зависели от конкретных сборок и конфигураций, а часть из них оказалась фиктивной.
Для PHP2Shell появился эксплойт с обходом ASLR
Исследователи VulnCheck заявили о первом эксплойте для CVE-2026-109618, обходящем ASLR. Он рассчитан на системы x86-64 с типовой конфигурацией PHP и версии PHP 8.4.10–8.4.26.
Эксплойт использует утечку адресов через механизм отображения ошибок. Сейчас к нему имеют доступ только клиенты, которые занимаются защитой информации, но злоумышленники могут использовать для воссоздания техники AI-инструменты. Поэтому, кроме ранее опубликованных рекомендаций, дополнительно советуют отключить вывод ошибок: display_errors=Off.
По данным VulnCheck, на GitHub появились сотни прототипов, но рабочими считаются лишь единицы. Cloudflare сообщила о миллионах попыток эксплуатации, а Amazon зафиксировала первые атаки в honeypot-системах ещё 17 октября. Подтверждённых случаев взлома через PHP2Shell пока не сообщалось.
В PHP обнаружили новую уязвимость
Новая уязвимость (CVE-2026-115560) потенциально позволяет удалённо выполнить код, но проявляется только при редком сочетании нестандартных настроек и особенностей PHP-кода.
Риск возникает, если session.serialize_handler установлен в php_binary или php_serialize, а затем до вызова session_start() изменяется через ini_set() на значение php.
В качестве временной меры рекомендуется отключить отслеживание прогресса загрузки: session.upload_progress.enabled=0
Параметр нужно задать в php.ini или конфигурации сервера до обработки запроса. Подробности и исправления обещают опубликовать в следующих релизах PHP.
