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 и контейнеры. Один
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 исправленный пакет называется
Для PHP 8.1 и старше нужно подтверждение исправлений от поставщика пакетов либо переход на поддерживаемую ветку. Сам проект PHP эти версии уже не поддерживает.
Если исправление пока недоступно, временно ограничьте внешний доступ к уязвимому PHP-сервису, например через VPN. Рекомендованные командой PHP изменения настроек дают только частичную защиту.
Хостеру или подрядчику можно переслать официальное сообщение PHP и попросить точную версию пакета после обновления вместе с подтверждением перезапуска обработчиков. «Обновили на сервере» без этих деталей я бы ещё перепроверил.
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 и попросить точную версию пакета после обновления вместе с подтверждением перезапуска обработчиков. «Обновили на сервере» без этих деталей я бы ещё перепроверил.
Просмотры: 5