Как проверить и обновить PHP на VPS после критических уязвимостей: Ubuntu и Debian

В октябре 2026 года проект PHP закрыл две критические уязвимости, и одна из них — CVE-2026-109618. Если на вашем сервере работает сайт на PHP, нужно ответить на три вопроса: какая версия PHP стоит, исправлена ли она и работает ли уже исправленный код. Ниже — как обновить PHP на Ubuntu и Debian и не попасть в ловушку: на Ubuntu команда php -v может показывать старый номер даже после исправления.

Коротко. На Ubuntu версию PHP надёжнее проверять не по php -v, а по версии пакета (dpkg): Ubuntu переносит исправление в старую версию, и php -v на 24.04 по-прежнему пишет 8.3.6. На Debian 12 и 13 исправленный пакет сам даёт новый номер (8.2.35, 8.4.27), но сравнивать по пакету надёжно на всех системах. Обновитесь через apt, затем перезапустите PHP-FPM или Apache, потому что запущенный процесс сам не подхватит новый код. Если обновить нельзя, есть частичные меры, но они не делают установку безопасной. Данные на 27 октября 2026 года.

Что случилось: PHP-уязвимость CVE-2026-109618 и её соседка

21 октября 2026 года на php.net объявили о выходе PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35 (в журнале изменений 8.5.12 и 8.4.27 датированы 22 октября, поэтому правильно говорить «21-22 октября»). Эти версии закрывают две критические уязвимости: CVE-2026-109618 («RCE via OOM corruption») и CVE-2026-109619 («RCE via stale global state»). У обеих оценка по шкале CVSS v4.0 равна 9,2, у обеих уровень Critical.

RCE — удалённое выполнение кода: чужой код запускается на вашем сервере. Слова «без аутентификации» означают, что для начала атаки не нужна учётная запись ни на сайте, ни на сервере. Это описание возможности. Мы не утверждаем, что кого-то уже атаковали, и вам не стоит делать такой вывод только из номера CVE.

Под уязвимость подпадают ветки ниже исправленных версий: 8.2 ниже 8.2.35, 8.3 ниже 8.3.36, 8.4 ниже 8.4.27, 8.5 ниже 8.5.12. В зоне риска все способы запуска PHP для веба (они называются SAPI): PHP-FPM, Apache с mod_php, php-cgi, FrankenPHP, LiteSpeed. Выше всего риск у mod_php, то есть когда PHP встроен прямо в Apache. Подробности по данным авторов:

• для CVE-2026-109618 уязвимость подтверждена на mod_php; для FPM код по анализу восприимчив, но полного эксплойта авторы не показали;
• для CVE-2026-109619 проверен путь через жизненный цикл сессии, на mod_php и на FPM.

Полностью проблему закрывает только обновление. Остальное в статье — как его сделать и как проверить результат.

Какая версия PHP на сервере и как он запущен

Сначала выясняем две вещи: что установлено и каким способом PHP отвечает на запросы сайта. Это нужно, чтобы потом перезапустить именно ту службу. Подключитесь к серверу по SSH и выполните команды из карточки ниже. Мы снимали их на тестовом сервере с Ubuntu 24.04.5.

• php -v печатает версию PHP для командной строки (пометка cli). Это не всегда та версия, что отвечает сайту.
• dpkg -l показывает установленные пакеты, grep оставляет строки про PHP, awk выводит только имя и версию.

Как читать список. Если есть пакет php8.3-fpm (у вас может быть другая цифра), PHP работает отдельной службой FPM, а веб-сервер передаёт ей запросы. Если в списке есть пакет, в названии которого встречается mod-php, PHP встроен в Apache. Бывают оба варианта сразу, тогда обновлять и перезапускать нужно оба. В примерах ниже мы подставляем php8.3-fpm; вы подставляйте имя из своего списка.

Почему php -v на Ubuntu 24.04 показывает 8.3.6, хотя исправление уже установлено

Ubuntu не переходит на новую версию PHP внутри выпуска. Она берёт исправление из свежей версии и переносит его в уже установленную (это называется бэкпорт), а номер основной версии оставляет прежним. Поэтому на исправленной Ubuntu 24.04 команда php -v по-прежнему пишет «PHP 8.3.6», а не 8.3.36: на стенде пакет уже содержит исправление, а php -v показывает 8.3.6. На Ubuntu 22.04 исправленный пакет выводит полную версию пакета: «PHP 8.1.2-1ubuntu2.28». На Debian 12 и 13 всё иначе: там поставляется точечный выпуск проекта, и исправленный пакет сам пишет «PHP 8.2.35» (Debian 12) или «PHP 8.4.27» (Debian 13). Это значения из проверки в чистых образах этих систем. Один и тот же признак на разных системах читается по-разному, поэтому надёжнее всего сравнить версию пакета с таблицей ниже.

