PHP2Shell CVE-2026-109618 и 109619 на Debian и Ubuntu: Sury, PPA и apt

На 21 октября 2026 исправленные пакеты PHP вышли для Ubuntu 22.04, 24.04 и 26.04, для Debian 12 и 13; Ubuntu 20.04 получает их только через Ubuntu Pro, для Debian 11 исправления нет. Обновите пакеты через apt, затем обязательно перезапустите PHP-FPM или Apache (для mod_php — restart, не reload) и проверьте, что процессы не держат старый код. Статус Sury для веток 7.4 и 8.1 проверяйте заново командой apt-cache policy.

Что известно на 21 октября 2026 и что делать первым делом на Debian и Ubuntu

Сегодня, 21 октября 2026, вышли исправления для двух критических уязвимостей ядра PHP: CVE-2026-109618 и CVE-2026-109619 (обе CVSS v4.0 — 9.2). Публикация и релиз пакетов состоялись около 14:00 UTC, раскрытие ускорили из-за утечки деталей накануне. Обе ошибки используются без аутентификации, из сети, через запрос multipart/form-data, и затрагивают конфигурацию по умолчанию. Общий разбор мы дали в статье PHP2Shell: что делать за первый час, а здесь разбираем только Debian и Ubuntu, где у админа пять типичных задач: поставить исправленный пакет, перезапустить PHP, убедиться, что работает новый код, не сломать смешанные репозитории и честно решить, что делать с версиями без поддержки.

Картина по системам на момент проверки такая. Ubuntu 22.04, 24.04 и 26.04 получили исправленные пакеты в штатных репозиториях (USN-8948-1 и USN-8948-2). Для Ubuntu 20.04 исправление доступно только по подписке Ubuntu Pro (ESM). Для Debian 12 и Debian 13 заведены обновления безопасности, причём на момент одной из проверок пакет для Debian 12 в зеркалах ещё не появился, поэтому проверять нужно у себя командой apt-cache policy, а не по новостям. Для Debian 11 срок LTS закончился 31 августа 2026 года, и для PHP 7.4 исправления нет. Про репозиторий Сури (Sury) картина промежуточная: сборки 8.2.35, 8.3.36, 8.4.27 и 8.5.12 вышли, а подтверждения, что собраны 7.4 и 8.1, на момент проверки не было. Всё это быстро меняется, поэтому статус на вашей машине всегда подтверждайте командами из статьи.

Порядок действий у нас стандартный и короткий. Сначала инвентаризация: на каждом сервере выясняем, какие версии PHP стоят и откуда они взяты (дистрибутив или Sury). Затем обновление пакетов и обязательный перезапуск сервисов. Затем проверка, что в памяти живёт новый код. Если обновить нельзя, ставим временные меры и планируем миграцию. Инвентаризацию серверов удобно вести в учётной системе, о том, как её организовать, мы писали в статьях про инвентаризацию ИТ-активов и учёт техники и заявок в GLPI.

Покажем на условном примере. Интернет-магазин «Лавка Мастеров», пятнадцать рабочих мест: витрина на Ubuntu 22.04 с PHP-FPM, старый складской портал на Debian 11 с PHP 7.4 и тестовая копия на Ubuntu 24.04. Мы описываем подход, а не результаты. Витрину обновляем первой, потому что она смотрит в интернет и принимает загрузки файлов. Тестовую копию обновляем следом и используем как репетицию отката. Складской портал на Debian 11 официального исправления не получит, поэтому для него мы сразу закладываем два шага: закрыть доступ из интернета и запланировать переезд на поддерживаемую систему.

• Выяснить версии: `php -v`, `dpkg -l 'php*' | grep ^ii`, источники пакетов через `apt-cache policy`.
• Обновить пакеты PHP и сразу перезапустить FPM или Apache.
• Проверить, что процессы не держат удалённые файлы старой библиотеки.
• Для 20.04 подключить Ubuntu Pro и выполнить `pro fix`; для Debian 11 решать вопрос миграции.
• Если обновить нельзя — временные меры и ограничение доступа, но не вместо патча.

