2026-10-21T21:18:00+03:00

21.10.2026 21:18

21 октября 2026 года команда PHP выпустила внеочередные исправления для двух критических уязвимостей: CVE-2026-109618 и CVE-2026-109619.

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

Обновление PHP — единственная полная мера защиты, о чём прямо говорят официальные advisories проекта.

Что случилось 21 октября 2026 года

Релизы PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35 содержат исправления двух уязвимостей, которым команды безопасности присвоили критический уровень по шкале CVSS. По сообщениям разработчиков, уязвимости могут позволить неавторизованное удалённое выполнение кода.

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

Суть первой уязвимости: CVE-2026-109618

Проблема связана с обработкой ошибки нехватки памяти (out-of-memory). Когда PHP исчерпывает лимит памяти во время обработки входящих данных, интерпретатор аварийно покидает текущий контекст выполнения.

Если это происходит в момент, когда внутренние структуры запроса ещё не полностью инициализированы, процедура завершения запроса может обработать недоинициализированные данные как корректные.

Уязвимый путь связан с обработкой multipart/form-data — формата, который браузеры используют для загрузки файлов. При определённых условиях запрос может обойти проверку post_max_size или создать большое количество служебных структур внутри разрешённых лимитов, доводя процесс до критической ошибки памяти.

Особую опасность представляет режим Apache mod_php: подтверждённый сценарий эксплуатации срабатывает ещё до запуска PHP-кода приложения. Это значит, что уязвим даже минимальный сайт, если он работает на уязвимой сборке PHP.

Суть второй уязвимости: CVE-2026-109619

Вторая проблема — использование ранее освобождённой памяти (use-after-free) между запросами. В PHP-FPM и других многозапросных средах один рабочий процесс последовательно обрабатывает множество запросов.

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

В advisory описаны два подтверждённых механизма:

• выдача диагностических сообщений при применении устаревших или некорректных ini-настроек до инициализации следующего запроса;
• использование механизма session.upload_progress, который может обращаться к данным сессии до обычной инициализации.

Рабочая цепочка эксплуатации требует, чтобы оба запроса обработал один и тот же воркер, а также точной подстройки под раскладку памяти процесса. Это усложняет атаку, но не делает её невозможной: речь идёт о снижении надёжности, а не о принципиальной защите.

Кто находится под угрозой

По данным официального advisory PHP, уязвимы все установки, обрабатывающие веб-запросы:

• PHP-FPM;
• Apache с mod_php — наиболее рискованная конфигурация;
• CGI-обработчики (php-cgi);
• FrankenPHP;
• LiteSpeed и LSAPI.

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

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

Какие версии PHP содержат исправления

Ветка PHP	Минимальная исправленная версия	Состояние ветки
8.5	8.5.12	Активно поддерживается
8.4	8.4.27	Активно поддерживается
8.3	8.3.36	Поддержка безопасности
8.2	8.2.35	Приближается окончание поддержки
8.1 и старше	Официальных новых релизов нет	Требуется обновление ветки или бэкпорт от поставщика

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

Как проверить версию PHP на сервере

Проверка через командную строку:

php -v
php-fpm -v
rpm -q php php-fpm        # для RHEL-совместимых систем
dpkg -l | grep php        # для Debian/Ubuntu

Помните: версия в консоли может отличаться от версии, обслуживающей сайт, особенно если на сервере несколько веток PHP или несколько пулов FPM. Проверьте все пулы:

ps aux | grep '[p]hp-fpm'
systemctl list-units --type=service | grep -i php

Обновление PHP на виртуальной машине BitrixVM

В BitrixVM 9.x используются собственные совместимые пакеты PHP. Подключать сторонние репозитории, такие как Remi, без предварительной проверки не рекомендуется: они могут вызвать конфликты с пакетами BitrixEnv.

Порядок действий:

1. Создайте резервную копию сайта и базы данных.
2. Проверьте свободное место на диске.
3. Подключитесь к серверу по SSH и запустите меню управления:

sudo /root/menu.sh

Выберите пункт обновления пакетов PHP и MySQL в разделе управления серверами пула. BitrixVM установит доступные обновления из своих репозиториев. Затем перезапустите PHP-FPM:

sudo systemctl restart php-fpm
sudo systemctl status php-fpm --no-pager
php -v

Обновление пакетов также можно выполнить через DNF:

sudo dnf check-update
sudo dnf update --refresh
sudo systemctl restart php-fpm

Обновление на обычном VDS и в Docker-окружении

Для RHEL-совместимых систем (AlmaLinux, Rocky Linux, CentOS Stream):

sudo dnf update --refresh
sudo systemctl restart php-fpm httpd

Для Debian и Ubuntu:

sudo apt update
sudo apt upgrade
sudo systemctl restart php8.3-fpm apache2

Название сервиса PHP-FPM зависит от установленной ветки: php8.2-fpm, php8.3-fpm, php8.4-fpm или другое.

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

rpm -q --changelog php | head -n 80

Ищите упоминания CVE-2026-109618 и CVE-2026-109619. Если записей нет, сервер нельзя считать защищённым.

Обновление Docker-контейнеров

Если PHP работает в контейнере, недостаточно обновить пакет внутри запущенного экземпляра: при пересоздании контейнера изменения исчезнут. Правильный порядок:

1. Обновите базовый образ в Dockerfile или укажите тег исправленной версии.
2. Пересоберите образ.
3. Перезапустите контейнеры.
4. Проверьте версию PHP внутри нового контейнера.

docker compose build
docker compose up -d
docker compose exec php php -v

Если используется готовый образ PHP, подтяните свежую версию тега и пересоберите окружение. Не применяйте обновления только внутри работающего контейнера: это создаст расхождение между образом и продакшеном.

Перезапуск воркеров обязателен

Одного обновления пакетов недостаточно. Устаревшее состояние живёт в процессах, поэтому после обновления необходимо перезапустить PHP-FPM и Apache. Иначе часть воркеров продолжит работать с уязвимой версией в памяти.

Долгоживущие процессы, запущенные из консоли — воркеры очередей, демоны, фоновые скрипты, — также нужно перезапустить вручную, если они используют PHP.

Временные меры, если обновление задерживается

Эти настройки снижают риск отдельных сценариев, но не делают сервер защищённым. Обновление остаётся приоритетной задачей.

Отключите отслеживание прогресса загрузки

session.upload_progress.enabled = 0

Для PHP-FPM настройку нужно задать в конфигурации пула, чтобы она применялась до обработки запроса:

php_admin_value[session.upload_progress.enabled] = 0

После изменения обязательно перезапустите PHP-FPM. Не полагайтесь на ini_set() в коде приложения или файлы .user.ini — они применяются слишком поздно.

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

post_max_size = 8M

Если загрузка файлов необходима, используйте разумный предел:

post_max_size = 32M
upload_max_filesize = 24M

Дополнительная настройка для PHP 8.5

fatal_error_backtraces = 0

Временная блокировка multipart-запросов

Если сайт не принимает файлы через веб-формы, можно временно заблокировать multipart-запросы на уровне веб-сервера. Это отключит загрузку файлов и загрузку изображений в административных разделах CMS, поэтому используйте меру только как крайний вариант.

Для Nginx:

if ($http_content_type ~* "multipart") {
    return 403;
}

Для Apache с mod_rewrite:

RewriteCond %{HTTP:Content-Type} multipart [NC]
RewriteRule ^ - [F,L]

Перед применением проверьте конфигурацию и перезагрузите веб-сервер только после успешной проверки:

sudo nginx -t && sudo systemctl reload nginx

Другие временные меры

