PHP2Shell (CVE-2026-109618 / CVE-2026-109619): что это и как временно снизить риск

22.10.2026
PHP2Shell (CVE-2026-109618 / CVE-2026-109619): что это и как временно снизить риск

PHP2Shell — общее название двух критических уязвимостей в самом интерпретаторе PHP: CVE-2026-109618 и CVE-2026-109619. Речь не о «дыре в одном плагине сайта», а о дефектах рантайма: при определённых условиях злоумышленник может добиться удалённого выполнения кода (RCE) на сервере с уязвимой версией PHP. Для компаний это риск компрометации веб-приложений, утечки данных и дальнейшего движения по инфраструктуре.

Публичные исследовательские материалы и PoC уже доступны в открытом доступе (в том числе на GitHub). Это ускоряет массовые проверки и атаки: полагаться только на «нас никто не найдёт» нельзя. Единственное полное устранение — обновление PHP до исправленных сборок; всё остальное ниже — временный щит на часы или дни, пока идёт плановый апдейт.

Кого это касается

  • Сайты и API на PHP 8.2 / 8.3 / 8.4 / 8.5 без октябрьских патчей 2026 года
  • Хостинг с PHP-FPM, Apache mod_php, LiteSpeed и аналогичными связками
  • Контейнеры и PaaS, где в образе «зашита» старая минорная версия PHP
  • Внешние PHP-бэкенды за CDN/прокси: обновлять нужно именно тот runtime, который обслуживает трафик

Ветки PHP 8.1 и ниже со стороны проекта PHP уже не получают регулярных исправлений — нужен переход на поддерживаемую ветку или бэкпорт от дистрибутива/LTS-вендора.

Полное устранение: обновить PHP

По официальным advisory исправлены следующие релизы (и новее в своей ветке):

  • PHP 8.2.35
  • PHP 8.3.36
  • PHP 8.4.27
  • PHP 8.5.12

После обновления пакетов или пересборки Docker-образа обязательно перезапустите все PHP-воркеры (FPM / Apache / пул) и убедитесь, что в прод отдаёт уже новая версия (php -v на том же окружении, что обслуживает сайт).

Временные меры, пока нельзя пропатчить

Ниже — конфигурация PHP, WAF и правила веб-серверов из mitigation-гайдов плюс рекомендации advisory PHP. Это не замена обновлению PHP, а стоп-гэп до установки 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12. Настройки задавайте административно и перезапускайте воркеры; ini_set() / .user.ini для части пунктов не сработают.

1. Конфигурация PHP (быстрый стоп-гэп)

Основной подтверждённый вектор связан с механизмом session upload progress (по умолчанию включён). Отключение сохраняет обычную загрузку файлов, но нейтрализует этот путь:

; php.ini
session.upload_progress.enabled = Off
; PHP-FPM pool (например www.conf)
php_admin_flag[session.upload_progress.enabled] = off

Дополнительно из advisory PHP:

  • На PHP 8.5: fatal_error_backtraces=0
  • Для CVE-2026-109618: memory_limit=-1 через php_admin_value + лимит памяти контейнера/cgroup; не использовать RLIMIT_AS / RLIMIT_DATA
  • Ограничить post_max_size (≈8M без uploads / ≈32M с uploads) и размер multipart на прокси
  • Убрать битые per-request INI; при возможности pm.max_requests=1

После правок: systemctl reload php*-fpm или перезапуск Apache / LiteSpeed.

2. Cloudflare WAF (custom rules)

  • Шаблоны правил для блокировки вредоносного multipart (с исключениями легитимных upload-маршрутов)
  • На Enterprise — инспекция тела запроса на признак PHP_SESSION_UPLOAD_PROGRESS
  • Не блокировать запросы только по cookie PHPSESSID — сломаете нормальные сессии

3. FrankenPHP (Caddyfile)

{
    frankenphp {
        php_ini session.upload_progress.enabled 0
    }
}

4. Lighttpd

На vhost/каталогах без загрузки файлов можно запретить multipart для POST|PUT|PATCH:

$HTTP["request-method"] =~ "^(POST|PUT|PATCH)$" {
    $REQUEST_HEADER["Content-Type"] =~ "(?i)^\s*multipart/form-data([;,[:space:]]|$)" {
        url.access-deny = ( "" )
    }
}

5. Apache: ModSecurity и .htaccess

ModSecurity — блокировать параметр PHP_SESSION_UPLOAD_PROGRESS:

SecRequestBodyAccess On
SecRule ARGS_NAMES "@streq PHP_SESSION_UPLOAD_PROGRESS"     "id:1026109618,phase:2,t:none,deny,status:403,log,    msg:'php2shell: PHP_SESSION_UPLOAD_PROGRESS field blocked'"

.htaccess / mod_rewrite — на каталогах без uploads закрыть multipart до PHP:

RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^(POST|PUT|PATCH)$ [NC]
RewriteCond %{HTTP:Content-Type} ^[[:space:]]*multipart/form-data([;,[:space:]]|$) [NC]
RewriteRule ^ - [F,L]

6. Мониторинг и реакция

  • Алерты на дочерние процессы PHP-воркеров (php-fpm, httpd): оболочки, curl/wget/nc, неожиданные интерпретаторы
  • Логи fatal/timeout на публичных URL; ограничить прямой доступ к origin
  • EOL PHP (≤8.1): срочно отключить upload progress, сузить периметр (VPN/WAF) или изолировать хост

Важно: display_errors=Off, оператор @ и снижение error_reporting не защищают от этих CVE.

Чек-лист для IT-руководителя

  1. Инвентаризация: где крутится PHP (сайты, CRM, внутренние порталы, контейнеры)
  2. Сверка версии с патч-релизами выше
  3. Если апдейт сегодня невозможен — применить временные меры и назначить окно обновления
  4. Перезапуск воркеров и проверка версии в проде
  5. Контроль логов и аномалий после изменений

Как помогает SoftTech

Для организаций в Минске и РБ закрываем операционную часть: аудит версий runtime, плановое обновление, hardening PHP-FPM/веб-сервера и мониторинг. См. информационную безопасность, администрирование IT-инфраструктуры и заявку на консультацию.

Материал носит оборонительный характер: описывает риск и меры снижения ущерба. Пошаговые эксплойты и воспроизведение атак в статье не публикуются. Исследовательские PoC в открытом доступе ускоряют необходимость патча, а не заменяют его.

Частые вопросы клиентов

Достаточно ли временно отключить session.upload_progress?

Это ключевой стоп-гэп из mitigation-гайдов и закрывает основной подтверждённый вектор, но не отменяет патч PHP и не покрывает все сопутствующие пути (в т.ч. связанные с OOM). Полная защита — обновление до исправленных релизов.

Почему советуют memory_limit=-1, а не более жёсткий лимит?

Для CVE-2026-109618 опасен контролируемый отказ выделения памяти внутри PHP. Снятие лимита убирает этот триггер; границу доступности нужно держать на уровне cgroup/контейнера, не через RLIMIT_AS/DATA.

Наш сайт на Laravel/Bitrix/WordPress — мы в зоне риска?

Да, если под ним уязвимый PHP. Фреймворк и CMS сами по себе патч рантайма не заменяют. Обновляйте PHP (или образ) на сервере/хостинге.

Сколько можно жить на временных мерах?

Часы или дни, не недели. Публичные PoC уже есть; откладывать патч опасно для любых интернет-доступных PHP-сервисов.

Может ли SoftTech проверить наши серверы?

Да: инвентаризация версий, план обновления, временный hardening и контроль после патча в рамках абонентского обслуживания или разового аудита ИБ.

Получить консультацию Все новости