Таблица исправленных версий: Debian 11/12/13 и Ubuntu 20.04–26.04

Ниже сводка версий, начиная с которых пакет считается исправленным. Данные взяты из уведомлений Ubuntu (USN-8948-1 и USN-8948-2) и из сообщений Debian (DLA-4848-1 для Debian 12, DSA-6574-1 для Debian 13). Если у вас версия не ниже указанной, пакет исправлен. Если ниже — обновляйтесь. Для Sury и PPA версии устроены иначе (суффикс вроде +deb.sury.org), их сравнивают с upstream-номером, об этом дальше.

Upstream-версии, в которых исправление включено в сам PHP: 8.5.12, 8.4.27, 8.3.36 и 8.2.35, релиз 21 октября 2026 года. Ветки 8.1 и старше официально не поддерживаются, исправления в них от разработчиков PHP нет. Это не значит, что Ubuntu 22.04 остаётся уязвимой: дистрибутив делает собственный бэкпорт и сохраняет номер 8.1.2 с новым суффиксом. Поэтому ориентироваться на выхлоп php -v нельзя: он покажет 8.1.2-1ubuntu2.28, и только по суффиксу видно, что это исправленная сборка. Это одна из самых частых путаниц: админ видит «8.1.2» и решает, что стоит древняя версия, хотя на самом деле пакет уже заменён.

Для более старых релизов Ubuntu по тем же уведомлениям: 18.04 — php7.2 7.2.24-0ubuntu0.18.04.17+esm14, 16.04 — php7.0 7.0.33-0ubuntu0.16.04.16+esm22, 14.04 — php5 5.5.9+dfsg-1ubuntu4.29+esm18. Все они доступны только в ESM. Если у клиента такие системы ещё живы, мы не обсуждаем «как обновить», а обсуждаем, как быстро их вывести из эксплуатации или спрятать от внешнего трафика.

Для самопроверки сравнивайте установленную версию с таблицей средствами dpkg, а не глазами. Команда вернёт «OK», если версия пакета не ниже исправленной. Подставьте свой пакет и версию из таблицы.

dpkg --compare-versions "$(dpkg-query -W -f='${Version}' php8.3-fpm)" ge 8.3.6-0ubuntu0.24.04.13 && echo OK || echo NEED-UPDATE

Глазами лучше смотреть журнал изменений пакета. Если в changelog есть упоминание CVE-ID, это прямое подтверждение. Для Debian и Sury журнал может быть без номеров CVE, тогда сравнивайте версию.

zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php8.3-fpm/changelog.Debian.gz
apt changelog php8.3-fpm | head -n 30

apt-команды: проверить, обновить, подтвердить

Сначала смотрим, что вообще установлено. Список пакетов PHP по именам вида php8.3 удобно получить командой из рекомендации Ubuntu. Она показывает только метапакеты и интерпретаторы, без десятков расширений.

apt list '?installed ?name(^php[0-9.]+$)'
dpkg -l 'php*' | grep ^ii | awk '{print $2, $3}'
php -v

Дальше обновляем. Важно не обновлять систему целиком вслепую на production, а точечно подтянуть пакеты PHP. Команда с --only-upgrade не поставит новые пакеты, а лишь обновит уже установленные. Перед этим всегда выполняем apt update: без свежего индекса apt не увидит исправления.

sudo apt update
sudo apt install --only-upgrade '?name(^php[0-9.]+$)'

Шаблон ?name(^php[0-9.]+$) ловит метапакеты вида php8.3, но не затрагивает расширения. Зависимости apt подтянет сам: расширения php8.3-fpm, php8.3-cli, php8.3-mysql и так далее приходят из того же исходного пакета и обновляются вместе. Если у вас расширения установлены без метапакета, добавьте их в команду либо выполните sudo apt upgrade на тестовой машине, чтобы заранее увидеть полный список. Мы всегда читаем вывод apt перед согласием: нас интересуют строки с php и любые удаляемые пакеты. Если список на удаление выглядит неожиданно, останавливаемся и разбираемся.

После обновления проверяем, что кандидат и установленная версия совпали. В выводе apt-cache policy строки Installed и Candidate должны быть равны, а в таблице версий (см. выше) номер должен быть не ниже исправленного.

