Две уязвимости PHP2Shell с оценкой критичности 9,2 из 10 могут дать атакующему удалённое выполнение кода на сервере. Вокруг них уже появилась популярная «защитная» настройка, но разработчики PHP и исследователи предупреждают: она не закрывает проблему. Для команд, которые держат PHP-приложения в публичном доступе, это означает простую вещь — готовить обновление и временно уменьшать поверхность атаки, а не надеяться на одну строчку в php.ini.
PHP планировал выпустить исправления 21 октября в 14:00 UTC, не раскрывая заранее ни затронутые версии, ни техническую причину дефектов, ни гарантированное временное решение. По данным The Hacker News, Cloudflare уже фиксировала ранние попытки эксплуатации и включила экстренные правила для защищаемых сайтов. Подтверждённых компрометаций на момент публикации не было, а доступный публичный код эксплуатации не доказал работоспособность. В каталоге CISA известных эксплуатируемых уязвимостей эти баги также пока не значились.
Одна настройка не превращается в патч
Чаще всего администраторам советовали отключить Session Upload Progress: session.upload_progress.enabled=0. Этот механизм PHP по умолчанию хранит сведения о ходе загрузки файла, чтобы приложение могло показать пользователю индикатор прогресса. Японская компания GMO Flatt Security сначала допускала, что отключение функции может снизить риск, но затем уточнила: одной этой меры недостаточно, а способы обхода ожидаемы.
Такую осторожность разделяют и внутри PHP-проекта. Разработчик ядра PHP Джина Питер Баньярд заявила, что единственной мерой смягчения остаётся обновление PHP. Релиз-менеджер PHP 8.6 Джо Фергюсон сформулировал ещё короче: настройки INI не спасут. Причина не только в возможном обходе. Связь PHP2Shell именно с Session Upload Progress не была официально подтверждена, а независимый аудит поставил под сомнение описываемый в этой подсистеме сценарий. Пока детали уязвимостей закрыты, проверять эффективность точечных советов со стороны практически невозможно.
Отключать параметр всё же не запрещают: если приложение не использует прогресс загрузки, функциональных потерь почти не будет. Но важно проверить, что значение применилось именно к процессу, обслуживающему HTTP-трафик, — PHP-FPM, mod_php или CGI. Вывод php -i в консоли здесь не даёт гарантии. Параметр можно задать в php.ini, .htaccess или .user.ini; последний вариант работает только с CGI/FastCGI и по умолчанию перечитывается раз в 300 секунд. Для Apache-модуля потребуется .htaccess или конфигурация веб-сервера.
Что делать до установки обновления
Если обновление нельзя накатить сразу, самый надёжный временный шаг — убрать публичный PHP-сервис из интернета или поставить его за VPN, allowlist либо обязательную аутентификацию на периметре. При этом нужно убедиться, что origin-сервер не доступен напрямую в обход CDN или прокси. CERT-EU советует изолировать интернет-доступные приложения до появления исправления; для критичных внутренних систем такой сценарий может оказаться менее болезненным, чем расследование RCE на продакшене.
Ещё один вариант — блокировать на веб-сервере запросы с телом multipart/form-data, не пропуская их до PHP. Это ломает загрузку файлов и часть форм, поэтому решение подходит лишь как краткая аварийная мера. Ограничение нельзя делать только для POST: в PHP 8.4 появилась функция request_parse_body(), которая обрабатывает multipart-тела и в запросах с другими методами. И здесь нет стопроцентной гарантии: правило закрывает предполагаемый путь входа, а не подтверждённую первопричину.
WAF и правила Cloudflare полезны как дополнительный слой, но не как замена обновлению: они видят только проходящий через них трафик и могут не распознать новый вариант атаки. Параллельно стоит сократить привилегии веб-процесса, убрать с сервера лишние секреты и облачные роли, минимизировать хранимые данные и проверить сохранность логов вне скомпрометированного узла. Если RCE всё же сработает, именно эти меры определят масштаб инцидента.
Исправления PHP выходят только для поддерживаемых веток 8.2–8.5. Владельцам PHP 8.1, 7.x и тем более 5.x рассчитывать на upstream-патч не приходится: остаются обновление платформы, изоляция или ожидание бэкпорта от дистрибутива либо хостинга. WordPress, Laravel и другие приложения сами по себе проблему не исправят — обновлять нужно рантайм, контейнерный образ или серверный пакет. Главный вопрос после выхода фикса будет не в том, кто успел поменять INI-параметр, а в том, сколько публичных PHP-инсталляций всё ещё работают на неподдерживаемых ветках. Подробности инцидента и позиции участников собраны в .
