PHP2Shell: як перевірити свій сервер і закрити небезпечну вразливість PHP

У PHP виявили дві критичні вразливості під назвою PHP2Shell. Вони дозволяють зловмисникам запускати власний код на вашому сервері без пароля.

Вразливості виправили 21 жовтня 2026 року, а атаки вже тривають. Якщо на вашому сервері є сайт на PHP, оновіть PHP сьогодні. Нижче наведено просту інструкцію, яка займе 10–15 хвилин.

Що сталося

PHP працює як офіціант у ресторані. Відвідувач (браузер) робить замовлення. Офіціант (PHP) несе його на кухню (сервер) і приносить результат — сторінку сайту.

 

Тепер уявімо дві ситуації.

 

Перша вразливість (CVE-2026-109618). Офіціант несе надто важкий піднос і впускає його на підлогу. Потім він прибирає уламки й помилково вважає їх цілим посудом. Так само працює PHP: коли йому бракує пам’яті, він залишає дані неповними. Зловмисник може навмисно спричинити таку ситуацію та впровадити власний код.

 

Друга вразливість (CVE-2026-109619). Відвідувач пішов, але залишив свої речі на столі. Офіціант їх не прибрав. Наступний відвідувач сідає за цей стіл і може скористатися залишеними речами. Так само й у PHP: після одного запиту в пам’яті можуть залишатися «чужі» дані. Наступний запит може отримати до них доступ або використати їх для атаки.

 

Обидві вразливості отримали оцінку небезпеки 9,2 із 10. Це дуже високий рівень ризику.

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

Це стосується всіх, у кого на сервері працює сайт або сервіс на PHP. Наприклад:
 

• WordPress, WooCommerce, Joomla, Drupal, OpenCart;

• 1С-Бітрікс, Magento, Laravel;

• phpMyAdmin, Nextcloud, форуми, самописні сайти;

• панелі керування, як-от ISPmanager, cPanel, aaPanel, HestiaCP.

Вразливими є всі версії PHP від 5.4 до 8.5.11. Не має значення, як PHP підключений до вебсервера: через PHP-FPM, Apache (mod_php), LiteSpeed чи іншим способом. Найбільше ризикують сайти на Apache з mod_php.
 

Якщо ви не знаєте, чи використовується PHP на вашому сервері, найімовірніше, він там є. На PHP працює близько 70% сайтів в інтернеті.

Наскільки це небезпечно?

Дуже небезпечно. Ось що вже відомо:
 

• Перші спроби атак помітили 17 жовтня — за чотири дні до виходу виправлень.

• Після 21 жовтня кількість спроб зросла з десятків тисяч до мільйонів за одну добу.

• До атак приєднався ботнет Mirai. Це мережа заражених пристроїв, яка автоматично шукає вразливі сервери по всьому інтернету.

Хороша новина: дослідники повідомляють, що більшість публічних експлойтів поки не спрацьовує зі стандартними налаштуваннями. Але це не привід зволікати.
 

Уявіть, що ви дізналися: у вашому під'їзді зламався замок на вхідних дверях. Злодії ще не заходили. Невже ви чекатимете, поки вони увійдуть? Тут така сама ситуація. Боти вже перевіряють сервери по всьому інтернету. Питання лише в тому, коли черга дійде до вашого.

Дізнайтеся версію PHP

Підключіться до сервера через SSH і виконайте команду:

php -v

У відповіді ви побачите рядок на кшталт PHP 8.3.30 (cli). Порівняйте свою версію з таблицею.

Важливо: на сервері може бути кілька версій PHP. Команда php -v показує лише одну з них. Сайт може працювати на іншій версії. Переглянути всі запущені версії можна так:

systemctl list-units --type=service | grep php

Якщо номер версії не змінився після оновлення, це не завжди погано. Ubuntu, Debian, AlmaLinux та інші системи часто інтегрують виправлення в стару версію. Номер залишається незмінним, але вразливість уже усунено. Перевірити це можна за журналом змін пакета.

Для Ubuntu та Debian:

zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php*-common/changelog.Debian.gz

Для AlmaLinux, Rocky Linux і CentOS Stream:

rpm -q --changelog php-common | grep -E 'CVE-2026-10961[89]'

Якщо команда вивела рядки з номерами CVE, виправлення встановлено. Якщо результат порожній, переходьте до кроку 2.

Оновіть PHP

Перед оновленням створіть резервну копію сайту та бази даних. Якщо щось піде не так, ви зможете швидко все відновити.

Ubuntu та Debian

sudo apt update
sudo apt upgrade

Після цього перезапустіть PHP. Замість 8.3 підставте свою версію:

sudo systemctl restart php8.3-fpm

Якщо сайт працює через Apache, перезапустіть і його:

sudo systemctl restart apache2

AlmaLinux, Rocky Linux, CentOS Stream

sudo dnf upgrade --refresh 'php*'
sudo systemctl restart php-fpm
sudo systemctl restart httpd

Панелі керування
 

• cPanel. Версії PHP (пакети ea-php) оновлюються разом із системою. Запустіть оновлення через WHM або командою sudo yum update.
• ISPmanager, aaPanel, HestiaCP та інші. Оновіть PHP у розділі керування версіями PHP в панелі або через системні пакети, як описано вище.
• Docker. Перезберіть образ на основі актуальної версії PHP і перезапустіть контейнер.