apt-cache policy php8.3-fpm
apt list -a php8.3-fpm 2>/dev/null | head

Если Candidate показывает старую версию, причин обычно три: не выполнен apt update, нужный репозиторий безопасности не включён в sources.list или пакет приходит из стороннего источника с более высоким приоритетом. Для Debian 12 учитывайте, что на момент одной из проверок обновление в зеркалах ещё не появилось. Это нормально для первых часов после релиза: подождите и повторите. Не пытайтесь компенсировать это ручным скачиванием .deb из случайных мест.

Для Ubuntu 20.04 штатный репозиторий исправление не получит. Нужен Ubuntu Pro. Порядок такой: подключаем машину токеном, затем просим систему применить исправление для конкретной CVE. Команда pro fix сама проверит, затронута ли система, и поставит нужные пакеты ESM.

sudo pro attach <ТОКЕН>
pro status
sudo pro fix CVE-2026-109618
sudo pro fix CVE-2026-109619

Токен берётся в личном кабинете Canonical, а условия подписки уточняйте у вендора. Мы не храним токены в заметках и скриптах: передаём их через сейф паролей, как и любые другие секреты. После pro fix версия пакета php7.4 должна оканчиваться на +esm5 или выше. Если машина не подключена к Pro, команда подскажет, что нужно сделать.

Если на сервере включены конфигурационные подсказки dpkg (вопрос про замену файла настроек), не давите «Y» автоматически. Для PHP мы сохраняем собственные php.ini и пулы FPM. Безопаснее обновлять с параметром, который сохраняет локальные версии конфигов, а новые варианты сравнивать вручную.

sudo apt install --only-upgrade -o Dpkg::Options::="--force-confold" '?name(^php[0-9.]+$)'

Sury и PPA ondrej: несколько версий PHP на одном сервере

На Debian и Ubuntu многие ставят PHP не из дистрибутива, а из репозитория Ондржея Сури: packages.sury.org для Debian и ppa:ondrej/php для Ubuntu. Причина понятна: можно держать рядом 7.4, 8.1 и 8.3 и переключать сайты по одному. На одном сервере у нас часто стоят три версии, потому что старое приложение не готово к новой ветке. Эта же гибкость создаёт главный риск этой уязвимости: уязвимым считается каждый установленный интерпретатор, который обслуживает хотя бы один сайт, и патчить нужно каждую ветку отдельно.

Что известно по Sury на 21 октября 2026. Пакеты 8.2.35, 8.3.36, 8.4.27 и 8.5.12 опубликованы для amd64 и arm64. Автор репозитория заявил, что бэкпорт будет сделан для каждой версии PHP в его репозитории (от 5.6 до 8.1) на всех поддерживаемых Debian и Ubuntu. Но подтверждения, что сборки для 7.4 и 8.1 уже вышли, на момент проверки не было. Поэтому формулируем осторожно: заявление есть, готовых пакетов для старых веток мы не подтверждали. Проверяйте сами.

Как проверить, что бэкпорт для 7.4 или 8.1 вышел. Смотрим кандидата и сравниваем его с тем, что у вас стоит. Если после apt update версия не изменилась, исправления там ещё нет. Если изменилась, открываем changelog и читаем, что именно сделано. В журнале Sury номера CVE могут отсутствовать, поэтому одной строки grep недостаточно: смотрим дату и описание записи.

sudo apt update
apt-cache policy php7.4-fpm php8.1-fpm
apt changelog php7.4-fpm | head -n 25
apt list --upgradable 2>/dev/null | grep -i php

Что видеть в выводе. Строка Installed и строка Candidate: если Candidate выше установленной, бэкпорт доступен. Строка источника справа покажет, откуда пришёл пакет: packages.sury.org или ppa.launchpadcontent.net/ondrej. Версия вида 8.3.36-1+ubuntu24.04.1+deb.sury.org+1 содержит upstream-номер 8.3.36 — это исправленная ветка. Версия вида 8.1.34-1+... означает, что вы всё ещё на старой сборке, и в этом случае мы смотрим дату записи в changelog и не принимаем решение по одному номеру.