Мы сверили версии с кандидатами установки в чистых образах Ubuntu 24.04, Ubuntu 22.04, Debian 12 и Debian 13 на 27 октября 2026 года: везде кандидат совпал с указанным в таблице. Для PPA ветки 8.2 и 8.5 мы не проверяли. Ubuntu 26.04 в проверку не входила: если у вас она, сверьте пакет с уведомлением Ubuntu о безопасности самостоятельно.

Первый способ проверки: найти номер CVE в журнале изменений установленного пакета. Если запись есть, исправление в пакете присутствует. Файл с журналом называется /usr/share/doc/php8.X-common/changelog.Debian.gz (вместо X подставьте свою цифру), он есть на всех четырёх системах, а строки с CVE в выводе на Debian выглядят чуть иначе, чем в нашем примере. Ключ -m2 останавливает поиск после двух совпадений. Следом смотрим, что говорит apt-cache policy: строка Installed — что стоит, Candidate — что apt готов поставить.

Команду apt-get changelog мы тоже пробовали, но на нашем стенде она вернула ошибку 404: для этого пакета журнал на серверах Ubuntu недоступен. Файл в /usr/share/doc надёжнее, он лежит на самом сервере.

Второй способ точнее: сравнить версию установленного пакета с исправленной из таблицы. Пакетный менеджер умеет сравнивать версии с тильдами и суффиксами, обычное сравнение строк тут не годится. Команда dpkg --compare-versions A ge B отвечает, не меньше ли A, чем B. В первой строке ниже работает реальный пакет стенда. Во второй мы подставили версию с суффиксом .12: это пример того, как команда сообщает о старом пакете, на стенде такой пакет не стоял.

• FIXED — версия с исправлением из таблицы выше; для своей системы замените её и имя пакета (php8.3-fpm).
• dpkg-query -W -f="\${Version}" выводит версию установленного пакета.
• Слово OK в ответе означает, что стоит версия с исправлением или новее. UPDATE NEEDED — пора обновляться.

Как обновить PHP на Ubuntu и Debian

Перед обновлением сделайте копию сайта и базы: после обновления пакетов вернуться на прежнюю версию сложнее, чем сделать копию сейчас. В панели WeaselCloud нет снимков и бэкапов, поэтому копию делаете сами, как описано в инструкции как сделать бэкап VPS своими руками.

На Ubuntu и на Debian команды одинаковые. Первая обновляет список доступных версий пакетов, вторая ставит обновления, в том числе патчи безопасности. Ту же пару используют в инструкции про защиту свежего VPS. Если вы вошли как root или sudo не установлен, выполняйте команды без sudo:

sudo apt update && sudo apt upgrade

Команда покажет список пакетов, которые будут обновлены, и спросит подтверждение. Среди них будут пакеты php… с вашей версией. Выводить его здесь мы не стали: он зависит от вашего сервера. Если вы ставили PHP из репозитория ondrej/php, пакеты обновятся оттуда же. На Debian 12 и 13 то же самое, только пакеты называются php8.2… и php8.4…, а на Ubuntu 22.04 — php8.1….

Проверка, что обновлять больше нечего: после apt-get update команда считает пакеты PHP в списке обновляемых. Ноль означает, что для PHP новых версий нет. На нашем стенде пакет уже был исправленным.

Теперь самое важное. Файлы на диске обновились, но запущенный процесс PHP-FPM продолжает работать со старым кодом в памяти, пока вы его не перезапустите. Для FPM команда такая (для другой версии замените номер):

sudo systemctl restart php8.3-fpm

Имя службы зависит от системы: php8.1-fpm (Ubuntu 22.04), php8.2-fpm (Debian 12), php8.3-fpm (Ubuntu 24.04), php8.4-fpm (Debian 13). Если PHP встроен в Apache, перезапускать нужно Apache: sudo systemctl restart apache2; его пакеты называются libapache2-mod-php8.X. Перезапуск может ненадолго прервать обработку запросов, поэтому выберите спокойный момент, но не откладывайте его.

Как убедиться, что процесс новый. Смотрим состояние службы, время запуска процессов и то, на какой файл ссылается запущенный процесс (PID в команде ls замените номером главного процесса из столбца PID).

