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

Обновление 21 октября, 14:00 UTC: PHP выпустил исправление. Обновитесь до 8.5.12, 8.4.27, 8.3.36 или 8.2.35 либо поставьте исправленные пакеты дистрибутива.

В PHP нашли две критические уязвимости: CVE-2026-109618 и CVE-2026-109619. Обе позволяют удалённо выполнить код (RCE): злоумышленник отправляет на сервер специально подготовленный запрос и запускает на нём свой код. Команда безопасности PHP оценила обе в 9.2 балла по шкале CVSS v4.0. 21 октября PHP выпустил исправление в версиях 8.5.12, 8.4.27, 8.3.36 и 8.2.35.

В Sansec ожидали массовых атак в течение 15 минут после релиза. Опубликованный патч обычно подсказывает атакующим, где искать. Если на вашем VPS работает WordPress, Laravel, форум, панель управления или любой другой код на PHP, обновляйтесь прямо сейчас.

Что подтвердил PHP

Согласно бюллетеню безопасности PHP, обе уязвимости позволяют выполнить код на сервере без авторизации. CVE-2026-109618 срабатывает, когда PHP не хватает памяти, а данные запроса подготовлены только частично: при очистке PHP принимает их за корректные. Из-за CVE-2026-109619 внутреннее состояние одного запроса остаётся жить после освобождения памяти, и его может подхватить следующий запрос в том же воркере.

Под угрозой любая установка PHP, которая обрабатывает веб-запросы: PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP и LiteSpeed. Самым рискованным PHP называет mod_php: для него уже показан эксплойт, который срабатывает до запуска кода приложения.

Номера CVE первыми назвали CERT-EU и watchTowr, а утечка накануне релиза указывала на session upload progress. Бюллетень подтверждает upload progress как один из путей атаки через CVE-2026-109619, но не единственный.

Про атаки. 20 октября в Huntress сообщили, что у их партнёров атак не было и публичного эксплойта они не видели. К утру 21 октября ситуация изменилась. Технический директор Cloudflare Дейн Кнехт написал в X, что компания уже видит первые атаки и развернула правила WAF против известных векторов. Правила доступны на всех тарифах, включая бесплатный. Сам Кнехт называет их временной мерой и призывает обновиться в 14:00 UTC. Если сайт стоит за Cloudflare, это даёт запас времени, но только для трафика через Cloudflare: запросы напрямую на IP сервера обходят WAF.

Какой PHP стоит на сервере

Первым делом найдите все версии PHP на сервере. Тут есть подвох: команда php -v показывает версию PHP для командной строки. А сайт работает через PHP-FPM или модуль Apache, и версия там может быть другой.

Поэтому проверьте три вещи: какие версии PHP установлены (в Debian и Ubuntu у каждой своя папка в /etc/php), какие сервисы PHP запущены и какую версию показывает каждый бинарник FPM по отдельности. Если PHP работает в Docker, проверьте и каждый контейнер: в каждом свой PHP, и по названию образа это не всегда понятно.

Запишите список.

Обновляемся и проверяем

Перед началом сделайте свежий бэкап или снапшот: если после обновления что-то сломается, откатываться на копию недельной давности будет больно. Заодно скопируйте текущие access-логи nginx или Apache и логи PHP-FPM туда, где их не удалит logrotate. Если кто-то успел проникнуть на сервер до патча, по ним можно будет понять, как это произошло.

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

Обновляйте PHP тем же способом, каким ставили: через apt в Debian и Ubuntu (пакеты дистрибутива или репозиторий ondrej/sury), через dnf в AlmaLinux, Rocky и CentOS Stream. Перед обновлением убедитесь, что новая сборка уже появилась в репозитории и что ни один пакет PHP не закреплён (hold): такие пакеты молча пропускаются. После обновления перезапустите PHP-FPM или Apache, если PHP работает как его модуль.

Панели управления обновляют PHP по своему графику. Например, cPanel распространяет PHP в пакетах EasyApache 4, так что исправление появится, когда cPanel выпустит новые сборки ea-php. Обновите панель и проверьте список изменений.

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

Процессы, которые работают постоянно (воркеры очередей, планировщики, Laravel Octane), продолжат использовать старую версию, пока их не перезапустить. Перезапустите и их. Потом пройдитесь по списку, который составили в начале, и проверьте версию каждого бинарника, включая FPM.

Здесь многие путаются. Дистрибутивы переносят исправления в свои пакеты, а номер версии оставляют старым. Обновлённый пакет в Ubuntu или Debian может показывать 8.1.2 с дополнительным суффиксом. Поэтому не сравнивайте версию с php.net, а ищите номера CVE в трекере безопасности Ubuntu или Debian.

Если на время ожидания вы заблокировали multipart-запросы (об этом ниже), снимите блокировку, когда сайт переедет на исправленную версию, и проверьте, что файлы загружаются. Upload progress можно не включать: большинству сайтов он не нужен.

Если обновиться сразу не получается

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