Если бэкпорта для старой ветки нет, варианты такие. Первый: перенести приложение на поддерживаемую ветку (8.2–8.5) и держать 7.4 или 8.1 только пока идёт тестирование. Второй: убрать старую версию из публичной видимости: отключить её пул FPM или закрыть сайт на ней по адресу, пока не появится пакет. Третий: собрать PHP из исходников по патчу, но тут важно помнить, что Patchstack писал о минимальных бэкпортах для 7.4, 8.0 и 8.1 только при сборке из исходников, и это уже зона ответственности того, кто собирает. Мы такой путь советуем лишь при наличии человека, который будет поддерживать сборку.

Подключение репозитория Sury на Debian делаем по инструкции автора: ставим пакет ключей и добавляем файл источника. На Ubuntu достаточно add-apt-repository. Ниже приведены стандартные шаги, но сверяйте их со страницей репозитория, потому что способ доставки ключа менялся.

# Ubuntu
sudo add-apt-repository ppa:ondrej/php
sudo apt update

# Debian: ключ и источник по инструкции на https://packages.sury.org/php/README.txt
apt-cache policy | grep -i sury

Несколько версий одновременно живут так. У каждой своя служба FPM (php7.4-fpm, php8.1-fpm, php8.3-fpm), свой сокет вида /run/php/php8.3-fpm.sock и своя папка конфигов /etc/php/8.3/. Сайт привязан к версии указанием сокета в конфиге nginx или обработчика в Apache. Команда update-alternatives --config php меняет только PHP в командной строке, на веб-обработку она не влияет. Это ещё одна ловушка: админ переключил альтернативу на 8.3 и решил, что всё переехало, а сайт по-прежнему отвечает через 7.4.

systemctl list-units 'php*-fpm*' --no-pager
ls /run/php/ /etc/php/
grep -R "fastcgi_pass\|SetHandler" /etc/nginx /etc/apache2 2>/dev/null | grep -i php
update-alternatives --list php

По этой выдаче составляем карту: какой сайт через какую версию работает, какие версии вообще не нужны. Забытые версии часто остаются после тестов: пул запущен, сайт давно не обслуживается, а порт открыт. Такой интерпретатор тоже уязвим, поэтому мы либо обновляем его, либо останавливаем и отключаем systemctl disable --now php7.4-fpm. Об особенностях панелей, где несколько версий PHP ведёт сама панель, читайте в статье про HestiaCP, ISPmanager и несколько версий PHP.

Debian 11 после конца LTS и Ubuntu 20.04: как жить, пока нет исправления

Debian 11 и PHP 7.4 — самая неприятная пара. Поддержка LTS закончилась 31 августа 2026 года, исправления для PHP 7.4 нет, и на системном уровне ждать его не стоит. Вывод, который мы делаем для клиентов, простой: система больше не получает официальных обновлений безопасности, значит уязвимость нужно закрывать архитектурно. Есть коммерческие программы расширенной поддержки от сторонних компаний, но будет ли там исправление для этой CVE, мы не подтверждали: проверьте у вендора. Не стоит строить план на надежде.

Реалистичных путей три. Первый — миграция на Debian 12 или 13 с PHP, который получает исправления (на Debian 12 это 8.2, на Debian 13 это 8.4). Для этого нужно проверить совместимость приложения с новой веткой, и именно поэтому мы начинаем с тестовой копии. Второй — оставить Debian 11, но поставить PHP из Sury для поддерживаемой ветки: подключаете репозиторий, ставите 8.2 или 8.3, переключаете сайт. Тут надо убедиться, что у Sury есть сборки под bullseye: подтверждения этого мы в фактах не имеем, смотрите страницу репозитория. Третий — не трогать PHP и изолировать сервер: ограничить доступ по IP, поставить перед ним обратный прокси, убрать из интернета. Это временная мера, и она не лечит.

