PHP2Shell (CVE-2026-109618, CVE-2026-109619): критические уязвимости PHP — что обновить

Две критические уязвимости удалённого выполнения кода в самом PHP, CVSS 9.2. Исправленные версии, временная защита и как проверить серверы.

21 октября 2026 года проект PHP выпустил исправления двух критических уязвимостей в ядре PHP, получивших название PHP2Shell. Они находятся в самой среде выполнения языка, а не в CMS или плагине, поэтому затронут практически каждый сайт и веб-приложение на PHP, пока его не обновят. Согласно бюллетеням PHP, атаку может запустить один специально сформированный запрос ещё до выполнения кода приложения.

Уязвимости

CVEСутьОпасность
CVE-2026-109618Повреждение памяти при обработке нехватки памяти (например, при разборе multipart-загрузок) — удалённое выполнение кодаКритическая, CVSS 4.0: 9.2
CVE-2026-109619Устаревшее состояние запроса используется следующим запросом в том же процессе (use-after-free) — удалённое выполнение кодаКритическая, CVSS 4.0: 9.2
CVE-2026-115560Третья проблема, объявленная CERT-EU 23 октября; подробности — со следующим выпуском PHPУдалённое выполнение кода

Команда PHP считает наиболее опасной конфигурацию mod_php (PHP внутри Apache); PHP-FPM, LSAPI и FrankenPHP также считаются уязвимыми. По данным CERT-EU, в сети начали появляться эксплойты (proof of concept).

Исправленные версии

  • PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 и новее.
  • PHP 8.1 и старше (включая 7.4) больше не поддерживаются: официальных выпусков нет. Используйте исправленные пакеты вашего дистрибутива Linux — например, старые выпуски Ubuntu, такие как 20.04, получают исправления только через Ubuntu Pro (ESM), — или обновите PHP.
  • Пакеты дистрибутивов после исправления часто сохраняют старый номер версии, поэтому проверяйте журнал изменений пакета, а не только php -v.

Если обновить сегодня нельзя

Эти меры из бюллетеней PHP и CERT-EU снижают риск, но не делают сервер безопасным:

  1. Установите session.upload_progress.enabled=0 в php.ini или пуле FPM (не через ini_set() или .user.ini) и перезапустите все процессы PHP.
  2. В PHP 8.5 установите fatal_error_backtraces=0.
  3. Держите post_max_size небольшим (8M, если загрузка файлов не нужна) и ограничьте размер запросов и число частей multipart на веб-сервере или прокси.
  4. Блокируйте multipart-запросы на входе для приложений, которые не принимают файлы.
  5. Не используйте ограничения RLIMIT_AS / RLIMIT_DATA — они могут вызвать уязвимый сценарий.
  6. Если обновить невозможно, отключите доступные из интернета PHP-приложения или спрячьте их за VPN до исправления.

Не забудьте о «скрытом» PHP

PHP встроен во многие продукты: панели управления, NAS, системы мониторинга, веб-интерфейсы устройств. Уточните у поставщиков, затронуты ли их продукты, и установите обновления.

Сначала обновление, потом усиление защиты. Временные настройки лишь выигрывают время.

CySec проверит ваши серверы на уязвимые версии PHP, установит обновления с минимальным простоем и настроит мониторинг новых бюллетеней.

Источники: бюллетень PHP GHSA-w8hw-w9fx-j79w, бюллетень PHP GHSA-6wmf-4rv5-p3rp, CERT-EU 2026-018.


Все статьи

Ещё по этой теме

Все статьи по теме

Нужна помощь с этим?

Наши инженеры проанализируют вашу текущую инфраструктуру и предложат конкретные улучшения.