1. Отключите session upload progress

Эта функция включена по умолчанию и показывает, какая часть файла уже загрузилась. По данным PHP, отключение перекрывает подтверждённые пути атаки через сессии для CVE-2026-109619, но не все варианты. Загрузка файлов продолжит работать, пропадут только индикаторы прогресса, построенные на этой функции. Выставьте session.upload_progress.enabled в Off для каждой установленной версии PHP в php.ini, пуле FPM или конфигурации сервера. На .user.ini не полагайтесь: файл в папке сайта может снова включить функцию, поэтому в PHP-FPM закрепите настройку в каждом пуле через php_admin_flag. Потом перезапустите PHP-FPM или Apache, если PHP работает как его модуль, чтобы изменение подхватили все воркеры.

2. Примените меры PHP против CVE-2026-109618

Выставьте memory_limit в -1 через php_admin_value в пуле FPM или конфиге Apache, чтобы приложения не могли это переопределить. Без лимита памяти один запрос может занять всю оперативку сервера, поэтому PHP советует подстраховаться лимитом контейнера или cgroup. Снизьте post_max_size до 8M, если на сайт не загружают файлы, или до 32M, если загружают, и держите upload_max_filesize ниже этого значения. На PHP 8.5 также отключите fatal_error_backtraces.

3. Проверьте, что настройки применились там, где работает сайт

Командная строка тут не поможет. Проще всего положить в корень сайта временный PHP-файл со случайным именем, который выводит значения этих настроек. Откройте его в браузере, убедитесь, что изменения применились, и удалите файл. Если открылась страница 404, значит, сервер пропускает все запросы через index.php, и этот способ проверки вам не подойдёт.

4. Ограничьте multipart-запросы на веб-сервере

PHP советует ограничить на веб-сервере размер запроса и число частей в multipart, ещё до того, как запрос дойдёт до PHP. Если сайту загрузки не нужны, проще заблокировать multipart-запросы целиком. Настройка file_uploads в значении Off не поможет: PHP всё равно разбирает тело запроса, просто пропускает файлы. В nginx добавьте правило, которое отвечает 403 на любой запрос, где в заголовке Content-Type есть слово multipart. Поставьте его в каждый блок server, который передаёт запросы в PHP. Не забудьте про блок по умолчанию, который отвечает на обращения напрямую по IP. В Apache такое же правило добавляется в виртуальный хост или в .htaccess. Следите, чтобы оно проверяло заголовок Content-Type именно у запроса: переменная CONTENT_TYPE в Apache относится к ответу, и такие запросы пройдут. Затем проверьте блокировку с другой машины, отправив на сайт загрузку файла. Ответ должен быть 403.

Минус у блокировки один, зато заметный: пока она стоит, загрузить файл на сайт не получится. Перестанет работать загрузка медиа в WordPress и некоторые формы обратной связи, которые отправляют multipart даже без вложений, например Contact Form 7. Страницы, вход в аккаунт, JSON API и большинство обычных форм продолжат работать. Плагины безопасности WordPress и проверка авторизации в приложении эту блокировку не заменят: PHP разбирает запрос раньше, чем они запускаются.

5. Если решили закрыть сайт до обновления, остановите веб-сервер или отдавайте 503

Не отключайте просто обработчик PHP в nginx или Apache: тогда сервер начнёт отдавать .php-файлы как обычный текст, вместе с паролями к базе из конфигов.

Если у вас PHP 8.1 или ниже

Поддержка PHP 8.0 и 8.1 закончилась, а у 7.x она закончилась ещё несколько лет назад. Новых релизов для этих веток PHP не выпускает. Часть дистрибутивов и LTS-вендоров переносит исправление в свои пакеты, а для тех, кто собирает PHP сам, команда PHP выложила минимальные патчи для 7.4, 8.0 и 8.1. Ubuntu 22.04 ещё поддерживается, поэтому Canonical может добавить исправление в свои пакеты PHP 8.1. Следите за бюллетенями Ubuntu Security Notices по этим CVE. Если ничего из этого не подходит, переходите на поддерживаемую версию, а до тех пор не снимайте временную защиту.

Лучше сразу на 8.3 или 8.4, а не на 8.2: обновления безопасности для 8.2 прекратятся 31 декабря 2026 года, и через десять недель переезжать придётся снова. Сначала проверьте сайт на копии: при переходе с 7.4 старые плагины любят ломаться самым неожиданным образом.

Кто обновляет PHP

На unmanaged VPS за PHP отвечаете вы, и обновляете его тоже вы. Всё, что для этого нужно, описано выше, а само обновление на большинстве серверов сводится к одной команде.

На managed VPS обновление можно поручить саппорту is*hosting: напишите тикет с просьбой обновить PHP. Сам саппорт на серверы не заходит, ведь что на них работает, знаете только вы. Поэтому запрос должен прийти от вас.

И в конце дня ещё раз проверьте версию PHP. А потом и версию FPM: сайт работает именно на нём.