Ubuntu 20.04 устроена проще: исправление есть, но только через Ubuntu Pro (ESM). Если подписки нет, у вас та же ситуация, что и у Debian 11. Пакет 7.4.3-4ubuntu2.29+esm5 не придёт обычным apt upgrade. Поэтому на 20.04 порядок следующий: подключить Pro, выполнить pro fix CVE-2026-109618 и pro fix CVE-2026-109619, перезапустить сервисы, проверить версию. Если подключать подписку не планируется, система должна оказаться в плане миграции на 22.04 или 24.04 с конкретной датой. Для компании на пятнадцать рабочих мест это нормальный разговор: тратиться на подписку для одной служебной машины или быстро её переселить.

Когда обновить сейчас не получается, у нас есть набор временных мер. Они частичные и ни в коем случае не заменяют обновление, но снижают риск. Что подтверждено по источникам. Первое: отключить отслеживание загрузки session.upload_progress.enabled=0 в php.ini или в конфиге пула FPM, но не через ini_set() и не через .user.ini, и перезапустить все воркеры. Одного этого мало, и по оценке разработчиков PHP надёжных обходных мер нет, единственное исправление — патч. Второе: для PHP 8.5 дополнительно fatal_error_backtraces=0. Третье: ограничения размера запроса и числа полей на веб-сервере. Четвёртое: блокировка multipart/form-data на уровне nginx или Apache, если на сайте нет загрузок, с оговоркой, что это ломает загрузку файлов и часть форм, в том числе корзину и оформление заказа в интернет-магазине, так что заказ нужно проверить руками.

# php-fpm пул, например /etc/php/8.1/fpm/pool.d/www.conf
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[post_max_size] = 8M

sudo php-fpm8.1 -t
sudo systemctl reload php8.1-fpm

Про memory_limit у источников разные рекомендации, и мы говорим о них прямо. Sansec предлагает memory_limit = -1, и это работает как мера против сценария нехватки памяти, но один запрос может съесть всю оперативную память сервера, поэтому нужен контроль RAM и лимиты на уровне контейнера или cgroup. Patchstack советует задавать это через php_admin_value, чтобы приложение не смогло переопределить значение, и ограничивать размер запроса. Не используйте RLIMIT_AS и RLIMIT_DATA. Выбор между ними зависит от сервера, и мы согласуем его с владельцем.

Блокировка multipart на nginx выглядит так, а на Apache делается через RewriteCond и RewriteRule. Обе вещи применимы только к сайтам без загрузок или после проверки заказа. Остановка PHP-FPM или режим «только GET и HEAD» тоже возможны, если сайт можно временно перевести в режим витрины-картинки. Более общую логику мер для всех платформ мы описали в обзорной статье серии, а специфику серверов на CentOS и Alma — в материале про CentOS, RHEL, Alma, Remi и EOL. Если серверы без поддержки нужно вести системно, это та работа, что мы делаем в рамках услуги обслуживание серверов и сайтов.

Рестарты: mod_php против FPM, needrestart и проверка

Обновление пакета не меняет код в уже запущенном процессе. Старый воркер продолжает жить с уязвимой библиотекой в памяти, пока его не перезапустят. Это самое частое место, где «обновили, но не защитились». Правила простые. PHP-FPM: systemctl restart php8.3-fpm, допустим и reload. mod_php: только systemctl restart apache2, а reload и graceful недостаточны. Если у вас Apache с mod_php и вы ограничились reload, сервер остаётся уязвимым. Для nginx с FPM перезапускать сам nginx не нужно, но нужно обновить и перезапустить пул FPM.

# какой режим у Apache
apache2ctl -M 2>/dev/null | grep -i php
systemctl list-units 'php*-fpm*' --no-pager

# перезапуск
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2   # если mod_php

Нужно перезапустить все версии, которые у вас работают: php7.4-fpm, php8.1-fpm и остальные. Пропущенная старая служба — классическая потеря. Для приложений на PHP, запущенных отдельно (очереди Laravel, Octane, FrankenPHP, воркеры Supervisor), нужны свои действия: php artisan queue:restart для очередей, перезапуск процесса для Octane (octane:reload недостаточно), новый релиз или образ для FrankenPHP, потому что apt его не лечит. Для LiteSpeed — обновить lsphpXY и выполнить pkill lsphp.

