Уязвимости PHP CVE-2026-109618 и CVE-2026-109619

Опубликованы уязвимости CVE-2026-109618 и CVE-2026-109619, позволяющие удалённо выполнять код (RCE) без аутентификации из-за некорректного завершения работы и управления состоянием запроса в ядре PHP. Проблема связана не с веб-приложениями вроде WordPress или GNUBoard, а с повреждением памяти и использованием памяти после освобождения (Use-After-Free) в самом механизме выполнения PHP. Для устранения проблемы необходимо немедленно обновиться до версий с установленными исправлениями безопасности, таких как PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35, а также перезапустить рабочие процессы.

Уязвимости движка PHP, которые нельзя устранить одним обновлением веб-приложения

21 октября 2026 года (UTC) команда разработчиков PHP сообщила о двух уязвимостях безопасности с оценкой 9,2 по CVSS v4.0. Злоумышленник может выполнить произвольный код на сервере, отправив специально сформированный HTTP-запрос без отдельной процедуры входа.

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

При успешной атаке злоумышленник получает права системной учётной записи, от имени которой работает процесс PHP. Это не означает немедленного получения прав root, однако позволяет создать веб-шелл в каталоге веб-сервера или прочитать указанные в файлах конфигурации данные для подключения к базе данных, чтобы вывести или изменить внутренние данные. Если несколько сайтов на одном сервере используют одну и ту же учётную запись выполнения PHP-FPM, компрометация одного сайта может распространиться на другие сайты сервера.

Повреждение памяти при аварийном завершении и принцип использования освобождённой памяти

Обе уязвимости возникают из-за небезопасной очистки памяти при исключительных ситуациях во время обработки запроса. Условия возникновения и внутренний механизм у них различаются.

CVE-2026-109618 (повреждение памяти при превышении ограничения памяти): Если во время обработки запроса PHP превышает разрешённое ограничение памяти (Out-Of-Memory), он вызывает longjmp() и немедленно прерывает выполнение. Если в этот момент работа прекращается до полной инициализации внутренних структур запроса, неполное состояние не откатывается и остаётся в памяти. Затем процедура очистки запроса доверяет этим неинициализированным данным как корректным и обращается к ним, что приводит к повреждению памяти и удалённому выполнению кода.

CVE-2026-109619 (Use-After-Free при обращении к памяти, освобождённой предыдущим запросом): Некоторые глобальные состояния и состояния обработки ошибок внутри PHP временно указывают на область памяти, принадлежащую одному запросу. При аварийном завершении запроса из-за критической ошибки (fatal error) или нехватки памяти сама память может быть освобождена, тогда как внутренняя ссылка на неё не будет инициализирована заново. В средах с повторным использованием рабочих процессов, таких как PHP-FPM или mod_php, тот же рабочий процесс принимает следующий HTTP-запрос и снова читает уже освобождённую область памяти (Use-After-Free), создавая путь к выполнению кода.

В официальном уведомлении безопасности в качестве подтверждённых путей для CVE-2026-109619 указаны функция отображения хода загрузки сессии (session.upload_progress), предупреждения конфигурации, выводимые до инициализации запроса, и трассировки критических ошибок PHP 8.5 (fatal_error_backtraces). При этом отмечается, что даже блокировка этих путей не устраняет другие варианты атаки.

Состояние исправлений для версий PHP и область влияния в зависимости от среды выполнения

Уязвимы версии PHP 8.2–8.5 ниже исправленных выпусков, а неподдерживаемая версия 8.1 и более ранние версии не входят в официальную область обновлений проекта PHP. Уязвимость затрагивает все варианты установки, обрабатывающие веб-запросы, включая PHP-FPM, mod_php, php-cgi, FrankenPHP и LiteSpeed; официальное уведомление считает наиболее опасным вариант mod_php. Red Hat классифицирует PHP-FPM как условно уязвимый через пути на уровне приложения.

Проверенная среда: По состоянию на 22 октября 2026 года в среде сервера Linux с репозиторием Remi выполнено обновление PHP 8.4.26 до 8.4.27, а также проверены перезапуск рабочих процессов PHP-FPM и обработка веб-запросов.

Порядок обновления пакетов и применения настроек смягчения для PHP-FPM

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

1. Установка обновления пакетов PHP
   Обновите пакеты через менеджер пакетов операционной системы до исправленной версии используемой серии PHP, например до 8.4.27 для серии 8.4. После установки сначала проверьте версию CLI в терминале.

   php -v

   После выполнения команды на экране отобразятся обновлённый номер версии и дата сборки, например PHP 8.4.27 (cli). Однако версия CLI может отличаться от версии процесса PHP, с которым взаимодействует веб-сервер, поэтому следующий шаг необходимо выполнить обязательно.

2. Изменение настроек PHP-FPM для уменьшения поверхности атаки (необязательное и временное смягчение)
   Если немедленное обновление невозможно или требуется дополнительный уровень защиты, создайте резервную копию php.ini или файла конфигурации пула PHP-FPM, например /etc/php-fpm.d/www.conf, а затем измените следующие параметры.

   php_admin_value[session.upload_progress.enabled] = Off
   php_admin_value[post_max_size] = 32M
   php_admin_value[upload_max_filesize] = 30M

   Отключение session.upload_progress.enabled блокирует подтверждённый путь атаки через сессию. Уменьшение post_max_size — например, до 8M в средах без загрузки файлов или до 32M в необходимых для этого средах — усложняет попытки вызвать нехватку памяти большими запросами. С учётом размера дополнительных заголовков multipart параметр upload_max_filesize следует устанавливать немного ниже post_max_size. В среде PHP 8.5 также примените настройку fatal_error_backtraces = 0.

