Критические уязвимости PHP в октябре 2026: какие версии опасны и как безопасно обновить сервер

Критические уязвимости PHP и безопасное обновление серверного окружения

21 октября 2026 года команда PHP выпустила экстренные обновления сразу для нескольких поддерживаемых веток языка из-за двух критических уязвимостей, способных привести к удалённому выполнению кода без авторизации. Речь идёт о CVE-2026-109618 и CVE-2026-109619. Обе проблемы получили оценку CVSS v4.0 9.2, а официальный PHP Security Team рекомендовал обновляться немедленно.

Для владельца сайта это важный случай, потому что проблема находится не в конкретной CMS, шаблоне или модуле. Уязвимость расположена на уровне самого PHP. Поэтому потенциально затронуты сайты на 1С-Битрикс, WordPress, Laravel, Symfony, Drupal, самописных CMS и любых других приложениях, если они работают на уязвимой версии интерпретатора.

При этом правильная реакция - не паника и не механическое переключение версии PHP на боевом сервере. Обновление интерпретатора затрагивает PHP-FPM, CLI, расширения, конфигурацию, Composer-зависимости, cron-задачи, очереди, OPcache, интеграции и иногда сам код проекта. Поэтому сначала нужно понять текущее окружение, подготовить откат, проверить совместимость и только после этого менять рабочую версию.

В этой статье разберём, что произошло, какие версии считаются исправленными, почему даже обычный сайт может оказаться под риском, как проверить свою версию PHP и как на практике должен выглядеть безопасный процесс обновления сервера. Материал актуализирован на 23 октября 2026 года.

Что произошло с PHP в октябре 2026 года

20 октября PHP Security Team заранее предупредил о предстоящем критическом security-релизе. На следующий день, 21 октября, были опубликованы исправления для двух уязвимостей удалённого выполнения кода:

CVE-2026-109618 - проблема, связанная с обработкой состояния при нехватке памяти;
CVE-2026-109619 - проблема, при которой внутреннее состояние запроса может пережить освобождение памяти и быть использовано последующим запросом.

Обе уязвимости относятся к ядру PHP. В определённых сценариях атакующий может отправить специально сформированный HTTP-запрос и добиться выполнения кода на сервере без предварительной авторизации в самом приложении.

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

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

Какие версии PHP уже исправлены

Исправления вошли в следующие релизы:

Ветка PHP	Минимальная исправленная версия	Статус
PHP 8.2	8.2.35	исправлено
PHP 8.3	8.3.36	исправлено
PHP 8.4	8.4.27	исправлено
PHP 8.5	8.5.12	исправлено

Следовательно, например, PHP 8.2.20, 8.2.34, 8.3.35 или 8.4.26 сами по себе не содержат эти исправления. Для поддерживаемой ветки нужно перейти как минимум на соответствующий security-релиз или более новую версию той же ветки.

Отдельная ситуация - PHP 8.1 и более старые ветки. Они уже не получают обычные обновления безопасности непосредственно от PHP Project. Некоторые Linux-дистрибутивы и коммерческие LTS-поставщики могут переносить исправления в старые пакеты самостоятельно. Поэтому здесь нельзя определять безопасность только по номеру версии: нужно понимать, откуда установлен PHP и поддерживает ли конкретный поставщик этот пакет.

Для PHP 8.2 есть ещё один важный момент: официальная security-поддержка этой ветки заканчивается 31 декабря 2026 года. Поэтому если сервер всё равно требует обслуживания, имеет смысл оценить не только установку 8.2.35, но и план дальнейшего перехода на PHP 8.3 или 8.4 - разумеется, после проверки совместимости проекта.

Кого касается уязвимость

Официальный advisory перечисляет практически все основные способы обслуживания web-запросов PHP:

PHP-FPM;
Apache с mod_php;
php-cgi;
FrankenPHP;
LiteSpeed и другие окружения, где PHP обрабатывает HTTP-запросы.

То есть популярная связка Nginx + PHP-FPM также входит в потенциально затронутые конфигурации. Наличие Nginx перед PHP само по себе проблему не устраняет.

Наиболее высокий риск PHP Security Team отдельно отмечает для mod_php, где был продемонстрирован сценарий, при котором вредоносный запрос может сработать ещё до выполнения прикладного кода сайта. Но это не означает, что владельцам PHP-FPM можно ничего не делать: официальная рекомендация по обновлению распространяется на все PHP-установки, обслуживающие web-запросы.