Теперь проверка, что в памяти нет старого кода. Первый способ — поиск процессов, которые держат удалённые файлы системных путей. Пустой вывод означает, что всё хорошо. Второй — утилита needrestart, она показывает службы, которым нужен перезапуск после обновления библиотек.

sudo grep -lE ' /(usr|lib|opt).*\(deleted\)$' /proc/[0-9]*/maps
sudo needrestart -b -r l

Как читать результат. Если первая команда выводит номера процессов, значит, у них в памяти файлы, которые были удалены обновлением, то есть старая версия. Нужно узнать, какие это процессы (ps -p <PID> -o pid,etime,cmd) и перезапустить соответствующую службу. needrestart в пакетном режиме выводит строки с префиксом NEEDRESTART-SVC: — это службы, которые требуют перезапуска. Если среди них php-fpm или apache2, перезапускаем.

Дальше полезно подтвердить версию именно того процесса, который отвечает на запросы, а не командной строки. У PHP CLI и FPM могут быть разные пакеты и разные ini-файлы. Для FPM смотрим версию исполняемого файла службы, а для Apache — модуль. Простой тест: временный файл с phpinfo() мы не оставляем на боевом сайте, поскольку он выдаёт лишнее, а проверяем из консоли php-fpm8.3 -v и сопоставляем с таблицей версий. Затем делаем контрольный запрос к сайту и смотрим журнал на ошибки после перезапуска.

php-fpm8.3 -v
systemctl status php8.3-fpm --no-pager | head -n 12
sudo journalctl -u php8.3-fpm --since '10 min ago' --no-pager | tail -n 20
sudo tail -n 20 /var/log/nginx/error.log

В нашем условном случае с «Лавкой Мастеров» мы после обновления витрины проверяем сначала версию пакета, затем перезапуск, затем отсутствие процессов с удалёнными файлами, затем руками оформляем тестовый заказ с загрузкой файла в личном кабинете. Только после этого считаем шаг закрытым. Тестовый заказ важен, потому что именно multipart-запросы затронуты, а ограничения на размер запроса, если вы их включали, нередко ломают форму оформления.

Отдельный пункт — следы возможной эксплуатации. Источники называют необычные multipart-запросы, после которых в журнале ошибка memory_limit или повторяющиеся HTTP 500, аномально большие или битые cookie PHPSESSID и необъяснимые перезапуски воркеров. Это не доказательство ни в ту, ни в другую сторону. Если признаки есть, мы обновляем сервер, считаем его возможно скомпрометированным и передаём владельцу список паролей и ключей на ротацию; сами пароли живых учёток не меняем. Как читать логи, разбираем в статье про признаки взлома в журналах nginx и Apache.

Откат, unattended-upgrades и частые ошибки

Сначала про откат, потому что вопрос задают чаще всего. Откат пакета PHP возвращает уязвимую версию, поэтому он оправдан только как кратковременная мера, если новое обновление сломало приложение и нужно срочно вернуть работоспособность. В этом случае параллельно включаем временные меры из предыдущих разделов. Технически откат делается установкой конкретной версии, которую apt ещё помнит. Смотрим доступные версии и историю операций, затем ставим нужную и фиксируем её, чтобы автообновление не вернуло исправленный пакет без вашего ведома.

apt list -a php8.3-fpm 2>/dev/null
grep -A3 'php8.3' /var/log/apt/history.log | tail -n 20
sudo apt install php8.3-fpm=<ВЕРСИЯ_ИЗ_СПИСКА> php8.3-cli=<ВЕРСИЯ_ИЗ_СПИСКА> php8.3-common=<ВЕРСИЯ_ИЗ_СПИСКА>
sudo apt-mark hold php8.3-fpm php8.3-cli php8.3-common
# снять фиксацию, когда проблема решена
sudo apt-mark unhold php8.3-fpm php8.3-cli php8.3-common

Версии нужно задавать у всех пакетов одной ветки, иначе apt откажется или создаст смесь разных сборок. Если старый пакет уже убран из зеркала, он недоступен, поэтому мы советуем на день обновления сохранять копии .deb из /var/cache/apt/archives/. Откат не заменяет план: после того как причина поломки найдена (чаще всего это старое расширение или несовместимость с новой минорной версией), возвращаемся на исправленную сборку. «Подержать старую пока тихо» — самая опасная формулировка этого месяца.

