PHP закрыла две критические RCE-уязвимости: обновиться нужно сразу
Команда PHP выпустила обновления для двух критических уязвимостей, которые позволяют выполнить код на сервере без аутентификации. Релиз вышел раньше заранее объявленного срока 14:00 UTC: официальный advisory опубликован 21 октября в 00:35 UTC.
Речь о CVE-2026-109618 и CVE-2026-109619. Обе получили оценку 9,2 из 10 по CVSS v4.0. Для внешне доступных PHP-приложений это повод не откладывать обновление: атака не требует входа в приложение, а в одном из подтверждённых сценариев с mod_php запрос может сработать ещё до выполнения кода самого приложения.
Какие системы под угрозой
В advisory PHP к затронутым отнесены все установки, обслуживающие веб-запросы: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Наивысшим PHP называет риск для mod_php, но проверять нужно не только его: важен любой публичный вход в PHP через веб-сервер.
Обновления уже доступны для поддерживаемых веток: PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. В дистрибутивах Linux и у поставщиков с долгосрочной поддержкой исправления могут поставляться как пакетные обновления или бэкпорты — их стоит проверить по бюллетеням конкретного вендора.
Старые версии — отдельная проблема
PHP 8.1 и более ранние ветки больше не получают обычные обновления от проекта. Для версий 7.4, 8.0 и 8.1 команда PHP подготовила минимальные исходные бэкпорты, но это не равнозначно полноценной поддержке. Тем, кто получает PHP из дистрибутива или коммерческого LTS, нужно выяснить у поставщика наличие патча; остальным — планировать переход на поддерживаемую ветку.
В advisory приведены настройки, которые могут сузить отдельные пути атаки, однако PHP прямо предупреждает: полностью безопасным решением остаётся только обновление. Отключение отдельных функций, настройка лимитов или перезапуск воркеров не должны становиться заменой патча.
Что сделать сегодня
Сначала составьте список публичных PHP-сервисов и выясните, каким пакетом и какой версией они работают. Затем установите обновление, перезапустите соответствующие воркеры и проверьте критичные сценарии приложения. Для систем, которые нельзя обновить немедленно, временные меры из advisory могут уменьшить экспозицию, но не закрывают уязвимости полностью.
В этот раз главный риск — не экзотическая библиотека и не ошибка прикладного кода: исправление требуется на уровне PHP-рантайма. Поэтому владельцам интернет-доступных приложений стоит передать задачу тем, кто отвечает за пакеты, веб-сервер и развёртывание.













