Хостинг написав: «PHP оновлено». Це може бути правдою для одного сайту з п'яти на вашому акаунті, правдою лише для командного рядка або правдою на папері, поки робочі процеси досі тримають у пам'яті стару версію. Після PHP2Shell такої відповіді мало. Нижче чотири перевірки, які власник сайту може зробити сам за п'ятнадцять хвилин, і список питань до хостингу.
Чому «оновлено» ще не означає «захищено»
- Оновили не той сайт. На акаунті бувають кілька доменів, піддоменів і тестових копій, і в багатьох панелях версію PHP вибирають для кожного окремо.
- Оновили лише консольний PHP. Команда
php -v показує версію для терміналу й cron. Сайт у браузері обслуговує інший PHP: PHP-FPM, Apache чи LiteSpeed, і це можуть бути різні версії.
- Процеси не перезапущено. Пакет оновлено на диску, але працівники PHP-FPM чи Apache, що запущені раніше, виконують старий код, поки їх не перезапустять.
- Версія в рядку обманює в обидва боки. Дистрибутиви Linux (Debian, Ubuntu) часто переносять виправлення в пакет зі старішим номером версії: за номером сайт виглядає вразливим, а за змістом уже закритий. Буває й навпаки.
Перевірка 1. Яку версію бачить саме сайт
Без терміналу:
- WordPress: Інструменти → Стан сайту → вкладка «Інформація» → розділ «Сервер», рядок «Версія PHP».
- Тимчасовий файл
phpinfo: файл із одним рядком <?php phpinfo(); у корені сайту, відкрити в браузері й одразу видалити: сторінка видає надто багато про сервер, щоб лишати її публічною.
- Заголовок відповіді: команда
curl -sI https://ваш-сайт.ua | grep -i x-powered-by покаже PHP/8.x.y, якщо адміністратор не вимкнув цей заголовок. Часто вимкнено, тоді порожній результат нічого не доводить.
Перевірка 2. Порівняйте з виправленими версіями
Виправлення вийшли для гілок 8.5 (8.5.12), 8.4 (8.4.27), 8.3 (8.3.36) і 8.2 (8.2.35). Для 8.1 і старших офіційного виправлення немає. Номер вашої версії такий самий або новіший за відповідний у списку? Добре. Нижчий? Не поспішайте з висновком: якщо сервер на Debian чи Ubuntu, спитайте хостинг, чи пакет містить виправлення CVE-2026-109618 і CVE-2026-109619. Журнал змін пакета це показує, і хостингу відповісти на таке питання нескладно.
Перевірка 3. Чи перезапущено процеси
Оновлення без перезапуску працює лише на диску. Спитайте хостинг прямо: «після оновлення ви перезапустили PHP-FPM (або Apache) і коли саме?». Якщо у вас є SSH, час запуску процесів видно командою ps -eo pid,lstart,cmd | grep -E "php-fpm|apache2|httpd": дата старту має бути пізнішою за час оновлення.
Перевірка 4. Усі місця, де живе PHP
- Усі домени й піддомени на акаунті, включно з тестовими копіями й забутими старими сайтами: один необновлений сайт на акаунті лишається точкою входу, навіть якщо головний уже закритий.
- Окремі пули PHP-FPM для різних сайтів.
- Завдання cron і консольні скрипти: вони запускаються тим PHP, що у терміналі, а не веб-версією.
Що спитати в хостингу
- Яка точна версія PHP зараз у моєму сайті (не «8.3», а повністю, з третім числом або номером пакета)?
- Чи входять у цей пакет виправлення CVE-2026-109618 і CVE-2026-109619?
- Коли після оновлення перезапущено PHP-FPM або веб-сервер?
- Чи застосовано те саме до всіх моїх доменів і піддоменів?
- Якщо мій PHP 8.1 чи старший: чи є у вас пакет із виправленням, чи треба переходити на нову гілку?
Якщо хостинг не може або не хоче
Бувають хостинги, що пропонують лише застарілі гілки PHP. Тоді залишаються два шляхи: перейти на гілку з виправленням (8.2–8.5), попередньо перевіривши на копії сайту, чи працюють плагіни й модулі, або перенести сайт на сервер, де ви самі керуєте версією. Ми робимо і те, і те: оновлення PHP і захист сервера проходить на копії сайту, з перевіркою сумісності й звітом про стан.
Жодна перевірка не дає стовідсоткової гарантії. Вона закриває типові помилки, але не замінює резервних копій і моніторингу.