Не забудьте про перезапуск

Це найпоширеніша помилка. Нову версію PHP встановлено, але стара продовжує працювати в пам’яті. Це як купити новий замок, але залишити його в коробці. Двері й далі зачиняє старий замок. Тому після оновлення обов’язково перезапустіть PHP-FPM і вебсервер.

Після перезапуску відкрийте сайт і перевірте, чи він працює.

Додайте тимчасовий захист

Цей крок варто виконати всім, навіть після оновлення. Він допоможе закрити ще одну вразливість, для якої поки немає виправлення (про неї йтиметься нижче).

Спочатку знайдіть файл налаштувань PHP. Для сайту зазвичай використовується файл із папки fpm:

ls /etc/php/*/fpm/php.ini

В AlmaLinux і Rocky Linux файл зазвичай розташований тут: /etc/php.ini.

Відкрийте файл і додайте в кінець такий рядок:

session.upload_progress.enabled = 0

fatal_error_backtraces = 0

Збережіть файл і перезапустіть PHP, як описано в кроці 2.

 

Як це вплине на роботу сайту? Майже ніяк. Перестане працювати лише індикатор прогресу завантаження великих файлів, якщо він реалізований засобами PHP. На більшості сайтів такого індикатора немає.

Це не заміна оновленню. Тимчасовий захист — як ланцюжок на дверях. Він заважає злодієві, але не замінює надійний замок. Спочатку оновіть PHP, а потім додайте це налаштування.

Якщо у вас PHP 8.1 або старішої версії

Версії 8.1, 8.0, 7.x і 5.x більше не підтримуються розробниками PHP. Офіційних виправлень для них не буде. Таких серверів в інтернеті дуже багато — близько 70% усіх установок PHP.

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

Що можна зробити:
 

1. Перевірити пакети вашої системи. Деякі збірки все ж отримали виправлення. Наприклад, пакети Ondřej Surý для Ubuntu та Debian (ppa:ondrej/php), а також пакети AlmaLinux. Оновіть PHP, як описано в кроці 2, і перевірте журнал змін із кроку 1.
2. Перейти на нову версію PHP. Це найкращий варіант на майбутнє. Але старий сайт може не працювати з новою версією PHP. Перед переходом потрібно перевірити його сумісність.
3. Придбати розширену підтримку. Наприклад, TuxCare випускає виправлення для старих версій PHP за окрему плату.

У будь-якому разі обов’язково виконайте крок 3 із тимчасовим захистом.

Якщо ваш сервер працює на CentOS 7, виправлень для PHP там узагалі не буде. Ця операційна система також застаріла. Краще перенести сайт на AlmaLinux або Rocky Linux.

Ще дві новини, про які мало пишуть

Третя вразливість поки без виправлення. 23 жовтня розробники PHP повідомили про ще одну помилку: CVE-2026-115560. Вона спрацьовує лише за рідкісних налаштувань сайту. Термінового оновлення для неї не буде — виправлення вийде в наступній плановій версії. Захист такий самий, як у кроці 3. Якщо ви вже додали рядок session.upload_progress.enabled = 0, ви захищені.
 

У нових версіях виявили власні помилки. У версіях 8.4.27 і 8.5.12 виявили дві проблеми з пам’яттю. Одна з них з’явилася саме в цьому оновленні. Це не привід повертатися до старої версії: вона набагато небезпечніша. Просто стежте за новинами. Наступне оновлення PHP, найімовірніше, вийде найближчими тижнями, і його також потрібно буде встановити.
 

Отже, одного оновлення недостатньо. За безпекою сервера потрібно стежити постійно.

Чекліст
 

• Дізнався версію PHP за допомогою команди php -v

• Перевірив, чи немає на сервері інших версій PHP

• Створив резервну копію сайту та бази даних

• Оновив PHP до безпечної версії

• Перезапустив PHP-FPM і вебсервер

• Додав session.upload_progress.enabled = 0 у php.ini

• Перевірив, чи відкривається сайт і чи працює він належним чином

• Нагадав собі перевірити наступне оновлення PHP

Не хочете розбиратися самостійно?

Оновити PHP нескладно, якщо ви вже робили це раніше. Але бувають інші ситуації. Ви оновили PHP, а сайт показує білий екран. Або в панелі є три версії PHP, і незрозуміло, яку саме змінювати. Або сайт старий, і ви боїтеся його зламати.

Для таких випадків у Zomro є два варіанти.

SOD: зробимо все за вас
 

Ви пишете нам, а наш системний адміністратор самостійно:
 

• перевірить, які версії PHP встановлені на сервері та яку використовує сайт;

• оновить PHP і перезапустить служби;

• додасть тимчасовий захист;

• перевірить, чи працює сайт після оновлення.

Вартість: €12,50 за кожні 15 хвилин роботи. Зазвичай оновлення PHP не займає багато часу.

Замовити оновлення PHP
 

Premium: швидка допомога, коли вона потрібна

Звичайний технічний запит може оброблятися до 10 годин. Якщо сайт перестав працювати після оновлення, таке очікування може коштувати надто дорого. З Premium ви отримаєте відповідь фахівця за 5–30 хвилин.

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