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

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

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

Что подтверждено, а что пока слухи

В официальном анонсе PHP сказано, что уязвимости две, обе критические, и релиз выйдет в 14:00 UTC. Выпустить его могут и раньше, если подробности окажутся в открытом доступе или начнутся атаки. Какие версии уязвимы, в каких исправлено и в чём суть проблемы, расскажут вместе с релизом.

Всё остальное известно со слов исследователей. Номера CVE называют CERT-EU и watchTowr, а в анонсе PHP их нет. В watchTowr говорят, что смогли воспроизвести CVE-2026-109618, так что уязвимости реальные. Если верить утечке, уязвимы все версии начиная с PHP 5, а исправления выйдут только для поддерживаемых веток, с 8.2 по 8.5. Судя по утечке, проблема в функции session upload progress и в обработке multipart-запросов (так браузер отправляет файлы). Официально PHP ничего из этого не подтверждал, а один из core-разработчиков языка написал, что защититься можно только обновлением.

Про атаки. 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, и по названию образа это не всегда понятно.

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

До патча: снижаем риск

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

Сделайте свежий бэкап или снапшот

Если после обновления что-то сломается, откатываться на копию недельной давности будет больно.

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

Эта функция включена по умолчанию и показывает, какая часть файла уже загрузилась. На неё указывает утечка, хотя причина пока не подтверждена. Загрузка файлов продолжит работать, пропадут только индикаторы прогресса, построенные на этой функции. Выставьте session.upload_progress.enabled в Off для каждой установленной версии PHP. Файл .user.ini в папке сайта может снова включить функцию, поэтому в PHP-FPM дополнительно закрепите настройку в каждом пуле через php_admin_flag. Потом перезапустите PHP-FPM или Apache, если PHP работает как его модуль. В Sansec также советуют включить session.use_strict_mode (значение 1). Что это закрывает именно эту атаку, никто не подтверждал, но настройка полезна и сама по себе: PHP перестаёт принимать идентификаторы сессий, которые не создавал сам. Добавьте её рядом с настройкой upload progress и после перезапуска проверьте, что вход на сайт работает.

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

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

Заблокируйте multipart-запросы на веб-сервере

Этот способ надёжнее. По данным утечки, атаковать можно и через саму обработку multipart, а отключение upload progress этот путь не перекрывает. Настройка file_uploads в значении Off тоже не поможет: PHP всё равно разбирает тело запроса, просто пропускает файлы. Остаётся отклонять такие запросы ещё до 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 разбирает запрос раньше, чем они запускаются.

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

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

Сохраните логи

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

После 14:00 UTC: обновляемся и проверяем

Сначала посмотрите на php.net описание релиза и список исправленных версий. Обновляйте 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 8.1 или ниже

Поддержка PHP 8.0 и 8.1 закончилась, а у 7.x она закончилась ещё несколько лет назад. Если утечка правдива, официальных исправлений для этих версий не будет. 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: сайт работает именно на нём.