Почему наличие современной CMS не защищает от этой проблемы

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

операционная система;
web-сервер - например, Nginx или Apache;
PHP и его расширения;
CMS или framework;
модули и библиотеки;
кастомный код проекта;
права доступа, сеть и инфраструктура.

Если уязвимость находится на уровне PHP, обновлённый 1С-Битрикс или WordPress не может самостоятельно её исправить. CMS начинает исполняться уже внутри PHP-процесса, а критическая ошибка может находиться ниже уровня приложения.

Именно поэтому принцип «мы регулярно обновляем CMS, значит сервер безопасен» недостаточен. Для production-проекта нужно отдельно контролировать жизненный цикл операционной системы, PHP, базы данных, web-сервера и системных библиотек.

Что означает Remote Code Execution

Remote Code Execution, или RCE, - класс уязвимостей, при котором удалённый атакующий потенциально способен добиться выполнения произвольного кода на сервере.

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

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

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

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

Самая простая проверка из shell:

php -v

В PHP-консоли 1С-Битрикс можно вывести текущую версию так:

echo PHP_VERSION;

Но есть важная деталь: версия CLI и версия, которая обслуживает сайт через PHP-FPM, могут отличаться. Команда php -v показывает PHP, доступный в командной строке. Nginx при этом может быть подключён к другому FPM-пулу или другому socket.

Поэтому при аудите сервера недостаточно увидеть один номер версии. Нужно проверить минимум:

какой PHP работает в CLI;
какой PHP-FPM обслуживает сайт;
какой FPM service запущен;
к какому socket или TCP-порту подключён Nginx;
какая версия используется в cron;
есть ли параллельно несколько веток PHP.

На сервере вполне может одновременно находиться PHP 8.1, 8.2 и 8.3. Если shell по умолчанию показывает 8.3.36, это ещё не гарантирует, что конкретный сайт не продолжает работать через php8.2-fpm.

Почему нельзя просто переключить PHP на новую версию и считать задачу закрытой

Формально обновление пакета может занимать несколько минут. Но production-обновление - это не только установка пакета. Главная работа заключается в том, чтобы после обновления сайт продолжил корректно выполнять все бизнес-функции.

Смена PHP может затронуть:

совместимость ядра CMS;
сторонние модули;
кастомный PHP-код;
Composer-зависимости;
нативные PHP-расширения;
настройки php.ini;
FPM pool configuration;
лимиты памяти и загрузки файлов;
OPcache;
cron и CLI-скрипты;
очереди и фоновые workers;
интеграции с внешними сервисами;
обработку изображений, архивов, XML, SOAP, Redis, Memcached и баз данных.

Например, сайт после переключения может открывать главную страницу, но перестать генерировать PDF, отправлять почту, создавать заказы, обрабатывать cron или выполнять обмен с 1С. Поэтому «главная открылась» - недостаточная проверка.

Как выглядит безопасное обновление PHP на сервере

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

1. Инвентаризация окружения

Сначала нужно понять, что именно работает на сервере. Фиксируются:

дистрибутив и его версия;
установленные версии PHP;
активные FPM-пулы;
версии PHP в CLI;
конфигурация Nginx или Apache;
используемые PHP-расширения;
источник пакетов PHP;
cron-задачи;
workers и supervisor/systemd services;
нестандартные php.ini и pool-конфигурации.

Этот этап особенно важен на серверах, которые развивались несколько лет. Там часто остаются старые service-файлы, несколько сокетов PHP-FPM, сторонние репозитории и legacy-задачи, о которых никто уже не помнит.

2. Проверка источника пакетов

Номер PHP сам по себе не всегда описывает реальный уровень security patching. Для поддерживаемых современных веток проще ориентироваться на официальный релиз. Для старых LTS-систем важно проверить, не использует ли дистрибутив backport: поставщик может сохранить старый номер основной версии, но перенести в пакет отдельное исправление безопасности.

Поэтому перед обновлением выясняют, откуда сервер получает PHP: штатный репозиторий ОС, сторонний репозиторий, BitrixVM, панель хостинга, контейнерный image или собственная сборка.

3. Резервная копия и возможность отката

До изменения runtime нужно иметь восстановимую точку. В зависимости от инфраструктуры это может быть snapshot виртуальной машины, backup файлов и БД, образ диска, резервная копия конфигурации или комбинация нескольких методов.

