Две уязвимости в PHP позволяют выполнить код на сервере от имени веб-процесса, и учётные данные для этого не нужны. Исправления вышли 21 октября в релизе безопасности организации PHP Foundation, обе проблемы объединены под названием PHP2shell. Splunk проверяет, затронуты ли его продукты этими уязвимостями. По текущим данным уязвимых продуктов у Splunk нет, часть продуктов ещё не проверена.
Две уязвимости памяти PHP и проверка продуктов Splunk
Уведомление Splunk SVD-2026-1013 от 22 октября относит к не подверженным уязвимости ряд продуктов: Splunk Cloud Platform, Splunk Enterprise, Universal Forwarder, Enterprise Security, SOAR, Observability Cloud, UEBA, AppDynamics On-Premises и AppDynamics PHP Agent. Под проверкой остаются Splunk OnCall, AppDynamics SaaS и Smartlook. Такой статус означает, что вендор выясняет, затронут ли продукт, и подтверждением уязвимости он не служит. Уведомление помечено как обновляемое, поэтому текущие списки не окончательные.
Первая уязвимость, CVE-2026-109618, связана с нехваткой памяти. При превышении заданного предела PHP аварийно прерывает обработку запроса и оставляет его память в некорректном состоянии, а процедура завершения запроса эти данные читает. Сбой выделения памяти не обязан быть связан с уже повреждённой областью: достаточно, чтобы он случился, пока память запроса не полностью инициализирована. Добраться до такого момента можно через составные запросы формы (multipart) - формат передачи данных с файлами, где число заголовков в части и вложенность полей не ограничены. Результат - выполнение кода на сервере.
Вторая уязвимость, CVE-2026-109619, относится к классу "использование после освобождения" (use after free), когда программа обращается к памяти, уже возвращённой системе. Рабочий процесс PHP (worker) хранит глобальные переменные: состояние ошибок, сессий, объектов и расширений. Они могут указывать на память одного запроса, и перед её освобождением эти переменные нужно сбросить. Неустранимая ошибка (fatal error) или предупреждение прерывают работу раньше сброса, и следующий запрос на том же worker читает освобождённые данные. Для эксплуатации нужны две операции: одна оставляет состояние запроса в глобальной области, вторая обращается к нему до обычной инициализации.
Числовой оценки CVSS в уведомлениях нет, указан только уровень Critical. Атака идёт по сети, учётные данные и участие пользователя не требуются, при этом сложность атаки высокая и нужны дополнительные условия. Вендор подтвердил неаутентифицированное выполнение кода с правами учётной записи веб-сервера. Сценарий проверен по HTTP на Apache mod_php со стандартными настройками памяти, а также на FPM. Сведений об эксплуатации в реальных атаках нет: публикация деталей означает доступность технической информации, а не применение в атаках.
Исправления вышли в PHP 8.2.35, 8.3.36, 8.4.27 и 8.5.12, более ранние выпуски этих ветвей уязвимы. Splunk собственного исправления не выпускал. Пока идёт проверка, администраторам остаётся отслеживать уведомление SVD-2026-1013 и версии PHP на своих узлах.
Полностью устраняет обе проблемы только обновление PHP. Если обновиться нельзя, остаются частичные конфигурационные меры. Для первой уязвимости снимают предел памяти (memory_limit=-1) административно и перезапускают все worker, проверив, что ни пул, ни каталог, ни настройки приложения не возвращают конечный лимит. Для второй отключают трассировки при неустранимых ошибках (fatal_error_backtraces) в PHP 8.5 и отчёты о ходе загрузки файлов (session.upload_progress).
Составные запросы формы, которые приложение не использует, блокируют на входном узле до передачи в PHP. Умеренный предел размера тела запроса (post_max_size) и ограничение числа частей, заголовков и загрузок снижают риск отказа в обслуживании, но обновление не заменяют. Пределы памяти контейнера не гарантируют защиту, а ограничения RLIMIT_AS и RLIMIT_DATA применять нельзя: при достижении лимита они сами вызывают сбой выделения памяти.
Обе уязвимости требуют сетевого доступа и высокой сложности атаки, но обходятся без учётных данных. Для Splunk риск пока ограничен продуктами под проверкой, а полной мерой остаётся обновление PHP до версии с исправлением. Подтверждённый сценарий связан с Apache mod_php, поэтому узлы с этой связкой обновляют в первую очередь.
Ссылки
- https://advisory.splunk.com/advisories/SVD-2026-1013
- https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
- https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
