PHP объявила, что выпустит исправления для двух критических уязвимостей удалённого выполнения кода, известных как PHP2Shell, 21 октября в 14:00 UTC. Оценка PHP — 9,2 из 10. На момент подготовки материала обновление ещё не вышло, а проект не раскрыл ни затронутые версии, ни уязвимый компонент, ни настройки, способные снизить риск. До публикации исправлений нельзя считать какую-либо меру гарантированной защитой: задача администраторов — сократить доступ к системе и подготовить быстрое обновление.
Cloudflare сообщила о первых попытках эксплуатации и включила экстренные правила для сайтов, проходящих через её сервис. Компания называет их временной мерой, а не заменой патча. Подтверждённых взломов в сообщениях нет; распространявшийся код эксплойта тоже не был доказанно работоспособным. На момент проверки 21 октября уязвимости не значились в каталоге известных эксплуатируемых уязвимостей CISA. watchTowr воспроизвела одну из них, но об атаках не сообщала. Исследователь опубликовал видео, которое, по его словам, показывает цепочку эксплуатации. При этом анонимный независимый аудит утверждает, что описанного бага в Session Upload Progress нет в выпущенных версиях PHP, а опубликованный proof of concept на них не работает. Эта картина может измениться быстро.
Отдельное предупреждение гласит: «PHP предупреждает о ещё одной неисправленной уязвимости RCE — CVE-2026-115560». Дополнительных сведений об этой уязвимости в материале нет, поэтому связывать её с PHP2Shell нельзя.
В соцсетях и блогах распространяли настройку session.upload_progress.enabled=0. Она отключает Session Upload Progress — функцию PHP, включённую по умолчанию: та записывает ход загрузки файла, чтобы другой запрос мог проверить прогресс. Рано утром 21 октября токийская компания GMO Flatt Security предложила этот вариант, оговорившись, что не уверена в его эффективности, но он, возможно, поможет «с некоторой вероятностью». Позднее, в обновлении с отметкой 14:00 по японскому времени (05:00 UTC), компания уточнила: одной настройки недостаточно, а обходной путь, вероятно, найдётся. Администраторам посоветовали следить за трафиком атак, подготовить обновление и установить его сразу после выхода.
Разработчики PHP не подтверждают эту настройку как защиту. Gina Peter Banyard, разработчик ядра PHP и автор документации, финансируемая PHP Foundation, сказала: «Могу сказать только одно: единственная мера защиты — установить патч или обновить PHP. К сожалению, я знаю слишком много». Joe Ferguson, менеджер выпуска будущей версии PHP 8.6, выразился короче: «Настройки ini вас не спасут». GMO Flatt не описала предполагаемый способ обхода, а связь уязвимости с Session Upload Progress остаётся спорной. Upwind всё ещё указывает отключение функции как «немедленную меру защиты», опираясь на анализ другого исследователя, а не на собственные испытания. watchTowr, воспроизведшая одну из уязвимостей, говорит, что «подтверждённого исправления или обходного решения пока нет».
Если настройка уже отключена, возвращать её не требуется, но считать её защитой не стоит. Руководство PHP и без того советует отключать Session Upload Progress, когда приложению не нужны индикаторы загрузки: имена сохранённых файлов и полей, предупреждает документация, «не проходят проверку и могут содержать код PHP». Практическое последствие отключения — перестанут работать полосы прогресса загрузки.
Проверять настройку нужно в PHP-процессе, который обслуживает сайт, а не только в командной строке. Параметр имеет область действия INI_PERDIR и задаётся через
Тем, кто может обновиться в 14:00 UTC, стоит заранее проверить процедуру установки и действия после неё, отрепетировать изменения конфигурации и договориться о необходимых согласованиях для аварийного перезапуска. Обновлять нужно именно среду PHP, обрабатывающую веб-запросы: PHP-FPM, mod_php или CGI. Обновление WordPress, Laravel или другого приложения не обновляет PHP под ним. Исправления PHP выпускает для четырёх поддерживаемых веток — с PHP 8.2 по PHP 8.5. Точные исправленные версии и границы затронутых выпусков должны объявить вместе с обновлением; ранее The Hacker News сообщала о поддерживаемых ветках и более широком контексте раскрытия.
Если установить патч сразу невозможно, CERT-EU советует «рассмотреть изоляцию приложений, доступных из интернета, от публичных сетей до выхода исправления». Banyard заметила, что отключить сервер на день «может быть самым разумным решением, но требовать этого от большинства людей совершенно нереалистично». Если выключить сайт нельзя, доступ можно ограничить VPN, списком разрешённых клиентов или обязательной аутентификацией на внешнем узле. Нужно убедиться, что запросы не могут обойти эти барьеры и попасть прямо на исходный сервер. GMO Flatt также рекомендует сократить объём хранимых данных и привилегии сервера, удалить сохранённые учётные данные, включая cloud roles, и настроить журналирование с защищённым хранением логов.
Ветки старше PHP 8.2 — включая 8.1, 7.x и 5.x — сняты с поддержки и не получат исправлений от PHP. Для них остаются обновление, отключение или изоляция системы. Дистрибутив Linux либо хостинг-провайдер может отдельно перенести исправление в свой пакет, но сроки будут зависеть от них.
Некоторые исследователи предлагают блокировать на веб-сервере запросы с телом
Клиентам управляемого и виртуального хостинга нужно узнать у провайдера, когда появится исправленная сборка PHP, и попросить подготовить её к установке. Провайдеру может потребоваться собрать пакет после выхода патча: например, CloudLinux сообщает, что обновлённые пакеты зависят от выпуска исправления upstream PHP и будут опубликованы после его появления. Debian, Ubuntu и другие дистрибутивы часто переносят патчи безопасности в уже установленную версию, не обновляя её номер до более нового. Поэтому по одной строке версии нельзя понять, установлен ли патч: следует сверить журнал изменений пакета с нужной CVE или проверить точную версию по бюллетеню дистрибутива.
После публикации исправления нужно проверить официальные материалы PHP: какая версия закрывает уязвимость в вашей ветке, какие выпуски признаны затронутыми, подтверждает ли проект какую-либо настройку как защитную и менялся ли код Session Upload Progress. Это поможет прояснить, находится ли проблема именно там. Исправленные версии и бюллетени ожидаются на и в GitHub Security Advisories PHP; в этих бюллетенях проект использует собственные идентификаторы уязвимостей. После обновления стоит изучить логи и проверить активность, зафиксированную до установки патча.
Изображение носит иллюстративный характер
Cloudflare сообщила о первых попытках эксплуатации и включила экстренные правила для сайтов, проходящих через её сервис. Компания называет их временной мерой, а не заменой патча. Подтверждённых взломов в сообщениях нет; распространявшийся код эксплойта тоже не был доказанно работоспособным. На момент проверки 21 октября уязвимости не значились в каталоге известных эксплуатируемых уязвимостей CISA. watchTowr воспроизвела одну из них, но об атаках не сообщала. Исследователь опубликовал видео, которое, по его словам, показывает цепочку эксплуатации. При этом анонимный независимый аудит утверждает, что описанного бага в Session Upload Progress нет в выпущенных версиях PHP, а опубликованный proof of concept на них не работает. Эта картина может измениться быстро.
Отдельное предупреждение гласит: «PHP предупреждает о ещё одной неисправленной уязвимости RCE — CVE-2026-115560». Дополнительных сведений об этой уязвимости в материале нет, поэтому связывать её с PHP2Shell нельзя.
В соцсетях и блогах распространяли настройку session.upload_progress.enabled=0. Она отключает Session Upload Progress — функцию PHP, включённую по умолчанию: та записывает ход загрузки файла, чтобы другой запрос мог проверить прогресс. Рано утром 21 октября токийская компания GMO Flatt Security предложила этот вариант, оговорившись, что не уверена в его эффективности, но он, возможно, поможет «с некоторой вероятностью». Позднее, в обновлении с отметкой 14:00 по японскому времени (05:00 UTC), компания уточнила: одной настройки недостаточно, а обходной путь, вероятно, найдётся. Администраторам посоветовали следить за трафиком атак, подготовить обновление и установить его сразу после выхода.
Разработчики PHP не подтверждают эту настройку как защиту. Gina Peter Banyard, разработчик ядра PHP и автор документации, финансируемая PHP Foundation, сказала: «Могу сказать только одно: единственная мера защиты — установить патч или обновить PHP. К сожалению, я знаю слишком много». Joe Ferguson, менеджер выпуска будущей версии PHP 8.6, выразился короче: «Настройки ini вас не спасут». GMO Flatt не описала предполагаемый способ обхода, а связь уязвимости с Session Upload Progress остаётся спорной. Upwind всё ещё указывает отключение функции как «немедленную меру защиты», опираясь на анализ другого исследователя, а не на собственные испытания. watchTowr, воспроизведшая одну из уязвимостей, говорит, что «подтверждённого исправления или обходного решения пока нет».
Если настройка уже отключена, возвращать её не требуется, но считать её защитой не стоит. Руководство PHP и без того советует отключать Session Upload Progress, когда приложению не нужны индикаторы загрузки: имена сохранённых файлов и полей, предупреждает документация, «не проходят проверку и могут содержать код PHP». Практическое последствие отключения — перестанут работать полосы прогресса загрузки.
Проверять настройку нужно в PHP-процессе, который обслуживает сайт, а не только в командной строке. Параметр имеет область действия INI_PERDIR и задаётся через
php.ini, .htaccess или .user.ini. Последний файл читают версии PHP CGI и FastCGI, но не модуль Apache; по умолчанию PHP перечитывает его раз в 300 секунд, так что изменение может вступить в силу через пять минут. Для Apache-модуля используют .htaccess или конфигурацию сервера. Значение следует проверить в PHP-FPM либо mod_php — в зависимости от того, что запущено на сайте. Вывод php -i в оболочке этого не гарантирует. Тем, кто может обновиться в 14:00 UTC, стоит заранее проверить процедуру установки и действия после неё, отрепетировать изменения конфигурации и договориться о необходимых согласованиях для аварийного перезапуска. Обновлять нужно именно среду PHP, обрабатывающую веб-запросы: PHP-FPM, mod_php или CGI. Обновление WordPress, Laravel или другого приложения не обновляет PHP под ним. Исправления PHP выпускает для четырёх поддерживаемых веток — с PHP 8.2 по PHP 8.5. Точные исправленные версии и границы затронутых выпусков должны объявить вместе с обновлением; ранее The Hacker News сообщала о поддерживаемых ветках и более широком контексте раскрытия.
Если установить патч сразу невозможно, CERT-EU советует «рассмотреть изоляцию приложений, доступных из интернета, от публичных сетей до выхода исправления». Banyard заметила, что отключить сервер на день «может быть самым разумным решением, но требовать этого от большинства людей совершенно нереалистично». Если выключить сайт нельзя, доступ можно ограничить VPN, списком разрешённых клиентов или обязательной аутентификацией на внешнем узле. Нужно убедиться, что запросы не могут обойти эти барьеры и попасть прямо на исходный сервер. GMO Flatt также рекомендует сократить объём хранимых данных и привилегии сервера, удалить сохранённые учётные данные, включая cloud roles, и настроить журналирование с защищённым хранением логов.
Ветки старше PHP 8.2 — включая 8.1, 7.x и 5.x — сняты с поддержки и не получат исправлений от PHP. Для них остаются обновление, отключение или изоляция системы. Дистрибутив Linux либо хостинг-провайдер может отдельно перенести исправление в свой пакет, но сроки будут зависеть от них.
Некоторые исследователи предлагают блокировать на веб-сервере запросы с телом
multipart/form-data, не пропуская их в PHP. Этот вариант направлен на предполагаемый способ чтения тела запроса, но сам путь атаки пока не подтверждён. Правило должно охватывать не только POST: в PHP 8.4 появилась функция request_parse_body(), которая может читать multipart-тело и при других HTTP-методах, поэтому фильтр только для POST потенциально обходится. Блокировка отключит загрузку файлов и может сломать формы, отправляющие multipart-данные даже без файла. WAF тоже остаётся временным барьером. Cloudflare включила экстренные правила известных путей атаки, в том числе для пользователей бесплатного тарифа; технический директор компании назвал их «только временной мерой». Правила видят лишь трафик, проходящий через Cloudflare, и могут не распознать новые способы атаки. Клиентам управляемого и виртуального хостинга нужно узнать у провайдера, когда появится исправленная сборка PHP, и попросить подготовить её к установке. Провайдеру может потребоваться собрать пакет после выхода патча: например, CloudLinux сообщает, что обновлённые пакеты зависят от выпуска исправления upstream PHP и будут опубликованы после его появления. Debian, Ubuntu и другие дистрибутивы часто переносят патчи безопасности в уже установленную версию, не обновляя её номер до более нового. Поэтому по одной строке версии нельзя понять, установлен ли патч: следует сверить журнал изменений пакета с нужной CVE или проверить точную версию по бюллетеню дистрибутива.
После публикации исправления нужно проверить официальные материалы PHP: какая версия закрывает уязвимость в вашей ветке, какие выпуски признаны затронутыми, подтверждает ли проект какую-либо настройку как защитную и менялся ли код Session Upload Progress. Это поможет прояснить, находится ли проблема именно там. Исправленные версии и бюллетени ожидаются на и в GitHub Security Advisories PHP; в этих бюллетенях проект использует собственные идентификаторы уязвимостей. После обновления стоит изучить логи и проверить активность, зафиксированную до установки патча.