• active — служба работает. В столбце STARTED время запуска процессов: оно должно быть позже обновления пакета.
• /proc/PID/exe — ссылка на программу, которую запустил процесс. Если файл заменили, пока процесс работал, после пути появится пометка (deleted): значит, процесс всё ещё старый и его нужно перезапустить. В нашем выводе пометки нет.
• Время изменения файла /usr/sbin/php-fpm8.3 здесь совпадает с датой сборки из php -v (19 октября). Это дата сборки пакета, а не момент вашей установки. Поэтому сравнение «процесс моложе файла» само по себе слабый признак: надёжнее пометка (deleted) и привычка перезапускать службу после каждого обновления PHP.

Что делать, если обновить прямо сейчас нельзя

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

Отдельно про session.upload_progress.enabled. 23 октября 2026 года php.net опубликовал информационное уведомление (CVE-2026-115560; полное уведомление обещано вместе со следующим плановым выпуском). В нём предлагают задать session.upload_progress.enabled=0 до следующего планового выпуска, чтобы полностью защититься от маловероятного сценария удалённого выполнения кода. Это рекомендация и для серверов, которые уже обновлены. Сценарий относится к приложениям, которые переключают session.serialize_handler на php через ini_set() до session_start() при включённом отслеживании загрузки. Авторы GHSA-6wmf-4rv5-p3rp тоже советуют держать параметр выключенным после обновления, если функция вам не нужна. Источник: https://www.php.net/archive/2026.php.

Покажем первую меру на стенде. Параметр session.upload_progress.enabled отвечает за отслеживание прогресса загрузки файла в сессии. Мы смотрим его значение в FPM, создаём файл конфигурации с одной строкой (его содержимое видно в карточке), перезапускаем службу и проверяем снова. Заодно php-fpm8.3 -t проверяет, что конфигурация не сломана, чтобы не уложить сайт опечаткой. Команда php-fpm8.3 -i показывает настройки именно FPM, а не командной строки.

Было On, стало Off. Если какой-то из ваших сайтов использует показ прогресса загрузки через сессии, после этого он перестанет работать: это цена меры. Путь к файлу выше относится к FPM; для Apache конфигурация лежит в другом каталоге, найдите свой в выводе php -i.

PHP 8.1 и старше, самосборка: что делать

У каждой ветки PHP есть срок, до которого проект выпускает исправления безопасности. Дальше ветка считается снятой с поддержки (EOL): новые уязвимости в ней не закрывают.

Если у вас PHP 8.1 или старше, для вашей ветки нет выпусков с исправлением. Зато команда безопасности PHP опубликовала минимальные бэкпорты исходного кода для 7.4, 8.0 и 8.1 в git-ветках PHP-7.4-CVE-2026-109618-109619, PHP-8.0-CVE-2026-109618-109619 и PHP-8.1-CVE-2026-109618-109619 репозитория php/php-src. Они рассчитаны на тех, кто собирает PHP из исходников. На Ubuntu 22.04 пакет php8.1 версии 8.1.2-1ubuntu2.28 содержит исправление, выпущенное самим дистрибутивом (см. таблицу выше), поэтому установите обновление через apt. Но надолго рассчитывать на ветку, которую проект уже не поддерживает, не стоит: планируйте переход на 8.3 или новее и заранее проверьте на копии сайта, что плагины и код его переживают. Сроки поддержки самих дистрибутивов в этой статье мы не проверяли.

Если PHP собран из исходников, apt о нём ничего не знает и сам не обновит. Есть три пути: пересобрать из исправленного выпуска (8.2.35, 8.3.36, 8.4.27, 8.5.12 или новее), пересобрать из одной из веток-бэкпортов либо перейти на пакеты дистрибутива. Последнее обычно проще поддерживать. Учтите разницу: у сборки из выпуска номер в php -v показывает исправленную версию, а у сборки из ветки-бэкпорта номер остаётся прежним, и по нему исправление не доказать.

Как проверить, что на сервере ничего не изменилось

Эти проверки не доказывают, что сервер чист, и ничего не гарантируют: отсутствие подозрительных файлов не означает, что их не было. Смысл скромнее — быстро заметить явные странности. Для сайта на PHP первым делом смотрят на файлы с недавними изменениями.

Первая команда ищет PHP-файлы в /var/www, изменённые за последние семь дней, вторая — файлы новее самого бинарника PHP-FPM. Пример ниже мы снимали на стенде, где единственный найденный файл — наш тестовый index.php, который мы создали сами для проверки.

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

