PHP2Shell: як дізнатися, яка версія PHP працює на вашому сайті

Що таке PHP2Shell

PHP2Shell - неофіційна назва, яку дослідники й вендори безпеки дали двом вразливостям у самому PHP, а не в CMS чи плагіні. Сам проєкт PHP цієї назви не вживає: в офіційному бюлетені вразливості названо «RCE via OOM corruption» і «RCE via stale global state», тобто віддалене виконання коду через пошкодження даних під час нестачі памʼяті і через застарілий глобальний стан.

За даними php.net, у CVE-2026-109618 обробка нестачі памʼяті може перервати PHP, коли внутрішні дані запиту ініціалізовано лише частково, і тоді очищення запиту сприйме некоректні дані як коректні. У CVE-2026-109619 внутрішній стан запиту може пережити звільнення памʼяті, і наступний запит у тому самому воркері здатен ним скористатися. Обидві вразливості можуть дати змогу виконати код на сервері без автентифікації. Проєкт PHP оцінив кожну на 9,2 (критично) за CVSS v4.0.

26 жовтня 2026 року CISA внесла обидві CVE до каталогу Known Exploited Vulnerabilities. Це означає, що в CISA є докази реальних атак. Оновлення справді термінове, але панікувати не варто: перші кроки нижче займають кілька хвилин.

Які версії вразливі, а які виправлені

Виправлені релізи вийшли 21 жовтня 2026 року. php.net вважає вразливими всі попередні релізи підтримуваних гілок. Стан гілок наведено за php.net: підтримувані версії.

Дистрибутиви Linux і LTS-вендори отримали патчі заздалегідь і випускають їх у власних пакетах. Для тих, хто збирає PHP із вихідного коду, php.net також опублікував мінімальні бекпорти для 7.4, 8.0 і 8.1.

Кого це стосується

За php.net, під ризиком усі інсталяції PHP, які обслуговують вебзапити: PHP-FPM, Apache з mod_php, php-cgi, FrankenPHP і LiteSpeed. Найвищим команда PHP вважає ризик для mod_php: там продемонстровано експлойт, який спрацьовує ще до запуску коду застосунку. На практиці це майже кожен сайт на PHP - WordPress, Joomla, Drupal, Laravel, інтернет-магазини і сайти, написані з нуля. Оновлення CMS тут не допоможе, бо вразливість у самому PHP.

Як перевірити версію PHP

Якщо можете, скористайтеся кількома способами: версія, яку видно в одному місці, не завжди та, що обслуговує сторінки сайту.

• Панель хостингу. У cPanel, Plesk чи подібній панелі відкрийте налаштування PHP для домену. Там видно версію, яку вебсервер використовує саме для цього сайту, а важить саме вона.
• Тимчасова сторінка phpinfo. Створіть файл із випадковою назвою і вмістом <?php phpinfo();, відкрийте його в браузері, запишіть рядки «PHP Version» і «Server API» та одразу видаліть файл. Забута сторінка phpinfo показує всім повну конфігурацію сервера.
• Заголовки відповіді. Виконайте curl -I https://your-site.example або відкрийте вкладку Network в інструментах розробника браузера і знайдіть рядок на кшталт X-Powered-By: PHP/8.3.30. Багато серверів цей заголовок приховують, тож його відсутність нічого не означає.
• Командний рядок. php -v на сервері показує версію консольного PHP. Вона може відрізнятися від тієї, яку PHP-FPM чи mod_php використовує для сайту, тому перевірте і вебверсію.
• Пакетний менеджер. Якщо PHP встановлено з пакетів дистрибутива, перевірте версію пакета, наприклад rpm -q php-common в AlmaLinux або dpkg -l | grep php у Debian та Ubuntu, і звірте її з бюлетенем безпеки вашого вендора.

Прихована версія - ще не гарантія безпеки

Якщо сайт не надсилає X-Powered-By, зовнішня перевірка не побачить версію. Приховати її - розумне налаштування (expose_php = Off у php.ini), але воно ховає лише номер. Якщо PHP не оновили, вразливий код і далі працює. Навіть документація PHP називає безпеку через приховування «однією з найслабших форм безпеки».

Те саме з фаєрволом чи CDN перед сайтом: вони можуть заблокувати частину шкідливих запитів, але php.net прямо пише, що повне рішення - лише оновлення.

Збіг версії - ще не доказ злому

Протилежна помилка трапляється так само часто. Якщо сканер бачить PHP/8.3.30, це означає лише, що показана версія старша за виправлення від розробників PHP. Це не доводить, що сайт атакували, і навіть не обовʼязково означає, що він вразливий:

• Дистрибутиви часто переносять виправлення у старі пакети, не змінюючи номер версії. AlmaLinux, наприклад, прямо радить не покладатися на php -v, а перевіряти версію пакета.
• Заголовок може надсилати інший сервер, ніж той, на якому працює сайт, наприклад старий проксі.
• Заголовок може бути застарілим або прописаним вручну.

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

Що зробити зараз

• Дізнайтеся точну версію PHP і пакет, які обслуговують сайт, одним зі способів вище.
• На гілках 8.2-8.5 оновіться до 8.2.35, 8.3.36, 8.4.27, 8.5.12 або новішої версії чи до виправленого пакета вашого дистрибутива. На віртуальному хостингу спитайте підтримку, чи встановлено виправлення CVE-2026-109618 і CVE-2026-109619, і збережіть відповідь.
• Після оновлення перезапустіть усі процеси PHP (PHP-FPM, Apache), щоб жоден із них не працював на старому коді.
• На 8.1 і старших заплануйте перехід на підтримувану гілку, а до того часу спитайте вендора, чи є бекпорт виправлення.
• Якщо оновитися сьогодні неможливо, php.net наводить тимчасові заходи, наприклад session.upload_progress.enabled=0 для CVE-2026-109619. За словами самої команди PHP, вони зменшують ризик окремих сценаріїв атаки, але не роблять інсталяцію безпечною.
• Після оновлення приховайте версію через expose_php = Off. Це прибирання, а не захист.

Що покаже перевірка ZNIMOK

Перевірка застарілого ПЗ читає лише те, що сайт і так віддає будь-якому відвідувачу. Якщо заголовок відповіді показує точну версію PHP, звіт порівнює її з останнім безпековим релізом тієї самої гілки та з даними про завершення підтримки і позначає розрив як те, що варто перевірити, а не як підтверджену вразливість. Якщо видно лише гілку, звіт так і каже: рівень патча невідомий. Жодних експлойт-запитів перевірка не надсилає.

Так можна швидко побачити, що стороння людина дізнається про ваш PHP. Остаточну відповідь дають панель хостингу або сам сервер.