3. Проверка синтаксиса конфигурации PHP-FPM и перезапуск процессов
   После сохранения настроек проверьте отсутствие синтаксических ошибок и перезапустите службу PHP-FPM.

   php-fpm -t
   systemctl restart php-fpm

   Если при выполнении php-fpm -t проблем с конфигурацией нет, на экране появится сообщение NOTICE: configuration file ... test is successful. Перезапуск рабочих процессов необходим для завершения старых процессов с устаревшей версией, остававшихся в памяти, и применения нового исправления и настроек.

4. Проверка фактически применённой версии через веб-запрос
   Откройте вкладку информации «Состояние сайта (Site Health)» в WordPress или диагностическую страницу интеграции веб-сервера и убедитесь, что рабочий процесс PHP-FPM, обрабатывающий веб-запросы, отвечает исправленной версией, например 8.4.27. Если для проверки был временно создан диагностический PHP-файл, удалите его сразу после проверки, чтобы не раскрывать внешним пользователям системную информацию.

Что делать при задержке обновления или побочных эффектах изменения настроек

Пакет не загружается из-за задержки обновления зеркала стороннего репозитория (например, Remi)

Сразу после срочного обновления безопасности из-за высокой нагрузки или задержки синхронизации пакеты обновлений в стороннем репозитории, например rpms.remirepo.net, могут быть недоступны для просмотра или загружаться медленно. В официальном уведомлении говорится, что обновление в этом репозитории, который поддерживают добровольцы, может не появиться в день публикации; рекомендуется перейти на пакеты дистрибутива или сборку из исходного кода.

В таком случае можно вручную указать в настройках репозитория адрес зеркального сервера с завершённой синхронизацией и нормальной скоростью, а затем выполнить обновление. Даже при ручной смене зеркала проверку подписи GPG (gpgcheck=1) необходимо оставить включённой для защиты от подмены пакетов. Если использовать зеркало невозможно, примените официальный пакет обратного портирования дистрибутива ОС или самостоятельно скомпилируйте исходный код.

Опасения по поводу нехватки памяти (OOM) или отказа в загрузке после применения настроек смягчения

В качестве меры смягчения CVE-2026-109618 при невозможности немедленного обновления официальное уведомление предлагает установить memory_limit = -1 (без ограничений) и одновременно задать ограничения памяти контейнера или cgroup. Однако на сервере с небольшим объёмом физической памяти снятие ограничения может привести к тому, что один запрос израсходует всю память сервера, а OOM Killer операционной системы принудительно завершит важный демон. Это временная мера до обновления; после перехода на исправленную версию безопаснее вернуть исходное ограничение памяти.

Кроме того, при уменьшении post_max_size по сравнению с прежним значением, например 64MB, сначала проверьте способ передачи файлов на сайте. На сайтах, где через административную веб-страницу напрямую загружаются большие резервные копии или плагины, запросы могут быть отклонены. Напротив, если большие файлы передаются через SFTP или rsync либо ограничение самого приложения уже установлено на уровне 30MB или ниже, снижение ограничения загрузки PHP до 32MB не повлияет на работу сервиса.

Если после обновления версии PHP рабочие процессы PHP-FPM периодически аварийно завершаются, причиной может быть настройка JIT-компиляции OPcache. Функция JIT, например opcache.jit=1255, напрямую не связана с этой уязвимостью, однако при наличии истории проблем со стабильностью после смены версии её можно отключить в файле конфигурации с помощью opcache.jit=off, чтобы предотвратить сбои.

Часто задаваемые вопросы

Устранит ли проблему обновление WordPress или плагинов до последних версий?

Нет. Уязвимость возникает в ядре PHP до запуска WordPress или плагинов безопасности. Известные шаблоны атак можно временно блокировать с помощью веб-экрана, например Cloudflare или AWS WAF, однако для устранения первопричины необходимо обновить саму версию PHP на сервере через хостинг-провайдера или администратора сервера.

Будет ли безопасно не обновляться, если отключить session.upload_progress.enabled?

Нет. В официальном уведомлении указано, что эта настройка блокирует только подтверждённый путь через сессию и не препятствует другим вариантам атаки. Кроме того, настройку следует задавать не через ini_set() или .user.ini PHP-FPM, а в php.ini, пуле FPM или конфигурации сервера, применяемой до разбора запроса; после этого необходимо перезапустить все рабочие процессы. Полное решение — только установка исправления.

Можно ли сразу продолжить эксплуатацию после установки исправления без дополнительных проверок?

Обновление предотвращает будущие атаки, но не показывает, был ли сервер скомпрометирован ранее. После обновления рекомендуется отдельно проверить признаки предыдущего взлома. Проверьте, не появились ли недавно в каталогах веб-сайта подозрительные или изменённые PHP-файлы, например веб-шеллы, а также изучите журналы доступа веб-сервера и журналы ошибок PHP на наличие необычных больших POST-запросов или повторяющихся ошибок памяти.

Как действовать в среде контейнеров или облачных образов?

Обновление пакетов на хост-сервере не изменяет автоматически среду выполнения PHP внутри контейнера. Поэтому необходимо заново собрать и развернуть образ контейнера на основе образа с исправленной версией — 8.5.12, 8.4.27, 8.3.36 или 8.2.35.

Источники

• PHP: Security Advisory (CVE-2026-109618, CVE-2026-109619)
• PHP: PHP 8.4.27 Release Announcement
• PHP: PHP 8 ChangeLog (8.4.27)
• Red Hat Customer Portal - CVE-2026-109618
• Red Hat Customer Portal - CVE-2026-109619
• PHP 원격 코드 실행 취약점 CVE-2026-109618, CVE-2026-109619 대응 및 PHP 8.4.27 업데이트 (на корейском)