Вторая зона для беглого взгляда — задания по расписанию. Так выглядел каталог /etc/cron.d и список пользовательских заданий на стенде. Имена в списке знакомые (certbot, php, sysstat), пользовательских заданий нет.

Для общей картины можно посмотреть процессы, которые больше всего грузят процессор (ps -eo user,pid,etime,cmd --sort=-pcpu | head -5), и число установленных соединений (ss -tnp state established | wc -l). Свой вывод мы здесь не показываем: он зависит от вашего сервера, и понять его можно, только зная, что на машине обычно работает.

Если нашли файл или задание, которого не создавали, не удаляйте их сразу. Сохраните копию и вывод команд, а затем откройте тикет в поддержку. Для постоянной защиты полезно пройти чек-лист первых 10 минут: ключи SSH, firewall, обновления.

Вопросы и ответы

Как понять, исправлен ли PHP, если php -v показывает 8.3.6?

Смотрите версию пакета, а не вывод php -v. На Ubuntu 24.04 исправленный пакет называется 8.3.6-0ubuntu0.24.04.13, а php -v при этом пишет 8.3.6. На Debian 12 и 13 исправленный пакет сам показывает новый номер (8.2.35 и 8.4.27), но сравнение версии пакета через dpkg --compare-versions надёжно на всех системах; можно также найти строки с CVE-2026-109618 в файле changelog пакета.

Нужно ли перезапускать PHP после обновления?

Да. Файлы на диске заменяются, но запущенные процессы продолжают работать со старым кодом, пока их не перезапустят. Для PHP-FPM это sudo systemctl restart php8.3-fpm (номер подставьте свой), для PHP внутри Apache — перезапуск Apache. Целиком сервер ради PHP перезагружать не нужно.

Что делать, если обновить PHP сейчас нельзя?

Задайте memory_limit=-1 через php_admin_value в пуле FPM или конфигурации Apache, отключите session.upload_progress.enabled, ограничьте размер запросов на веб-сервере и, если PHP работает в контейнере, поставьте лимит памяти контейнера как границу доступности, но не как защиту. Лимит памяти PHP не понижайте. Это частичные меры, они не делают установку безопасной, поэтому назначьте себе дату обновления. Не используйте RLIMIT_AS и RLIMIT_DATA.

Мой сервер на PHP 8.1. Он тоже в зоне риска?

Выпусков PHP 8.1 с исправлением нет: ветка снята с поддержки с 31 декабря 2025 года, но для самосборки есть ветка-бэкпорт PHP-8.1-CVE-2026-109618-109619. На Ubuntu 22.04 исправление есть в пакете php8.1 версии 8.1.2-1ubuntu2.28, его нужно установить. Планируйте переход на поддерживаемую ветку.

Значит ли это, что мой сервер уже взломан?

Нет. Уязвимость — это возможность, а не факт, и из номера CVE нельзя сделать вывод о том, что она использовалась против вашего сервера. Обновите PHP, перезапустите службу и выборочно проверьте файлы и задания, как описано выше.

Итоги

• CVE-2026-109618 и CVE-2026-109619 закрыты в PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35; под уязвимость подпадают более ранние версии этих веток.
• Сравнивайте версию пакета через dpkg: на Ubuntu 24.04 php -v показывает 8.3.6 даже после исправления, на Ubuntu 22.04 пишет полную версию пакета, а на Debian 12 и 13 исправленный пакет сам даёт 8.2.35 и 8.4.27.
• Обновите пакеты через apt и перезапустите PHP-FPM или Apache; без перезапуска процесс остаётся старым.
• Если обновить нельзя, примените частичные меры, но помните: они не делают установку безопасной.
• Для PHP 8.1 и старше выпусков с исправлением нет (есть ветки-бэкпорты для самосборки): планируйте переход на 8.3 или новее.
• Параметр session.upload_progress.enabled=0 php.net советует держать и на обновлённых серверах до следующего планового выпуска (уведомление о CVE-2026-115560 от 23 октября 2026 года), если функция вам не нужна.
• Проверка файлов и заданий по расписанию помогает заметить явные странности, но не гарантирует чистоту.

🎁 -40% на первый месяц нового VPS. Промокод GUIDE40
Нужен сервер под ваши задачи? Первый месяц со скидкой.
Введите GUIDE40 при оформлении заказа. Работает один раз на клиента.
Выбрать VPS и забрать скидку →