Звичний сценарій зламу завжди вимагає якогось вхідного квитка – слабкого пароля, викраденого токена чи залишків старої адмінпанелі. Але що робити, коли для отримання доступу вистачає звичайного, на перший погляд цілком легітимного запиту до сайту, який змушує PHP виконувати сторонній код?
Саме про цю загрозу днями заговорили фахівці з безпеки, коли розкрили дві критичні вразливості в самому PHP. Не в якомусь популярному плагіні для WordPress і не в занедбаній CMS, а в самій мові програмування. Під ударом опинилися і крихітні сайти-візитки на віртуальному хостингу, і потужні VPS із нестандартними проєктами.
Ситуація настільки гостра, що Європейська команда реагування на комп’ютерні інциденти (CERT-EU) прямо рекомендувала ізолювати від мережі ресурси, які не вдається оперативно захистити.
Що сталося з PHP і чому небезпека настільки серйозна
Йдеться про дві вразливості CVE-2026-109618 та CVE-2026-109619, за якими стоять серйозні помилки. Обидві отримали по 9,2 бала за шкалою CVSS 4.0 – цифри говорять самі за себе.
Корінь зла криється в тому, як інтерпретатор працює з пам’яттю. В одному сценарії збій трапляється за нестачі ресурсів, коли внутрішні структури ще не сформовані до кінця. В іншому PHP повторно використовує ділянку пам’яті, яку вже встиг звільнити.
Збоку це може виглядати як звичайний запит від відвідувача. Проте в умілих руках збій перетворюється на класичну атаку RCE (Remote Code Execution). Що найнеприємніше – жодної авторизації не потрібно. Забудьте про підбір паролів до SSH чи спроби отримати доступ до адмінпанелі.
Механізм атаки може спрацювати ще до того, як сам рушій сайту взагалі візьметься за обробку запиту. Тобто навіть добре написаний та захищений застосунок може постраждати просто тому, що під ним працює вразлива версія PHP.
Як через один сайт можна отримати доступ до сервера
Візьмемо типовий VPS із середнім інтернет-магазином. Потік трафіку йде звичним шляхом: вебсервер приймає запит, передає його PHP, той звертається до бази даних і видає результат. Швидко і звично.
Але якщо в цей ланцюжок потрапляє експлойт, шкідливий код може запуститися з тими самими правами, під якими працює процес сайту. Далі все залежить від конфігурації.
Знайшовся доступ до конфігураційних файлів у каталозі – і ось у зловмисника вже є облікові дані для підключення до бази даних. Дозволено запис у кореневий каталог проєкту – чекайте на появу вебшелу. Після цього контроль над сайтом може опинитися в чужих руках.
Типова помилка налаштування – тримати кілька проєктів під одним системним користувачем без належної ізоляції. У такій схемі достатньо скомпрометувати один інтернет-магазин, щоб під загрозою опинилися сусідні сайти.
Звісно, сам факт виконання коду не дає повного доступу до всього сервера одним кліком. Якщо ізоляція налаштована належним чином, а процеси працюють з обмеженими правами, можливості зловмисника будуть суттєво обмежені. Проте навіть цього зазвичай вистачає для серйозного головного болю.
Які сервери можуть постраждати найбільше
Масштаб проблеми вражає: під загрозою версії від PHP 5.4 до 8.5.11 включно. Спосіб запуску PHP не гарантує захисту – у списку і PHP-FPM, і класичний Apache mod_php, і php-cgi разом із FrankenPHP та LiteSpeed.
Окрему тривогу викликає зв’язка Apache з модулем mod_php. Для неї вже продемонстровано можливість атаки, здатної обійти захист самого застосунку.
Найважче доведеться тим, хто роками не зазирав у налаштування сервера. Стару версію PHP часто залишають за принципом «працює – не чіпай»: на ній працює старе корпоративне програмне забезпечення, бухгалтерська система чи нестандартний інтернет-магазин. Оновлюватися бояться через ризик порушити робочі процеси.
Тільки от відсутність помилок у журналах не означає, що система захищена. Сервер може місяцями працювати без єдиного збою, залишаючись доступним для чергової спроби атаки.
Те саме стосується Docker-контейнерів. Хоча сама хостова система може оновлюватися регулярно, старий образ усередині контейнера продовжує працювати з вразливою версією PHP.
Чи можна захиститися звичайним фаєрволом
Мережевий фаєрвол корисний, коли треба закрити зайві порти або відсіяти спроби підбору паролів. Але не тут. Для мережевих засобів захисту цей трафік може виглядати як черговий звичайний запит на отримання сторінки. Зміна пароля SSH чи блокування непотрібних портів саму вразливість не усунуть.
WAF (Web Application Firewall) дещо покращує ситуацію, відсіюючи частину шкідливих запитів, проте розробники виправлень кажуть прямо: це лише тимчасовий захід, а не повноцінне рішення.
Головне – права доступу. Окремий системний обліковий запис для кожного сайту, мінімум зайвих дозволів для процесів PHP – це базові запобіжники, які допомагають обмежити наслідки атаки. Вони не усувають вразливість самого інтерпретатора, але дають шанс утримати зловмисника в межах ізольованого середовища.
Що перевірити на VPS або виділеному сервері вже зараз
Почніть із перевірки фактично встановлених версій PHP. Консольна команда php -v покаже лише версію інтерпретатора, який запускається з командного рядка за замовчуванням. Проте сайт може працювати через зовсім інший пул PHP-FPM, тому перевіряйте саме те середовище, яке обробляє вхідні запити.
Виправлення вже доступні в офіційних випусках PHP 8.2.35, 8.3.36, 8.4.27 та 8.5.12. Якщо ви встановлюєте пакети з репозиторіїв дистрибутива Linux, перевіряйте оновлення від супроводжувачів пакетів. Часто вони переносять виправлення до старіших версій, залишаючи основний номер версії незмінним.
Зі старими гілками на кшталт PHP 8.1 ситуація складніша: офіційної підтримки більше немає, тому доводиться покладатися на репозиторії з розширеною підтримкою. Якщо виправлених пакетів узагалі немає, доведеться планувати перехід на підтримувану версію.
Перед будь-якими змінами робіть резервні копії та перевіряйте сумісність програмного забезпечення. Після оновлення обов’язково перезапустіть відповідні служби, інакше старі процеси ще деякий час залишатимуться в пам’яті зі старим кодом.
І головне правило: відсутність тривожних симптомів не доводить, що система захищена. Вразливість не обов’язково спричиняє помітні збої в роботі сервера. Іноді про те, що щось пішло не так, ви дізнаєтеся вже після успішного виконання стороннього коду.