Как обновить PHP на VPS: Ubuntu, Debian, AlmaLinux, репозитории Ondřej и Remi

21 октября 2026 года PHP выпустил версии 8.5.12, 8.4.27, 8.3.36 и 8.2.35 с исправлением двух критических уязвимостей PHP2Shell, которые позволяют выполнить код на сервере без авторизации. Ветки 8.1 и старше от проекта PHP исправлений больше не получают. На виртуальном хостинге патч ставит провайдер, а на VPS — владелец сервера: Beget, например, прямо написал в своём заявлении, что VPS клиенты обновляют сами. Подробности инцидента — в нашей новости о PHP2Shell, здесь — только практика: обновление PHP на Ubuntu, Debian и AlmaLinux.

Команды редакция сверила с документацией и исходниками пакетов — packages.sury.org, PPA на Launchpad, мастером репозитория Remi, бюллетенями Ubuntu, Debian и AlmaLinux. Версии пакетов проверены на 21–22.10.2026, часть команд — на нашем тестовом VPS с Ubuntu 22.04 в режиме только чтения.

Откуда на сервере PHP и почему от этого зависит способ обновления

PHP на сервере может прийти из разных источников, и у каждого свой порядок обновления. Ubuntu и RHEL-семейство обычно сохраняют старый номер версии и вшивают патч внутрь: исправленный PHP на Ubuntu 24.04 по-прежнему называется 8.3.6, на AlmaLinux 9 — 8.3.33. Debian на этот раз обновил свои ветки до 8.2.35 и 8.4.27. Сторонние репозитории Ondřej Surý и Remi выпускают версии PHP один в один, и там исправленная сборка называется 8.3.36.

# Debian и Ubuntu: какие пакеты PHP стоят и из какого репозитория
dpkg -l 'php*' | awk '/^ii/{print $2, $3}'
apt-cache policy php8.3-fpm
ls /etc/apt/sources.list.d/

# AlmaLinux, Rocky, RHEL
rpm -qa 'php*'
dnf repolist
dnf module list php

Если в версии пакета есть deb.sury.org, PHP пришёл из репозитория Ondřej Surý или его PPA. Суффикс remi означает Remi, alma или module_el9 — пакеты дистрибутива. Отдельный случай — панели управления: ISPmanager ставит альтернативные версии PHP в /opt/, и они обновляются не так, как системные. Как узнать, какая версия на самом деле обслуживает сайт, а не только консоль, разбираем в гайде о проверке версии PHP.

Статус исправлений PHP2Shell по дистрибутивам и репозиториям

Сверять нужно полную версию пакета с бюллетенем, а не номер, который показывает php -v. Таблица собрана по бюллетеням на вечер 21.10.2026 по UTC.

Debian forky и sid в трекере Debian на 21.10 значились уязвимыми. AlmaLinux, по блогу дистрибутива, сначала выложил пакеты в тестовый репозиторий, а в 21:15 UTC перенёс в основные. По сводке Маттиаса Гениара, в 10:40 UTC 21.10 стало известно, что Remi в этот день исправление не выпустит, а в 19:20 UTC — что фикс для 8.2–8.5 на RHEL 8, 9 и 10 в репозитории всё же есть. В Alpine edge на 18:39 UTC оставались 8.3.35, 8.4.26 и 8.5.11. 22.10 мы проверили сами: в репозитории Remi для EL9 лежит php-fpm-8.3.36 с записью в changelog от 22.10, а в Alpine 3.24 — php83-fpm 8.3.36-r0 со сборкой от 21.10. Зеркала синхронизируются с задержкой, поэтому версию в своём репозитории всё равно сверяют перед обновлением.

Что сделать до обновления

Регрессии бывают и при обновлении внутри ветки, а при переходе на новую ветку дополнительно меняются расширения, умолчания php.ini и поведение функций. Минимум перед любым вариантом — снимок диска в панели хостера или бэкап по схеме из гайда по бэкапам VPS; чем они отличаются при откате, объясняем в сравнении снапшота и бэкапа. Для WordPress есть и бэкап средствами CMS перед обновлением PHP.

# Debian/Ubuntu, от root (sudo -i). Архив конфигов PHP и веб-сервера —
# укажите те каталоги, что есть на сервере
tar czf /root/php-configs-$(date +%F).tgz /etc/php /etc/nginx
ls -lh /root/php-configs-*.tgz