Теперь unattended-upgrades. Хорошая новость: на Debian и Ubuntu он по умолчанию ставит обновления безопасности. Плохие новости три. Первая: он сам не перезапускает PHP-сервисы, поэтому процессы останутся со старым кодом, пока кто-нибудь не перезапустит их или не перезагрузит сервер. Вторая: репозиторий Sury и PPA в список разрешённых источников по умолчанию не входят, и автоматического обновления из них не будет, если вы не добавили их в Origins-Pattern. Третья: фиксация пакетов через apt-mark hold, сделанная когда-то для стабильности, блокирует и это обновление. Проверяем так.

apt-mark showhold
grep -vE '^\s*//' /etc/apt/apt.conf.d/50unattended-upgrades | grep -A8 -E 'Allowed-Origins|Origins-Pattern'
sudo unattended-upgrade --dry-run -d 2>&1 | grep -i -E 'php|allowed origins|hold' | head
tail -n 30 /var/log/unattended-upgrades/unattended-upgrades.log

Если нужно, чтобы источник Sury обновлялся автоматически, его добавляют в Origins-Pattern в /etc/apt/apt.conf.d/50unattended-upgrades. Точные значения origin и archive смотрите командой apt-cache policy и в файлах Release вашего источника, мы не приводим готовую строку, потому что у Debian-репозитория и у PPA они разные. Принимать решение об автообновлении PHP из сторонних источников стоит осознанно: минорное обновление ветки иногда ломает старое приложение, а у «Лавки Мастеров» складской портал как раз такой.

Чтобы автоматические обновления были полезны, нужен перезапуск. Для этого существует needrestart. По умолчанию на серверах он может спрашивать подтверждения в интерактивном режиме, а при обновлении через unattended-upgrades вопросов нет, и службы остаются со старым кодом. Режим автоматического перезапуска включают в /etc/needrestart/needrestart.conf значением $nrconf{restart} = 'a';. Это безопасно не для всех серверов: перезапуск баз данных или служб, работающих с долгими задачами, может быть нежелателен, поэтому мы включаем автоперезапуск выборочно и исключаем критичные службы через $nrconf{override_rc}. Для PHP-FPM автоперезапуск обычно приемлем.

Типичные ошибки, с которыми мы сталкиваемся у клиентов. Ставят обновление и не перезапускают FPM. Делают reload Apache при mod_php. Проверяют php -v в консоли, а сайт работает на другой ветке. Забывают отдельный пул или старую версию с открытым сокетом. Думают, что update-alternatives переключил сайт. Остаются на Ubuntu 20.04 без Pro и считают, что apt upgrade всё сделает. Полагаются на Docker-образ, не пересобрав его: про такие сценарии читайте в статье про Docker, php-fpm, Nextcloud и mailcow. Ставят сниппеты и «плагины-заплатки» с форумов — Patchstack прямо предостерегает от них.

Ещё одно предупреждение про приоритеты. У Sury и у дистрибутива версии устроены по-разному, и если у вас смешанная установка, apt может предпочесть «старший» номер из Sury вместо исправленного пакета дистрибутива или наоборот. Всегда сверяйте источник в apt-cache policy и держите на сервере один выбранный источник для каждой ветки PHP. Если на сервере уже несколько лет накапливались источники, удобно навести порядок в рамках общего плана работ по серверам: так задача перестаёт быть авральной.

Наш чек-лист на один сервер после обновления: версия пакета не ниже исправленной; все ветки PHP, которые запущены, обновлены или остановлены; службы перезапущены (restart для mod_php); нет процессов с удалёнными файлами; тестовый заказ или загрузка файла прошли; журнал после перезапуска чистый; unattended-upgrades и needrestart проверены; записано, откуда пакет и когда сделана проверка. Если вы не успеваете сделать это сами по нескольким серверам, мы можем взять инвентаризацию и обновление на себя.

Частые вопросы