Як оновити PHP на практиці: перевірка, перемикання, контроль роботи та приховування версії

У 2026 році опубліковано критичну вразливість PHP з оцінкою CVSS 9.8. Серед японських сайтів, сервери яких розкривають версію PHP, 59.5% досі показують версію, не оновлену до випуску з виправленням (Юкі Накадзава, Security Exposure Survey 2026; дані зібрано за допомогою Site Scouter). У цій статті покроково розібрано практичні дії: як з'ясувати, яка версія PHP працює на вашому сервері, як перемкнути версію на віртуальному хостингу, як перевірити сайт після цього і, нарешті, як перестати повідомляти рядок версії зовнішньому світу.

Ця стаття також опублікована англійською на sitescouter.net і nkzw.jp та японською на sitescouter.net. Це українська версія на Site Scouter, перекладена з англійської.

Спочатку з'ясуйте поточну версію PHP

Перший крок — знати, що насправді працює на сервері. Способів перевірки кілька; достатньо будь-якого одного з них.

Через панель керування хостингом

У більшості провайдерів віртуального хостингу в панелі керування є меню на кшталт «PHP settings» (налаштування PHP) або «PHP version» (версія PHP). Увійдіть, відкрийте налаштування свого домену чи сайту — там буде показано застосовану зараз версію PHP. Назви меню та їхнє розташування в різних провайдерів відрізняються, тож звіряйтеся з актуальним посібником свого провайдера.

Через «Site Health» у WordPress

Якщо у вас WordPress, відкрийте в адмінпанелі Tools → Site Health → Info. У розділі «Server» показано поточну версію PHP. Плагін не потрібен, тому для власників сайтів на WordPress це найпростіший шлях.

За допомогою phpinfo() (не залишайте його в мережі)

Завантажте на сервер PHP-файл, що містить лише <?php phpinfo(); ?>, і відкрийте його в браузері — ви побачите докладні відомості про середовище, зокрема версію PHP.

Видаліть файл одразу після перевірки. Вивід phpinfo() містить номери версій, значення налаштувань і перелік встановлених модулів — саме те, чим може скористатися зловмисник. Залишити його в мережі означає віддати карту свого сервера. Ставтеся до нього як до тимчасового файлу для одноразової перевірки й негайно прибирайте.

Через /server/ на sitescouter.net — щоб побачити версію, «видиму ззовні»

Наведені вище способи показують те, що сервер бачить зсередини. Щоб побачити, що ваш сервер насправді повідомляє відвідувачам, скористайтеся перевіркою інформації про сервер Site Scouter (/server/). Введіть URL, і інструмент покаже, чи з'являється версія PHP у заголовках Server або X-Powered-By, — тобто погляд третьої сторони на те, чи видно «PHP 8.1.x» ззовні.

Графік підтримки PHP і критична вразливість 2026 року

Графік підтримки

Нижче коротко наведено статус підтримки, опублікований php.net (перевірено 27 жовтня 2026). Дати можуть продовжуватися або змінюватися, тому перед будь-якими діями ще раз звірте їх на php.net/supported-versions.php.

Виправлення безпеки для 8.2 також припиняються наприкінці 2026 року. Якщо зараз у вас 8.2, протягом наступного року вам потрібно перейти на 8.3 або новішу. 8.1 і старіші вже взагалі не отримують патчів і потребують уваги негайно.

Тим часом 52.3% японських сайтів, що розкривають версію PHP, показують версію з завершеним життєвим циклом (Юкі Накадзава, Security Exposure Survey 2026; дані зібрано за допомогою Site Scouter). Коли у версії EOL знаходять вразливість, виправлення для неї не випускають.

Критична вразливість 2026 року та версії з виправленням

У 2026 році для PHP опубліковано вразливості з оцінкою CVSS 9.8 (Critical).

У разі експлуатації ці вразливості можуть підмішувати в запит дані сесій інших користувачів, що веде до підвищення привілеїв або витоку інформації, а в найгіршому разі — до появи вебшелу на сервері. Якщо ваша версія нижча за 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12, оновіться без зволікань.

Порядок оновлення

Крок 1: Зробіть резервні копії перед перемиканням

Зміна версії може змінити поведінку PHP і покласти сайт. Завжди спочатку робіть такі резервні копії.

• Резервна копія бази даних: дамп MySQL / MariaDB (функція «Export» у phpMyAdmin або засіб резервного копіювання у вашій панелі керування)
• Резервна копія файлів: для WordPress — усе в wp-content/ (теми, плагіни, завантаження), а також wp-config.php

Крок 2: Перевірте сумісність WordPress, теми та плагінів

Під час переходу між мажорними версіями (7.x → 8.x) заздалегідь переконайтеся, що ядро WordPress, ваша тема й усі встановлені плагіни підтримують цільову версію PHP.

• Спочатку оновіть ядро WordPress через Dashboard → Updates
• Для кожного плагіна перевірте поле «Tested up to» на його сторінці WordPress.org або в інформації про підтримку від розробника
• Розгляньте заміну старих плагінів, які більше не супроводжуються

Крок 3: Перевірте на тестовому середовищі (рекомендовано)

Перш ніж перемикати робочий сайт, випробуйте нову версію PHP на тестовій копії (staging). Більшість великих хостингів надають функцію staging або піддомен, яким можна для цього скористатися.