# Список пакетов текущей ветки — понадобится при переходе
dpkg -l 'php8.2*' | awk '/^ii/{print $2}' > /root/php82-packages.txt

Обновление PHP в пределах ветки на Ubuntu и Debian

Это основной путь после PHP2Shell: ветка остаётся прежней, приходит сборка с патчем. Начинать нужно с apt update. На нашем тестовом VPS с Ubuntu 22.04 списки пакетов не обновлялись с мая, и apt-cache policy php8.1-fpm предлагал кандидата 8.1.2-1ubuntu2.23 — сборку без патча, тогда как исправленная по USN-8948-1 называется 8.1.2-1ubuntu2.28.

sudo apt update
apt list --upgradable 2>/dev/null | grep -i php

# Обновить только PHP (пример для ветки 8.3; модуль Apache — отдельным пакетом)
sudo apt install --only-upgrade 'php8.3*' libapache2-mod-php8.3

# Или все обновления разом
sudo apt upgrade

Убедиться, что патч на месте, можно по changelog пакета: в записи о новой ревизии перечислены закрытые CVE. Для пакетов дистрибутива php -v покажет старый номер, это нормально.

dpkg -l php8.3-fpm | tail -1
zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php8.3-fpm/changelog.Debian.gz

Обновление PHP в пределах ветки на AlmaLinux, Rocky и RHEL

В RHEL-семействе PHP разложен по потокам модулей (php:8.1, php:8.2, php:8.3) и пакету по умолчанию. AlmaLinux рекомендует для обновления две команды и перезапуск FPM.

sudo dnf clean metadata && sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm

# Проверить сборку: AlmaLinux сверяет её по суффиксу .alma.1
rpm -q php-common
rpm -q php8.4-common          # PHP 8.4 на AlmaLinux 10
rpm -q --changelog php-common | head -20
dnf updateinfo list --security | grep -i php

На AlmaLinux 8 с mod_php вместо FPM перезапускают Apache: sudo systemctl restart httpd. Потоки php:7.2, 7.3, 8.0 на AlmaLinux 8 и php:8.1 на AlmaLinux 9 сняты с поддержки: этот патч они получили, следующие не гарантированы.

Переход на новую ветку на Debian и Ubuntu: sury.org и PPA ondrej

Переходить на новую ветку имеет смысл, если в дистрибутиве PHP, который проект PHP уже не поддерживает или скоро перестанет: на Ubuntu 22.04 это 8.1, на Debian 12 — 8.2 с поддержкой безопасности до 31.12.2026. Сроки по таблице на php.net: 8.3 получает исправления до 31.12.2027, 8.4 — до 31.12.2028, 8.5 — до 31.12.2029. Дистрибутив свою ветку при этом продолжает патчить — USN-8948-1 закрыл PHP2Shell и в 8.1 на Ubuntu 22.04. Свежие ветки для Debian и Ubuntu собирает Ondřej Surý, один из сопровождающих пакетов PHP в самом Debian.

Подключение репозитория

Для Debian 12 и 13 официальный способ — скрипт из README packages.sury.org. Ключ ставится пакетом, репозиторий прописывается с signed-by:

sudo apt-get update
sudo apt-get -y install lsb-release ca-certificates curl
sudo curl -sSLo /tmp/debsuryorg-archive-keyring.deb https://packages.sury.org/debsuryorg-archive-keyring.deb
sudo dpkg -i /tmp/debsuryorg-archive-keyring.deb
sudo sh -c 'echo "deb [signed-by=/usr/share/keyrings/debsuryorg-archive-keyring.gpg] https://packages.sury.org/php/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/php.list'
sudo apt-get update

Для Ubuntu 22.04 и 24.04 привычный путь — PPA. Сейчас на странице ppa:ondrej/php сказано, что репозиторий переезжает в packages.sury.org: для Ubuntu 26.04 основной источник уже sury.org, а для Jammy и Noble PPA пока работает, инструкцию по миграции автор обещает позже. По данным Launchpad, 21.10.2026 в 14:45 UTC в PPA опубликованы 8.2.35, 8.3.36, 8.4.27 и 8.5.12 для Jammy и Noble. Сборки для arm64 по 8.4 и 8.5, по сводке Гениара, догнали amd64 только к вечеру.

sudo apt install software-properties-common
sudo add-apt-repository ppa:ondrej/php
sudo apt update

