20 октября команда безопасности PHP предупредила о security-релизе. Он назначен на среду, 21 октября 2026 года, 14:00 UTC. По Москве это 17:00. В релизе две критические уязвимости, обе с оценкой CVSS 4.0 ровно 9.2. Запись на php.net стоит с отметкой 20:32 UTC. В тот же вечер её коротко пересказал LWN: готовиться стоит всем, у кого сайт на PHP.
CVE, список затронутых веток и номера исправленных сборок команда опубликует вместе с релизом. До 14:00 UTC выбирать версию наугад не из чего. За эти часы полезнее понять, какой PHP уже обслуживает сайты, и не скачать соседний тестовый архив с той же страницы.
Две дыры с оценкой 9.2
Обе уязвимости команда ставит на 9.2 по CVSS 4.0 и называет critical. Просит обновиться, как только сборка появится. Окно тут на часы. Откладывать до спокойных выходных это предупреждение не предлагает.
Разбор того, как дыры вызываются, выйдет вместе со сборкой. До публикации версий менять конфиг nginx или выключать модули PHP не из чего: команда просит подготовиться и обновить ту ветку, которую назовут. Способ обновления тот же, которым PHP уже стоит на сервере.
Раньше 14:00 UTC, если детали утекут
Команда оставляет за собой ранний выпуск. Повод один из двух. Либо подробности любой из дыр стали публичными, либо в живом трафике видно, что уязвимость уже эксплуатируют. Если днём на той же странице php.net вместо предупреждения лежит список версий, ждать 17:00 по Москве не нужно.
На обычном VPS достаточно открыть php.net ближе к вечеру и ещё раз, если днём появится новость об эксплуатации. Жёсткое «только после семи» имеет смысл, пока страница всё ещё предупреждение, а не список сборок.
php-fpm, а не перезапуск nginx
На VPS с WordPress PHP почти всегда работает в php-fpm. Nginx только отдаёт запрос на сокет или порт пула. Конфиг веб-сервера ради этого релиза не правят. nginx -t и reload nginx нужны, когда меняли конфиг, не когда меняли интерпретатор.
php -v показывает CLI. Сайт может сидеть на другом бинарнике, если на машине две ветки. Обновить пакет одной ветки и оставить пул другой значит, что сайт останется на старом PHP. Сокет в fastcgi_pass должен быть сокетом того пула, который вы собираетесь перечитывать.
WP-CLI и крон из консоли берут php из PATH, то есть тоже CLI. Веб-запросы идут в FPM. После обновления смотрите оба, если кроны WordPress гоняете из консоли, а не только через веб.
OPcache живёт в памяти воркеров. Новый пакет без reload пула легко оставляет старый байткод. Хватает reload юнита php-fpm. Restart машины и restart nginx здесь лишние.
Команды ниже ничего не меняют. Первая показывает CLI, вторая перечисляет юниты FPM.
php -v systemctl list-units 'php*-fpm.service' --no-pager
Имя юнита из списка и есть то, что потом перезагружать через reload. На Ubuntu и Debian в имени обычно номер ветки. На AlmaLinux и Rocky часто один юнит php-fpm. Ориентир всё равно вывод, не привычка. Если юнитов несколько, нужен тот, чей сокет прописан в сайте nginx. Конфиг до релиза только читают. Копию пула снимают, только если полезете его править, а для этого обновления пул обычно не правят.
Tarball на php.net и пакет дистрибутива
В 14:00 UTC на php.net будут исходники и номера версий. Пакет Ubuntu или Debian выходит своим объявлением, не в ту же минуту. Пока сборки нет в том репозитории, откуда PHP уже стоит, собирать интерпретатор из git в рабочий пул не стоит. Новый репозиторий в этот день лучше не подключать: потом неясно, какая ветка откуда взялась.
На странице архива сразу под предупреждением висит PHP 8.6.0 RC3 от 8 октября. Команда пишет, что это ранний тестовый выпуск и в прод его ставить нельзя. Следующий кандидат, RC4, у них намечен на 22 октября. RC3 это тестовый шаг ветки 8.6, он вышел задолго до сегодняшнего предупреждения. Скачать его «раз уж всё равно обновляемся» значит поставить на сайт сборку, которую php.net просит не ставить.
Когда пакет вашей ветки появился, обновляют его и делают reload того юнита, который обслуживает сайт. Если пулов несколько, reload каждому, кто реально отвечает сайтам, а не только дефолтному. Переход на другую мажорную ветку в том же окне отдельная работа. Плагин или тема WordPress могут не пережить удалённую функцию, и белый экран даст скачок версии.
Базу этот релиз не мигрирует. mysql_upgrade и смена MariaDB здесь ни при чём: меняется интерпретатор. Бэкап по вашему обычному расписанию полезен сам по себе, но это не шаг перед сменой PHP. FastCGI-кэш nginx, если он включён, после reload FPM может ещё отдавать готовые страницы. Сбрасывать его заранее не нужно. Это нужно, только если конкретная страница после обновления ведёт себя не так, как до него.
Если сайт после reload молчит, смотрят журнал этого юнита FPM. Белый экран после смены PHP чаще начинается там, не в логе WordPress и не в error.log nginx.
До 14:00 UTC работа короткая: запомнить юнит, не трогать nginx и не качать RC3. После публикации на php.net обновляют свою ветку тем способом, которым PHP уже стоит, и перечитывают пул.