Якщо тестового середовища немає, практична альтернатива — перемикати у період низького трафіку (пізно вночі) й одразу ж переглянути ключові сторінки власними очима.

Крок 4: Перемкніть версію PHP у панелі керування

Великі японські віртуальні хостинги (Sakura, Xserver, Lolipop, ConoHa WING, mixhost та інші — японські хостинг-сервіси, наведені як приклади) мають у панелі керування меню для перемикання версій PHP. Типовий порядок такий:

1. Увійдіть у панель керування хостингом
2. Відкрийте налаштування домену чи сайту й знайдіть меню на кшталт «PHP settings», «PHP version» або «Language version»
3. Виберіть 8.3 або 8.4 (найновішу стабільну версію, яку пропонує ваш хостинг) і збережіть / застосуйте
4. Набуття змінами чинності може тривати кілька хвилин

Назви меню та кроки в різних провайдерів відрізняються. Завжди дотримуйтеся офіційного посібника свого провайдера — там також наведено доступні версії.

Крок 5: Перевірте сайт і журнал помилок

Після перемикання переконайтеся в такому.

• Головна та ключові сторінки коректно відображаються в браузері
• Ви можете увійти в адмінпанель WordPress
• Перевірте журнал помилок PHP через функцію журналів у панелі керування або за шляхом, заданим у error_log. Якщо бачите PHP Fatal error або PHP Deprecated, відповідний плагін чи тема потребують уваги
• Якщо щось зламалося, негайно поверніться до попередньої версії (більшість панелей дозволяють миттєвий відкат), знайдіть причину й спробуйте знову

Приховайте рядок версії (після оновлення)

PHP і вебсервери можна налаштувати так, щоб вони не повідомляли номери своїх версій. Це і є «приховування версії», але приховування версії не усуває вразливість. Спершу завершіть оновлення, а цей крок застосовуйте як додатковий захід.

Якщо переплутати порядок, отримаєте «стару версію з прихованим номером»: її важче помітити, а реальний ризик той самий.

Приберіть заголовок із версією PHP (expose_php)

Додайте до php.ini або .htaccess таке:

; add to php.ini
expose_php = Off

Якщо хостинг не дозволяє редагувати php.ini безпосередньо, пропишіть те саме налаштування в .user.ini (його підтримує більшість віртуальних хостингів). Після перезавантаження (або коли зміна набуде чинності) переконайтеся через Site Scouter /server/, що версія PHP зникла із заголовка X-Powered-By.

Мінімізуйте заголовок Server в Apache

Якщо Apache під вашим керуванням (VPS або виділений сервер), задайте в httpd.conf чи apache2.conf таке:

ServerTokens Prod
ServerSignature Off

ServerTokens Prod повертає лише Server: Apache, без версії. ServerSignature Off прибирає рядок про сервер зі сторінок помилок.

Мінімізуйте заголовок Server в nginx

Для nginx додайте це в блок http файлу nginx.conf:

server_tokens off;

Після цього nginx повертає лише Server: nginx, без версії.

Остаточна перевірка після змін

Коли оновлення й налаштування приховування версії завершено, перевірте свій сайт через перевірку інформації про сервер Site Scouter (/server/). Якщо заголовки X-Powered-By і Server більше не показують номерів версій, версія ззовні не видна.

Контрольний список

• [ ] Перевірено поточну версію PHP через панель керування, Site Health або /server/
• [ ] Усвідомлено, що 8.1 і старіші — EOL (якщо це ваш випадок)
• [ ] Узято до уваги кінцевий термін 2026-12-31 (якщо у вас 8.2)
• [ ] Зроблено резервні копії (база даних + файли)
• [ ] Перевірено сумісність WordPress, теми та плагінів
• [ ] PHP перемкнено на 8.3 або новішу (бажано 8.4 чи 8.5; найновішу стабільну версію, яку пропонує ваш хостинг)
• [ ] Підтверджено, що версія не нижча за випуски з виправленнями для CVE-2026-109618 / CVE-2026-109619 (8.2.35 / 8.3.36 / 8.4.27 / 8.5.12)
• [ ] Підтверджено, що після перемикання сайт працює, а в журналі помилок чисто
• [ ] Задано expose_php = Off / ServerTokens Prod / server_tokens off (після оновлення)
• [ ] Через /server/ підтверджено, що ззовні не видно жодної інформації про версії

Пов'язані статті

• Опубліковано вразливість PHP з оцінкою CVSS 9.8. Чи оновився світ? Що 260,000 сайтів розповідають про занедбані сервери — стан безпеки японських сайтів за результатами дослідження (блог Юкі Накадзави)
• Security Exposure Survey 2026 Дані дослідження та міжнародне порівняння для 260,000 сайтів у Японії, країнах G7 та Азії (sitescouter.net)
• Перевірка інформації про сервер: sitescouter.net/en/server/ Введіть URL, щоб побачити заголовки сервера, версію PHP і налаштування безпеки, видимі ззовні.

Дати підтримки наведено за php.net/supported-versions.php. Перед публікацією ще раз звірте найновіші дати.

Джерела

Остання перевірка: 2026-10-28. Специфікації та правила можуть змінюватися; перш ніж діяти, звіртеся з першоджерелами.

• PHP: Supported Versions (php.net)
• PHP: Runtime Configuration — expose_php (php.net)
• Apache HTTP Server: ServerTokens Directive
• nginx: server_tokens
• WordPress: Site Health