PHP сегодня устроил мне внеплановую перепись серверов :D

21 октября команда PHP выпустила исправления двух критических уязвимостей: CVE-2026-109618 и CVE-2026-109619. Обе получили 9,2 из 10 по CVSS 4.0.

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

Проверять нужно PHP, который обслуживает веб-запросы: PHP-FPM, Apache с mod_php, CGI, FrankenPHP, LiteSpeed. Команда PHP отдельно выделяет mod_php как самый высокий риск: атака может сработать ещё до выполнения кода приложения. До проверки пароля дело может вообще не дойти.

Я прошёлся по трём своим серверам, обновил 42 пакета и заодно нашёл PHP 7.4, который тихо обслуживал Roundcube. Веб-почту перевёл на исправленный PHP 8.3, старый обработчик остановил и заблокировал его запуск. Перепись перешла в археологию :DD

Если у вас есть PHP на сервере:

1. Найдите все работающие обработчики. Проверьте PHP-FPM, Apache и контейнеры. Один php -v в консоли показывает версию консольного PHP; сайт может обслуживать другая сборка. Загляните и в веб-почту с phpMyAdmin — там тоже бывает PHP, о котором все забыли.
2. Сохраните конфиги и установите исправления. Для поддерживаемых веток PHP это 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 или более новые версии. Дистрибутивы Linux могут выпускать свои пакеты с перенесёнными исправлениями.
3. Перезапустите обработчик PHP. Если используете Apache с mod_php, перезапустите Apache. Для Docker обновите образ и пересоздайте контейнеры. Старые процессы должны завершиться, иначе они продолжат обслуживать запросы со старым PHP.
4. После обновления проверьте вход в приложение, API и загрузку файлов. Для магазина — ещё и оформление заказа.

Например, в Ubuntu 24.04 исправленный пакет называется 8.3.6-0ubuntu0.24.04.13. Само число 8.3.6 в выводе PHP останется прежним — смотреть нужно полную версию пакета. Бюллетень Ubuntu.

Для PHP 8.1 и старше нужно подтверждение исправлений от поставщика пакетов либо переход на поддерживаемую ветку. Сам проект PHP эти версии уже не поддерживает.

Если исправление пока недоступно, временно ограничьте внешний доступ к уязвимому PHP-сервису, например через VPN. Рекомендованные командой PHP изменения настроек дают только частичную защиту.

Хостеру или подрядчику можно переслать официальное сообщение PHP и попросить точную версию пакета после обновления вместе с подтверждением перезапуска обработчиков. «Обновили на сервере» без этих деталей я бы ещё перепроверил.