• ограничьте доступ к административным разделам по IP или VPN;
• при высоком риске временно ограничьте публичный доступ к тестовым стендам;
• используйте правила WAF от вашего провайдера — они дают дополнительное время, но не заменяют патч;
• уберите устаревшие ini-настройки, вызывающие предупреждения при инициализации;
• исправьте фатальные ошибки и таймауты в коде, доступном для вызова по HTTP.

Что проверить после обновления

• версию PHP в консоли и внутри веб-обработчика;
• статус PHP-FPM и отсутствие ошибок в журналах;
• загрузку главной страницы и административного раздела;
• авторизацию пользователей;
• отправку форм и почтовых уведомлений;
• работу функций загрузки файлов;
• интеграции с внешними сервисами и обмен данными с 1С;
• выполнение агентов и задач cron;
• отсутствие предупреждений о несовместимости расширений.

Полезно также проверить журналы на следы предыдущих попыток эксплуатации: ошибки memory_limit на multipart-запросах, необычно большие сессионные cookies, необъяснимые падения воркеров.

Почему важно поддерживать PHP актуальным

Этот инцидент показал две вещи. Во-первых, даже зрелые компоненты, десятилетиями работавшие в продакшене, могут содержать серьёзные проблемы. Во-вторых, современный уровень автоматизации и аналитики сокращает время от публикации патча до массовых атак на старые версии. Запаздывание с обновлением становится реальным риском, а не теоретической проблемой.

Поддержка PHP 8.2 также ограничена по времени: после окончания срока поддержки ветка перестаёт получать исправления безопасности. Если ваш проект всё ещё работает на устаревшей ветке, планируйте обновление заранее, тестируйте совместимость плагинов и модулей и держите актуальный план отката.

Частые вопросы

Кто находится под угрозой

Любой сервер, который обрабатывает HTTP-запросы уязвимой версией PHP: PHP-FPM, Apache с mod_php, CGI, FrankenPHP, LiteSpeed. Проблема не зависит от CMS или кода приложения.

Какие версии содержат исправление

PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Для PHP 8.1 и старше официальных новых релизов нет: нужна миграция на поддерживаемую ветку или бэкпорт от поставщика ОС.

Достаточно ли отключить session.upload_progress

Нет. Настройка закрывает один подтверждённый вектор, но не устраняет обе уязвимости. Обновление PHP остаётся единственной полной мерой защиты.

Нужно ли перезапускать PHP-FPM после обновления

Да. Устаревшее состояние сохраняется в памяти воркеров. Без перезапуска часть процессов продолжит работать с уязвимой версией.

Как обновить PHP в Docker

Обновите базовый образ или тег в Dockerfile, пересоберите образ и перезапустите контейнеры. Изменения только внутри запущенного контейнера будут потеряны при его пересоздании.

Нужно ли обновлять плагины или модули CMS

Проблема находится в ядре PHP, поэтому плагины и темы CMS обновлять для устранения этой уязвимости не требуется. Но их совместимость с новой версией PHP стоит проверить на тестовом окружении.

Что делать, если PHP 8.1 или старше

Запланируйте миграцию на поддерживаемую ветку. Как временная мера — используйте пакеты с бэкпортом от поставщика ОС или минимальные исходные патчи от команды PHP, если они доступны.

Заключение

CVE-2026-109618 и CVE-2026-109619 — напоминание о том, что безопасность сайта начинается ниже уровня CMS. Проверяйте, какая именно версия PHP обрабатывает запросы, обновляйте её штатными средствами, перезапускайте воркеры и тестируйте проект после обновления.

Если нужно помочь с обновлением PHP, проверкой сервера или переносом проекта на актуальную ветку — напишите нам: 24@hm.plus. Мы сопровождаем серверы на AlmaLinux BitrixVM, CentOS BitrixVM, Ubuntu/Docker Bitrix Env и поможем обновить инфраструктуру без простоев.

Источники

• PHP Security Advisory: CVE-2026-109618
• PHP Security Advisory: CVE-2026-109619
• Архив релизов и обновлений PHP
• Документация BitrixEnv для Enterprise Linux 9