При следующем apt upgrade APT, скорее всего, заменит сборками Ondřej Surý и уже установленную ветку дистрибутива. По dpkg --compare-versions 8.2.35-1+0~20261021… из sury.org новее дебиановской 8.2.35-1~deb12u1, а 8.3.36-1+ubuntu24.04.1+deb.sury.org+1 из PPA — новее убунтовской 8.3.6-0ubuntu0.24.04.13. Что именно поставит APT, показывают apt-cache policy php8.2-fpm и пробный прогон apt-get -s upgrade.

Установка php8.x-fpm и тех же модулей

Новая ветка ставится рядом со старой, обе работают одновременно, у каждой свой сервис и свой сокет. Список модулей берём из файла, сохранённого на шаге подготовки, и меняем в нём номер ветки:

sudo apt install php8.3-fpm php8.3-cli
sed 's/^php8\.2/php8.3/' /root/php82-packages.txt | grep -v -E '^php8\.3-(fpm|cli)$' | xargs sudo apt install -y

Если apt сообщит, что пакета нет, причину выясняют до переключения сайта: модуль мог стать частью ядра PHP, сменить имя или ещё не собраться для новой ветки. Сайт переводят на новую версию, только когда на месте все расширения, которые требует приложение.

Перенос настроек php.ini и пулов

Файлы php.ini целиком из старой ветки не копируют: в новой версии другие умолчания и удалённые директивы. Надёжнее найти собственные правки, сравнив рабочий файл с эталоном пакета, и вынести их в отдельный файл в conf.d, который подхватит только FPM:

# Свои правки = отличия рабочего php.ini от эталона той же ветки
diff /usr/lib/php/8.2/php.ini-production /etc/php/8.2/fpm/php.ini
sudo nano /etc/php/8.3/fpm/conf.d/99-custom.ini

Пулы из /etc/php/8.2/fpm/pool.d/ копируют в /etc/php/8.3/fpm/pool.d/ и в каждом меняют путь listen. Если оставить старый, обе версии FPM попытаются слушать один и тот же сокет. Команда sed ниже сработает, только если в пути есть номер ветки; адреса вроде /run/php/site.sock или 127.0.0.1:9000 меняют вручную на свободные и тот же адрес прописывают в конфиге сайта. Стандартный пул www.conf уже настроен на /run/php/php8.3-fpm.sock. Конфиг проверяют до запуска:

sudo cp /etc/php/8.2/fpm/pool.d/site.conf /etc/php/8.3/fpm/pool.d/
sudo sed -i 's#php8\.2-fpm#php8.3-fpm#' /etc/php/8.3/fpm/pool.d/site.conf
grep -H '^listen' /etc/php/8.3/fpm/pool.d/*.conf
sudo php-fpm8.3 -t && sudo systemctl restart php8.3-fpm

Переключение nginx и Apache на новый сокет FPM

Для nginx достаточно заменить путь в fastcgi_pass и мягко перечитать конфиг. Базовую настройку сервера и блоков location мы разбирали в гайде по настройке nginx.

grep -rn 'php8.2-fpm.sock' /etc/nginx/
sudo sed -i 's#php8\.2-fpm\.sock#php8.3-fpm.sock#g' /etc/nginx/sites-available/example.conf
sudo nginx -t && sudo systemctl reload nginx

В Debian и Ubuntu есть ловушка с общим сокетом /run/php/php-fpm.sock. Служба FPM при старте регистрирует его через update-alternatives с приоритетом по номеру ветки (82, 83 и так далее), это видно в unit-файле пакета. Если в nginx прописан именно общий сокет, после установки 8.3 сайт может незаметно переехать на новую ветку сам. Проверить текущую привязку можно командой update-alternatives --display php-fpm.sock.

Для Apache с PHP-FPM пакет ставит готовый конфиг, который нужно включить вместо старого, — именно эти команды выводит установщик php8.3-fpm:

sudo a2enmod proxy_fcgi setenvif
sudo a2disconf php8.2-fpm
sudo a2enconf php8.3-fpm
sudo apachectl configtest && sudo systemctl reload apache2

Для Apache с mod_php модуль переключают вручную: установщик libapache2-mod-php8.3 не включит новый модуль, пока включён старый, и выведет ошибку «module already enabled». Чем отличаются схемы Apache и nginx с FPM, объясняем в сравнении nginx и Apache; по бюллетеню PHP риск PHP2Shell для mod_php самый высокий.

sudo apt install libapache2-mod-php8.3
sudo a2dismod php8.2
sudo a2enmod php8.3
sudo systemctl restart apache2

Консольный PHP и cron

Команда php в консоли тоже управляется через update-alternatives, и у новой ветки приоритет выше. Если alternatives в автоматическом режиме, после установки php8.3-cli задания cron и скрипты деплоя, вызывающие просто php, начнут работать на 8.3. Если сайт пока остаётся на 8.2, консоль фиксируют вручную:

update-alternatives --display php
sudo update-alternatives --set php /usr/bin/php8.2

Старую ветку отключают, когда сайт неделю-другую проработал на новой: sudo systemctl disable --now php8.2-fpm. Удалять пакеты 8.2 спешить не нужно — это быстрый путь отката.

Переход на новую ветку на AlmaLinux и RHEL: модули AppStream и Remi

Мастер настройки Remi описывает, что есть в официальных репозиториях: в EL 9 — PHP 8.0, 8.1, 8.2 и 8.3, в EL 8 — 7.4 и 8.2, в EL 10 — 8.3. На EL 8 и 9, если dnf module list php показывает нужный поток, проще всего переключиться на него. В EL 10 модулей в AppStream нет: там PHP 8.3 идёт обычными пакетами, а 8.4 на AlmaLinux 10 — отдельными пакетами php8.4-*. Команда dnf module switch-to по документации dnf включает новый поток и меняет версии установленных пакетов:

dnf module list php
sudo dnf module switch-to php:8.3
sudo systemctl restart php-fpm

Свежих веток в дистрибутиве нет, их собирает Remi Collet. По мастеру Remi для EL 9 и режима «одна версия», когда пакеты Remi заменяют системные с теми же именами php-*:

sudo dnf config-manager --set-enabled crb
sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
sudo dnf install https://rpms.remirepo.net/enterprise/remi-release-9.rpm
sudo dnf module switch-to php:remi-8.3
php --version
php --modules

Это команды для AlmaLinux и Rocky. На RHEL 9 CodeReady Builder мастер Remi включает иначе: subscription-manager repos --enable codeready-builder-for-rhel-9-x86_64-rpms. Для EL 8 репозиторий называется powertools, а в адресах стоит 8 вместо 9; для EL 10 — 10. В этом режиме сокет FPM не меняется: пакеты PHP в RHEL-семействе по умолчанию слушают /run/php-fpm/www.sock, а nginx и Apache уже настроены на него через /etc/nginx/conf.d/php-fpm.conf и /etc/httpd/conf.d/php.conf. Настройки остаются в /etc/php.ini и /etc/php-fpm.d/.

Для нескольких версий одновременно Remi предлагает пакеты-коллекции: php83, php83-php-fpm, отдельный сервис php83-php-fpm, пул в /etc/opt/remi/php83/php-fpm.d/www.conf и сокет /var/opt/remi/php83/run/php-fpm/www.sock. На этот сокет и переключают fastcgi_pass или SetHandler нужного сайта. Обновляются такие пакеты отдельно: sudo dnf upgrade 'php83-*' и перезапуск php83-php-fpm.

Перезапуск: когда хватит reload, а когда нужен restart

Пакет меняет файлы на диске, но работающий процесс держит старый PHP в памяти, пока его не перезапустят. Hadrian и сводный сайт Wiz php2shell.com прямо предупреждают: старые воркеры продолжают выполнять уязвимый код. Что перезапускать, зависит от того, как PHP подключён к веб-серверу.

Гениар проверил это на практике: после reload FPM мастер и воркеры работали на новом бинарнике, а Apache после graceful и apachectl -k restart держал старый libphp8.3.so до полной остановки и запуска — именно это делает systemctl restart.

Docker: пересборка образа с —pull

Официальные образы php на Docker Hub обновили до 8.2.35, 8.3.36, 8.4.27 и 8.5.12 — это зафиксировано в PR #1694 в docker-library/php, влитом 21.10. Обычная пересборка возьмёт закэшированный базовый образ, поэтому нужен флаг --pull, который по справке Docker Compose всегда пытается скачать более новую версию образа.

# Свой образ на базе php:8.3-fpm
docker build --pull -t myapp:php8.3 .

# Docker Compose: пересборка и пересоздание контейнеров
docker compose build --pull
docker compose up -d --force-recreate

# Какой PHP внутри
docker compose exec php php -v

Если образ собран на пакетах Alpine, версию PHP внутри после пересборки проверяют отдельно. Основы контейнеров — в нашем гайде о Docker.

Панели ISPmanager и HestiaCP

В документации ISPmanager сказано, что нативную версию PHP панель сменить не даёт: это версия из официального репозитория ОС, и обновляется она через apt или dnf, как описано выше. Альтернативные версии ставятся из репозитория ispmanager в /opt/ через «Настройки → Конфигурация ПО → Альтернативная версия PHP», а для режима «FastCGI (Nginx + PHP-FPM)» версию меняют на уровне пользователя. Заявления ispmanager о PHP2Shell на 21.10 мы не нашли, так что версии стоит проверять в «Настройки → Настройки PHP». Возможности панели — в обзоре ISPmanager.

В HestiaCP версии PHP-FPM для сайтов управляются командами из справочника CLI. Новую ветку добавляют, переводят на неё домен через шаблон бэкенда и удаляют старую, когда её не использует ни один домен:

v-list-sys-php
v-add-web-php 8.3
v-change-web-domain-backend-tpl admin example.com PHP-8_3
v-delete-web-php 8.2

По PHP2Shell участник команды HestiaCP 21.10 написал на форуме панели, что пакеты собственного PHP панели (hestia-php) собираются, но это займёт время. В той же ветке есть скрипт подключения sury.org для системного PHP сайтов. Для самой панели до выхода пакетов предложено два варианта: временно отключить HestiaCP или прописать в /usr/local/hestia/php/lib/php.ini memory_limit=-1, post_max_size = 8M и session.upload_progress.enabled=0. По бюллетеню PHP такие меры снижают риск, но обновление не заменяют. Установку панели с нуля мы показывали в гайде по HestiaCP.

Проверка после обновления

Проверять нужно три вещи: какая сборка стоит, что ни один процесс не держит старый PHP и что сайт отвечает. Сборку показывают dpkg -l или rpm -q из разделов выше. Для процессов Гениар предлагает команду, которая ищет в памяти процессов удалённые с диска библиотеки из /usr, /lib и /opt. Пустой вывод значит, что после обновления не осталось процессов со старыми файлами; версию каждого используемого PHP всё равно проверяют отдельно. На Debian и Ubuntu то же умеет needrestart:

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

Обе команды мы запускали на тестовом VPS: они только читают состояние системы. Дальше — сам сайт: главная, форма входа, загрузка файла, журнал ошибок PHP-FPM (/var/log/php8.3-fpm.log в Debian и Ubuntu, /var/log/php-fpm/ в RHEL) и журнал веб-сервера.

Если до патча вы ставили временные меры из бюллетеня PHP, часть из них после обновления нужно вернуть. Неограниченный memory_limit = -1 меняют обратно на реальный лимит, pm.max_requests — на прежнее значение, блокировку multipart-запросов на веб-сервере снимают, иначе не работают загрузки файлов. session.upload_progress.enabled = 0 PHP советует оставить, если сайт не показывает прогресс загрузки через эту функцию. Если сервер был доступен из интернета на уязвимой версии, после обновления имеет смысл пройти проверку VPS на взлом.

План обновления на одну страницу

1. Определить источник PHP: дистрибутив, sury.org/PPA, Remi, панель или Docker.
2. Сделать снимок диска или бэкап, сохранить /etc/php и конфиги веб-сервера.
3. Обновиться внутри ветки: apt update && apt install --only-upgrade 'php8.3*' или dnf upgrade 'php*'.
4. Сверить ревизию пакета с бюллетенем, а не php -v.
5. Если для текущей ветки исправления нет или она близка к концу поддержки — после проверки совместимости перейти на 8.3–8.5 через sury.org, PPA ondrej, поток модуля или Remi.
6. Перенести свои настройки php.ini и пулы, переключить nginx или Apache на новый сокет, проверить консольный php.
7. Перезапустить FPM, а при mod_php — Apache полностью, через restart.
8. Убедиться, что старый PHP не висит в памяти, и вернуть временные меры.

Если следить за патчами на сервере некому, эту работу можно отдать провайдеру: на хостинге с поддержкой PHP обновления ставит хостер, а порядок действий там описан в гайде об обновлении PHP на хостинге. Свой сервер подбирают в каталоге VPS и VDS или среди Linux-VPS.