У попередній матеріал про CVE-2026-109618 і CVE-2026-109619 я розібрала, чому дві критичні вразливості PHP від 21 жовтня 2026 року потребують швидкої реакції.
Тепер практична частина: як оновити PHP так, щоб не обмежитися одним apt upgrade, а перевірити весь шлях від поточної версії до працездатного застосунку після оновлення.
Нижче я використовую приклад PHP 8.5 на Ubuntu з Nginx і PHP-FPM. Для інших гілок PHP назви пакетів потрібно замінити на відповідні.
1. Спочатку перевірити, які версії PHP реально встановлені
php -vphp8.5 -vphp-fpm8.5 -vЯ не покладаюся лише на php -v. Команда php може вказувати на одну версію, а PHP-FPM, який реально обслуговує сайт, - на іншу.
Тому окремо перевіряю CLI і FPM. Якщо на сервері встановлено кілька гілок PHP, перевіряю кожну з них.
dpkg-query -W 'php8.5*'Це допомагає побачити не лише php8.5-cli і php8.5-fpm, а й розширення, які потрібно залишити узгодженими після оновлення.
Для пакетів дистрибутива номер версії потрібно оцінювати разом із повідомленням постачальника про безпеку, тому що виправлення може бути перенесене в його власну збірку.
2. Перед оновленням підготувати резервні копії та шлях відкату
Оновлення PHP змінює середовище виконання всього застосунку. Навіть якщо саме оновлення пакетів стандартне, я не хочу починати його без актуальної резервної копії даних і конфігурації.
Для MySQL приклад може виглядати так:
set -o pipefailumask 077 sudo mysqldump \ --single-transaction \ --quick \ --routines \ --events \ --triggers \ --no-tablespaces \ --databases app_db \ | gzip > app_db.sql.gz gzip -t app_db.sql.gzapp_db потрібно замінити на назву своєї бази. Облікові дані краще брати з уже налаштованого безпечного способу доступу, а не передавати пароль відкритим текстом у командному рядку.
gzip -t перевіряє цілісність архіву, але не доводить, що база реально відновлюється. Це окрема перевірка, яку я детальніше розбираю в окремий матеріал про те, чому самого файла резервної копії недостатньо.
sudo tar -czf /root/php-config-backup.tar.gz \ -C / \ etc/php/8.5 \ etc/nginx \ etc/supervisorЗа можливості я також готую знімок сервера або інший перевірений спосіб відкату. Важливо знати не лише, як оновити, а й що робити, якщо після цього застосунок не запускається.
3. Перевірити, які оновлення реально доступні
sudo apt-get update apt-cache policy \ php8.5-cli \ php8.5-fpmapt-cache policy показує встановлену та доступну версії пакетів. Якщо використовується сторонній репозиторій або пакет від дистрибутива з перенесеним виправленням, саме тут потрібно звірити джерело пакета та його стан безпеки.
mapfile -t packages < <( dpkg-query -W \ -f='${binary:Package} ${db:Status-Abbrev}\n' \ 'php8.5*' 2>/dev/null | awk '$2 == "ii" {print $1}') printf '%s\n' "${packages[@]}"Я формую список уже встановлених пакетів, щоб не додати випадково нові розширення й не оновлювати всю операційну систему разом із PHP.
4. Спочатку подивитися план змін без установлення
sudo apt-get -s install \ --only-upgrade "${packages[@]}"Параметр -s не встановлює пакети. Він показує, що саме планує зробити пакетний менеджер.
Перед реальним оновленням я перевіряю, що не зникають потрібні модулі PHP, не видаляються сторонні пакети й не з’являються неочікувані зміни залежностей.
5. Оновити встановлені пакети PHP
sudo apt-get install \ --only-upgrade "${packages[@]}"Цей крок оновлює вже встановлені компоненти PHP 8.5. Він не є повним оновленням усіх пакетів Ubuntu.
Під час оновлення пакет PHP-FPM може перезапустити службу автоматично. На production сервері це потрібно врахувати як можливе коротке переривання обслуговування динамічних запитів.
6. Після оновлення перевірити версії та конфігурацію
php8.5 -vphp-fpm8.5 -v sudo php-fpm8.5 -tsudo nginx -tТут я хочу отримати дві відповіді: чи справді встановилася очікувана версія PHP і чи залишилася конфігурація PHP-FPM та Nginx коректною.
Сам факт успішного завершення apt-get ще не означає, що сервер готовий повертати трафік без перевірки.
7. Перевірити стан служб і фонових процесів
systemctl is-active php8.5-fpmsystemctl is-active nginxsystemctl is-active mysqlsystemctl is-active supervisorsudo supervisorctl statusОсобливо важливі довгоживучі процеси: обробники черг, WebSocket-сервери, SSR-процеси або інші служби, які були запущені до оновлення.
Якщо вони вже були коректно перезапущені пакетами або керуванням службами й працюють на новій версії PHP, додатковий безумовний перезапуск не потрібен. Але їхню фактичну версію та стан потрібно перевірити.
8. Перевірити не лише HTTP 200, а й основні функції застосунку
curl -I https://example.com/200 OK - хороший перший сигнал, але недостатній для завершення оновлення.
Після зміни PHP я перевіряю щонайменше:
- підключення до бази даних;
- вхід і авторизацію користувачів;
- роботу черг;
- фонові процеси;
- завантаження файлів, якщо воно є;
- ключові сторінки й API;
- журнали PHP-FPM, Nginx і застосунку після оновлення.
Якщо один сервер обслуговує кілька сайтів, кожен із них потрібно перевірити окремо.
9. Оновлення PHP на Ubuntu не оновлює PHP у Docker
docker ps docker exec <container_name> php -vЦе одна з найпростіших помилок під час термінового виправлення: оновити PHP на вузлі й вважати, що всі середовища вже безпечні.
Контейнер має власну файлову систему та власний образ. Якщо всередині нього залишається вразлива версія PHP, потрібно оновити базовий образ, перебудувати контейнер і знову виконати перевірки.
10. Перевірити всі інші місця, де виконується PHP
Для одного проєкту PHP може існувати в кількох незалежних місцях:
Production сервер;
Dev сервер;
локальне середовище;
Docker-контейнери;
образи CI;
окремі машини для черг або служб.
Оновлення в одному місці не є доказом, що всі інші середовища теж виправлені.
Що я не роблю під час такого термінового оновлення
- Не обмежуюся
composer update. Це не виправляє вразливість PHP. - Не оновлюю всю операційну систему без потреби. Для термінового виправлення краще чітко бачити межу змін.
- Не пропускаю пробний план пакетного менеджера. Неочікуване видалення модуля краще побачити до встановлення.
- Не вважаю резервну копію перевіреною лише через наявність файла.
- Не завершую роботу на
php -v. Потрібно перевірити FPM, служби, застосунок і контейнери. - Не забуваю про довгоживучі процеси. Вони можуть продовжувати працювати зі старим процесом PHP, доки не будуть коректно перезапущені.
Короткий контрольний список
[ ] Версію CLI перевірено[ ] Версію PHP-FPM перевірено[ ] Установлені пакети PHP перелічено[ ] Стан пакетів постачальника перевірено[ ] Резервну копію бази створено[ ] Копію конфігурації створено[ ] Шлях відкату підготовлено[ ] План оновлення пакетів перевірено[ ] Пакети PHP оновлено[ ] Конфігурацію PHP-FPM перевірено[ ] Конфігурацію Nginx перевірено[ ] Стан служб перевірено[ ] Основні функції застосунку перевірено[ ] Журнали після оновлення перевірено[ ] Версії PHP у Docker перевірено[ ] Інші середовища PHP перевіреноБезпечне оновлення PHP - це не одна команда
Критична вразливість у самому PHP змушує оновлювати не залежності застосунку, а середовище, у якому цей застосунок виконується.
Але встановити новий пакет недостатньо. Потрібно знати, що саме було встановлено до оновлення, мати резервні копії, перевірити план змін, підтвердити нові версії та пройти основні функції застосунку після встановлення.
І найважливіше - перевірити всі місця, де реально працює PHP. Production сервер, dev сервер, Docker і локальне середовище не оновлюються один раз на всіх.
Оновлення завершене не тоді, коли пакет установився, а тоді, коли підтверджено нову версію PHP і працездатність усього застосунку.
