Две критические уязвимости в PHP (CVE-2026-109618 / CVE-2026-109619): что делать до выхода патча

Хочу себе такие же кнопки

Две критические уязвимости в PHP (CVE-2026-109618 / CVE-2026-109619): что делать до выхода патча

Кратко: официальный релиз безопасности PHP запланирован на 21 октября 2026 года, 14:00 UTC. Он должен закрыть две уязвимости с оценкой CVSS 9.2, допускающие удалённое выполнение кода. До выхода патча самая практичная временная мера — отключить session.upload_progress.enabled, но она закрывает лишь один из известных путей атаки и не заменяет установку исправления. Для PHP 7 и более старых версий официального исправления, скорее всего, не будет — нужно планировать обновление.

1. Суть проблемы

CERT-EU 20 октября 2026 года выпустил бюллетень 2026-018, предупреждающий о двух критических уязвимостях в PHP:

Параметр	Значение
Идентификаторы	CVE-2026-109618, CVE-2026-109619
Оценка CVSS	9.2 (критическая)
Тип угрозы	Удалённое выполнение кода (RCE)
Потенциально затронуты	Все версии PHP начиная с PHP 5 (по данным третьих источников; официально не подтверждено)
Дата выхода патча	21 октября 2026, 14:00 UTC

В бюллетене прямо указано, что уязвимости могут позволить неаутентифицированному удалённому атакующему выполнять произвольный код. Успешная эксплуатация даёт возможность запускать команды с правами процесса PHP, что ведёт к компрометации веб-сервера, утечке данных и использованию хоста как точки опоры для lateral movement внутри сети.

2. Технические детали: что известно, а что нет

На момент публикации PHP не раскрыл полные технические подробности, точный диапазон уязвимых версий и номера исправленных релизов.

Однако независимые исследования указывают на поверхность атаки, связанную с обработчиком session.upload_progress, а именно с функцией php_session_rfc1867_callback в ext/session/session.c, где предполагается use-after-free (UAF) в куче. Этот механизм появился в PHP 5.4 и включён по умолчанию, а обработка происходит до выполнения скрипта приложения, поэтому при подтверждении гипотезы под удар попадает широкий круг установок с конфигурацией по умолчанию.

Важная оговорка: этот технический разбор не подтверждён официально проектом PHP, и соответствие конкретных CVE описанному механизму ещё предстоит уточнить по официальному бюллетеню.

3. Временные меры: что и как сделать

3.1 Первоочередное действие — отключить session.upload_progress

В php.ini добавьте или измените:

session.upload_progress.enabled = Off

Затем перезагрузите службу в зависимости от того, как работает PHP:

• PHP-FPM: sudo systemctl reload php7.4-fpm (подставьте свою версию)
• mod_php: sudo systemctl reload apache2

Совместимость: директива одинакова в PHP 7 и PHP 8, различий в синтаксисе и способе задания нет.

Ограничение: по мнению ряда исследователей и представителей проекта PHP, отключение этой функции блокирует только один из вероятных путей атаки. Второй путь может находиться в самом multipart-парсере, который обрабатывает любой multipart/form-data POST независимо от данной настройки.

3.2 Ограничение multipart-запросов на периметре

Если есть WAF или обратный прокси, стоит ужесточить инспекцию или ограничить частоту multipart/form-data POST-запросов к эндпоинтам, которым загрузка файлов не нужна. Пример правила для Apache (в apache2.conf, внутри <VirtualHost> или <Directory>):

RewriteEngine On
RewriteCond %{HTTP:Content-Type} ^multipart/form-data [NC]
RewriteRule ^ - [F,L]

Правило точнее, чем просто multipart, и блокирует только multipart/form-data. Но помните: это защита на уровне шлюза, она не заменяет отключение session.upload_progress и обновление PHP.

3.3 Инвентаризация и планирование обновления

1. Определите все хосты и версии PHP (php -v).
2. Для PHP 7.x и старше исправлений, вероятно, не будет — планируйте миграцию на поддерживаемую ветку.
3. Сразу после выхода официального релиза установите патч. На момент публикации стабильные ветки — 8.5.11 / 8.4.26 / 8.3.35 / 8.2.34; если хостинг управляемый, уточните сроки у провайдера.

3.4 Если немедленное исправление невозможно

CERT-EU рекомендует рассмотреть изоляцию интернет-доступных приложений от публичных сетей до установки исправления. Это крайняя мера, но при CVSS 9.2 и наличии публичных PoC она оправдана для критичных систем.

4. Чего делать не стоит

• Не запускайте PoC-код с непроверенных сайтов на рабочих системах. Даже «безобидный» harness, который лишь отправляет два multipart-запроса, на уязвимой сборке может привести к падению процесса (DoS) из-за UAF. Проверять стоит только в изолированной лаборатории.
• Не считайте отключение одной директивы полной защитой. Это снижение риска, а не устранение уязвимости.
• Не откладывайте обновление. Публикация PoC и «weaponized» инструментов повышает вероятность массовых атак сразу после выхода патча.

5. Итоговый чек-лист

• Инвентаризировать все хосты и версии PHP
• Отключить session.upload_progress.enabled в php.ini (PHP 7 и 8 — одинаково)
• Перезагрузить PHP-FPM и/или Apache
• Ограничить multipart POST на WAF/прокси, где это возможно
• Зафиксировать сроки обновления (свои или провайдера)
• Для критичных систем рассмотреть временную сетевую изоляцию
• После выхода патча — установить его и проверить, что стоп-мера снята или оставлена осознанно

Главное: временные меры выигрывают время, но не закрывают уязвимость окончательно. Решение — в установке официального обновления PHP и, для устаревших веток, в миграции на поддерживаемую версию.