Критично не просто «иметь где-то бэкап», а понимать, сколько займёт возврат и какие именно данные будут потеряны при откате. Для интернет-магазина нужно учитывать новые заказы, оплаты и изменения, возникшие между созданием копии и возможным rollback.

Отдельно рекомендуем материал о проверке резервных копий и реальном восстановлении сайта.

4. Проверка совместимости приложения

Следующий вопрос - поддерживает ли проект выбранную ветку PHP. Для 1С-Битрикс нужно учитывать версию продукта, установленные модули Marketplace и собственный код. Для framework-проектов - требования Composer и версии библиотек.

Особенно внимательно проверяются:

устаревшие функции и синтаксис;
deprecated warnings;
изменения строгой типизации;
динамические свойства;
старые библиотеки;
код, завязанный на конкретное поведение расширений;
самописные интеграции;
шифрование и OpenSSL;
обработка XML/DOM;
старые драйверы БД.

Если одновременно меняется не patch-релиз, а ветка PHP - например, 8.2 → 8.4 - это уже отдельная миграционная задача. У нас есть отдельный материал про переход 1С-Битрикс на PHP 8.4.

5. Сопоставление расширений

После установки новой ветки PHP часто выясняется, что сам php-fpm есть, а часть расширений отсутствует. В результате сайт падает не из-за несовместимого кода, а потому что не подключены необходимые модули.

В зависимости от проекта это могут быть:

mysqli или pdo_mysql;
mbstring;
curl;
gd или imagick;
intl;
xml;
zip;
soap;
redis;
memcached;
opcache;
ionCube или другие сторонние loaders.

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

6. Перенос конфигурации без слепого копирования

Одна из опасных практик - просто скопировать старый php.ini поверх новой версии. В конфигурации могут быть устаревшие директивы, несовместимые параметры или настройки, которые больше не имеют того же смысла.

Корректнее сравнить старую и новую конфигурацию и осознанно перенести необходимые значения:

memory_limit;
max_execution_time;
post_max_size;
upload_max_filesize;
max_input_vars;
session settings;
date.timezone;
OPcache;
realpath cache;
логирование ошибок;
параметры FPM pool.

Так же отдельно сравниваются настройки CLI и FPM: они могут использовать разные ini-файлы.

7. Проверка FPM и привязки web-сервера

После установки новой версии PHP новый FPM-процесс может слушать другой socket. Например, web-сервер продолжает отправлять запросы в старый сокет, хотя администратор уже установил новую ветку.

Нужно проверить всю цепочку:

Nginx / Apache → FastCGI configuration → PHP-FPM pool → PHP binary → php.ini → extensions

Именно поэтому одна команда php -v не является полноценной проверкой обновления.

8. Проверка CLI, cron и фоновых задач

Даже если сайт работает через новый FPM, cron может по-прежнему запускать старый бинарник PHP по абсолютному пути. Это особенно характерно для проектов, где в crontab прописано что-то вроде конкретной версии интерпретатора.

Нужно проверить:

cron;
systemd timers;
Supervisor;
queue workers;
Bitrix cron scripts;
резервное копирование;
импорт/экспорт;
обмен с 1С;
почтовые задания;
консольные команды framework.

Иначе сервер может одновременно работать на двух версиях: web уже на новой, а фоновые процессы - на старой.

9. Перезапуск и очистка долгоживущих процессов

После security-обновления важно убедиться, что старые PHP workers действительно завершены и больше не обслуживают запросы. Это касается FPM, долгоживущих queue workers и других процессов.

Также после переключения проверяется OPcache. Старый кеш байткода не должен становиться источником непредсказуемого поведения при изменении runtime.

10. Функциональная проверка проекта

После обновления нужно проверять не только HTTP 200 на главной странице. Минимальный smoke-test зависит от проекта, но обычно включает:

главную и основные разделы;
авторизацию;
административную часть;
формы;
отправку почты;
загрузку файлов и изображений;
поиск;
каталог;
корзину и оформление заказа;
платёжную интеграцию в тестовом сценарии;
API и webhooks;
cron;
агентов 1С-Битрикс;
обмены и фоновые задачи.

После этого просматриваются PHP error log, Nginx error log, журнал приложения и системные логи FPM.

Что особенно важно для 1С-Битрикс

На серверах с 1С-Битрикс обновление PHP требует проверки не только самого ядра продукта. В реальных проектах основная сложность обычно находится в доработках, сторонних модулях и инфраструктуре.

До переключения желательно проверить:

