Критическая уязвимость PHP

Бяда пришла откуда не ждали.

Вчера выловили две критические уязвимость пыха CVE-2026-109618 и CVE-2026-109619, позволяющее выполнить удаленный код на серваке с помощью обращения к освобожденной памяти в обработчике отслеживания прогресса загрузки файлов на сервер (session.upload_progress). Причем функционал загрузки файлов не нужен, ибо срабатывает вшитый в ядро обработчик контента “multipart/form-data”.

Правда успешность выполнения зависит от конкретной системы и структуры в памяти, специфичных для различных дистров.

И часа полтора назад, в 17 часов по мск, оперативно выкатили обновы для весий PHP 8.2-8.5. И хотя уязвимость предполагается существует с 5.4, остальным предложили пососать мокрую дверную ручку, т.к заплатки к ним выпускать не планируют.

Зато дают охуенный совет убрать сайт под управлением уязвимого пыха за WAF, так называемый Web Application Firewall.

Учитывая, что у меня серваки крутятся под пятеркой и семеркой, то видимо придется объявлять ночной праздник сисадминства, т.к уже выкатили экслоит под названием PHP2Shell и вопрос автоматизации раскорячивания сайтов на пыхе по всему миру – вопрос нескольких дней.

Если нет возможности обновить пых на 8.2+, то предлагается закостылить защиту следующими способами:

  1. Отключение upload_progress сессий
    в php.ini добавляется строка
    session.upload_progress.enabled = off
    при работе через PHP-FPM в настройки пула, например /etc/php/7.4/fpm/pool.d/www.conf добавляем
    php_admin_flag[session.upload_progress.enabled] = off
    Правда создатель эксплоита утверждает, что этого недостаточно.
  2. Блокировка multipart запросов на уровне веб-морды

# для Nginx (только внутри блоков server и location)
if ($http_content_type ~* “multipart/form-data”) {
return 403;
}

# для Apache в mod_rewrite
RewriteCond %{HTTP:Content-Type} multipart [NC]
RewriteRule ^ – [F,L]

Оставить комментарий