Розробники PHP оголосили позапланове оновлення безпеки, яке має закрити одразу дві критичні вразливості. Реліз призначили на 21 жовтня 2026 року, 17:00 за київським часом. Обидві проблеми отримали оцінку 9,2 бала з 10 за шкалою CVSS 4.0, і за словами дослідників, вони дозволяють зловмиснику віддалено виконати власний код на сервері.
Найнеприємніше в цій історії те, що виправлення отримають лише гілки 8.2, 8.3, 8.4 та 8.5. Для PHP 8.1, 8.0, усіх версій 7.x і 5.x офіційного патча не буде, тож власникам таких серверів доведеться діяти самостійно.
Кого стосується загроза
Проєкти з підвищеним ризиком
Під удар потенційно потрапляє будь-що, що працює на PHP, але дві категорії варто перевірити першими. Це самописні сайти та проєкти на власних фреймворках, а також панелі керування хостингом на кшталт cPanel, Plesk чи DirectAdmin разом із самописними білінгами та панелями хостинг-провайдерів.
Сайти на WordPress
WordPress також працює на PHP, тому власникам таких сайтів теж варто знати свою версію інтерпретатора. Її можна подивитися в панелі хостингу або прямо в адмінці: розділ «Інструменти» → «Здоров’я сайту» → «Інформація» → «Сервер».
Що наразі відомо про php2shell
Назва та номери CVE
Назву php2shell вразливостям дали дослідники з компанії watchTowr. Вони ж використовують для них ідентифікатори CVE-2026-109618 та CVE-2026-109619, хоча в офіційному оголошенні PHP цих номерів немає.
Чого розробники ще не розкрили
Точний перелік вразливих версій, компонент PHP, у якому сидить проблема, і умови атаки (чи потрібна авторизація, чи має значення специфічна конфігурація сервера) PHP пообіцяли описати разом із релізом. Тимчасового обхідного рішення до виходу патча розробники не запропонували.
Чи є вже атаки
Станом на 21 жовтня ні спроб експлуатації, ні публічного експлойта ніхто не зафіксував. Про це повідомили watchTowr у своїх відповідях на часті запитання щодо php2shell, а також компанія Huntress.
Втім, розслаблятися не варто. Коли в червні 2024 року оприлюднили попередню серйозну ваду PHP, CVE-2024-4577, компанія Akamai помітила перші спроби атак на свої сервери-пастки вже протягом доби.
Як інформація вийшла назовні раніше строку
Анонімний допис і підтвердження дослідників
Спочатку деталі планували оприлюднити 22 жовтня. Проте 20 жовтня анонімний користувач форуму Hacker News написав про дві вразливості в PHP з максимальною оцінкою 10 з 10, які нібито зачіпають усі версії починаючи з PHP 5, хоча жодних доказів не навів. Того ж дня watchTowr підтвердили, що вразливості реальні й перебувають під ембарго, тобто під домовленістю не розголошувати подробиці до появи виправлення. Ввечері PHP випустили оголошення та зсунули реліз на добу раніше.
Що з цього не підтверджено
Твердження, що вразливі абсолютно всі версії від PHP 5, офіційно ніхто не підтвердив. watchTowr окремо зазначають, що жоден вендор цей діапазон не верифікував, а оцінка 10 з 10 походить виключно з того самого анонімного допису.
Масштаб проблеми: скільки серверів залишаться без патча
Дані Mallory
Компанія Mallory підрахувала, що 20 жовтня приблизно 884 тисячі серверів в інтернеті відображали у відповідях PHP версії 8.1 або старішої. Це близько 59% із майже 1,5 мільйона серверів, які взагалі показують номер версії PHP. Ще 740 тисяч машин повідомляють, що працюють на PHP, але версію приховують.
Обмеження цієї оцінки
Дані зібрали за допомогою Shodan – пошукової системи для пристроїв, підключених до мережі. Тому з цих цифр неможливо зрозуміти, скільки серверів насправді вразливі, адже йдеться лише про версії, які сервери самі про себе повідомляють.
План дій для адміністраторів і власників сайтів
Рекомендації нижче ґрунтуються на порадах компанії Huntress та CERT-EU – команди реагування на кіберінциденти для установ Європейського Союзу.
Інвентаризація
Перший крок – знайти всі місця, де у вашій інфраструктурі працює PHP. Сюди входять не лише сайти, а й панелі керування хостингом типу cPanel і Plesk та готове серверне програмне забезпечення, яке використовує PHP усередині.
Оновлення після релізу
Після 17:00 за Києвом 21 жовтня PHP слід оновити до версії з виправленням, і почати варто з серверів, що доступні з інтернету. Якщо сайт розміщено на хостингу, уточніть у провайдера, коли він встановить патч. Майте на увазі, що в пакетах дистрибутивів Linux виправлення може вийти під іншим номером версії, ніж в офіційному релізі PHP.
Що робити зі старими версіями
Сервери на PHP 8.1 і нижче потрібно переводити на 8.2 або новішу гілку. Якщо швидко зробити це неможливо, такі машини варто прибрати з публічного доступу, наприклад закрити за VPN або поставити перед ними файрвол для вебзастосунків (WAF).
Моніторинг підозрілої активності
Варто стежити, чи не запускають процеси PHP-FPM, PHP-CGI або вебсервера Apache командну оболонку, інтерпретатори чи утиліти для завантаження файлів. Така поведінка для звичайного сайту нетипова і може свідчити про спробу експлуатації.
Якщо є ознаки зламу
У разі виявлення чогось підозрілого сервер потрібно від’єднати від мережі та зберегти журнали вебсервера й PHP. Далі слід шукати веб-шели (файли, через які зловмисник віддалено керує сайтом), нові файли в кореневій теці сайту, нові завдання в планувальнику та облікові записи, яких раніше не було.