версию ядра 1С-Битрикс;
«Проверку системы» в административной части;
Marketplace-модули;
local/php_interface;
local/modules;
кастомные компоненты;
старый код в шаблонах;
агентов;
cron;
обмен с 1С;
почтовые события;
кеширование;
Memcached/Redis, если используются;
импорт больших файлов;
интеграции с платёжными системами и CRM.

Особенно опасны проекты, которые долго не обновлялись, но при этом имеют большой объём custom-кода. В таком случае повышение ветки PHP может вскрыть ошибки, которые годами не проявлялись.

Можно ли временно защититься без обновления

В официальном advisory PHP перечислены временные меры для уменьшения отдельных путей эксплуатации. Например, ограничения, связанные с memory limit, размером POST-запросов и session upload progress.

Но PHP Security Team прямо предупреждает: эти меры не делают уязвимую установку безопасной. Они перекрывают только конкретные известные сценарии. Полноценным решением остаётся обновление.

Поэтому временные ограничения уместны лишь как промежуточная защита, если production нельзя переключить немедленно. Использовать их как постоянную альтернативу security-релизу не стоит.

Почему WAF тоже не является полной заменой обновлению

Web Application Firewall может помочь блокировать известные сигнатуры атак, а reverse proxy способен ограничивать размер и структуру входящих запросов. Это полезные дополнительные уровни защиты.

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

Поэтому правильная модель такая:

обновлённый PHP + корректные права + firewall/WAF + мониторинг + резервные копии

а не:

уязвимый PHP + надежда, что firewall всё отфильтрует

Как понять, что обновление прошло успешно

После работ нужно подтвердить несколько вещей одновременно.

Web-запросы реально обслуживает исправленная версия PHP.
CLI использует ожидаемую версию.
Все необходимые расширения загружены.
FPM не содержит старых workers.
Nginx/Apache отправляет запросы в правильный pool.
Cron и background workers используют правильный бинарник.
Основные функции сайта пройдены smoke-test.
В логах нет новых fatal error и массовых warning.
Мониторинг не показывает рост 5xx.
Есть понятный путь отката, если скрытая проблема обнаружится позже.

Если после обновления появляются 502 или 504, это не обязательно означает «новая версия PHP плохая». Причиной может быть неправильный socket, незапущенный FPM service, отсутствующее расширение, fatal error приложения или неверные права. Отдельно мы разбирали это в статье про диагностику 502/504 между Nginx, PHP-FPM и приложением.

Нужно ли сразу переходить на самую новую ветку PHP

Не обязательно. Security patch и миграция между ветками - разные задачи.

Если сайт стабильно работает на PHP 8.3.35, первоочередная задача - установить безопасный релиз 8.3.36 или более новый релиз ветки 8.3. Это обычно значительно менее рискованно, чем одновременно переходить на 8.4 или 8.5.

Если проект работает на PHP 8.2, ситуация требует планирования: 8.2.35 закрывает текущую критическую проблему, но сама ветка 8.2 подходит к окончанию security-поддержки 31 декабря 2026 года. Значит, после срочного патча разумно отдельно запланировать переход на более новую поддерживаемую ветку.

То есть задачи лучше разделять:

срочно: устранить известную критическую уязвимость;
планово: перейти на актуальную долгоживущую ветку PHP после проверки проекта.

Что делать, если сервер на PHP 7.4, 8.0 или 8.1

Такой сервер нельзя оценивать по простой таблице «номер меньше - значит обязательно уязвим». Старые ветки уже находятся вне обычной поддержки PHP Project, но некоторые дистрибутивы и LTS-поставщики продолжают переносить security-fix в свои пакеты.

Нужно определить:

операционную систему;
репозиторий PHP;
точную версию пакета;
changelog поставщика;
наличие backport для CVE-2026-109618 и CVE-2026-109619.

Если подтверждённого исправления от поставщика нет, сервер нужно считать требующим обновления. А поскольку сама ветка PHP устарела, чаще всего речь идёт уже не о простом patch update, а о полноценной миграции приложения на поддерживаемый runtime.

Нужно ли выключать сайт на время обновления

Это зависит от архитектуры. На одиночном сервере короткое техническое окно часто безопаснее, чем переключение «на ходу» без контроля. В отказоустойчивой инфраструктуре можно обновлять узлы последовательно и выводить их из балансировщика.

Для обычного production-сервера решение принимается после оценки:

есть ли второй узел;
можно ли быстро откатить FPM;
есть ли активные заказы и оплаты;
есть ли длинные фоновые процессы;
нужно ли мигрировать конфигурацию;
меняется patch-релиз или ветка PHP.

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

Нужно ли проверять сервер на компрометацию после обновления

Да, если уязвимая версия была доступна из интернета до установки исправления, полезно хотя бы базово проверить систему.

Имеет смысл просмотреть:

access/error logs web-сервера;
PHP-FPM logs;
необычные новые PHP-файлы;
изменения в upload и временных каталогах;
неизвестные cron-задачи;
новые системные users или SSH keys;
подозрительные процессы;
неожиданные исходящие соединения;
изменения конфигурации;
следы web-shell.

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

Типичные ошибки при срочном обновлении PHP

Ошибка 1. Проверить только php -v

CLI может отличаться от версии PHP-FPM, которая обслуживает сайт.

Ошибка 2. Установить новый пакет, но не переключить Nginx

На сервере появляется безопасный PHP, однако сайт продолжает работать через старый socket.

Ошибка 3. Удалить старую версию до проверки новой

Так администратор сам уничтожает быстрый вариант отката.

Ошибка 4. Забыть про расширения

После переключения сайт получает fatal error из-за отсутствующего mbstring, redis, imagick, soap или другого модуля.

Ошибка 5. Проверить только главную страницу

Внешне сайт работает, но обмены, почта, заказы или cron уже сломаны.

Ошибка 6. Одновременно обновить PHP, CMS, базу и web-сервер

Если что-то ломается, становится трудно понять причину. Критические изменения лучше разделять.

Ошибка 7. Не проверить логи после переключения

Часть ошибок может не отображаться пользователю, но уже присутствовать в PHP/FPM log.

Ошибка 8. Считать временный workaround полноценной защитой

Официальный advisory прямо говорит, что полное решение - обновление.

Практический чек-лист для владельца сайта

Узнать фактическую версию PHP, обслуживающую сайт.
Проверить, относится ли она к исправленным версиям.
Если версия старая - определить ОС и источник PHP-пакетов.
Проверить наличие резервной копии и сценария восстановления.
Зафиксировать PHP-расширения и конфигурацию.
Проверить совместимость CMS и custom-кода.
Подготовить обновление и откат.
Обновить runtime контролируемо.
Проверить FPM, CLI, cron и workers.
Пройти функциональный smoke-test.
Проверить логи и мониторинг.
Если сервер долго был доступен на уязвимой версии - провести базовую проверку на компрометацию.

Когда лучше не обновлять самостоятельно

Если сервер обслуживает рабочий интернет-магазин, корпоративный портал, 1С-Битрикс с большим количеством доработок или несколько сайтов, обновление PHP лучше рассматривать как change в production-инфраструктуре, а не как бытовое обновление программы.

Особенно желательно привлечь специалиста, если:

на сервере несколько сайтов;
установлено несколько версий PHP;
нет тестового окружения;
нет понятного backup/rollback;
используется старая ОС;
PHP установлен из стороннего репозитория;
есть кастомные модули 1С-Битрикс;
есть интеграции с 1С, CRM, банками и платёжными системами;
работают cron и background workers;
сервер нельзя надолго останавливать.

В таких случаях самое важное - не сам факт установки нового пакета, а сохранение работоспособности всего проекта после изменения.

Как мы проводим обновление PHP

В ЭКШН АЙТИ обновление PHP на production обычно начинается с аудита текущего окружения. Мы определяем реальную версию PHP-FPM и CLI, проверяем web-сервер, расширения, конфигурацию, cron и особенности проекта.

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

Такой подход особенно важен для 1С-Битрикс, где один сервер может одновременно содержать ядро CMS, кастомные компоненты, агенты, cron, интеграции, обмены и сторонние модули.

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

Итог

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

Для поддерживаемых веток исправления доступны начиная с PHP 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Если сервер работает на более раннем релизе соответствующей ветки, обновление откладывать не стоит.

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

Если нужна помощь с проверкой PHP, аудитом сервера или безопасным обновлением 1С-Битрикс и других PHP-проектов - можно обратиться к нам. Сначала проверим текущее состояние и риски, затем предложим безопасный сценарий обновления без лишних изменений на production.

Источники и актуальность

Материал подготовлен по официальному security advisory PHP от 21 октября 2026 года, официальным release notes PHP 8.2.35, 8.3.36, 8.4.27 и 8.5.12, а также странице поддерживаемых версий PHP. Актуальность информации - 23 октября 2026 года.