PHP2Shell: вразливості PHP CVE-2026-109618 і 109619 — що робити

Оновлено: 08.11.2026, за даними php.net, CVE.org, NVD і CISA. Перша версія статті вийшла 21.10.2026, до публікації виправленого випуску PHP.

Якщо хостинг наприкінці жовтня надіслав листа про термінове оновлення PHP, а в новинах писали про «PHP2Shell», ішлося про одну подію: у самому PHP, а не в CMS чи плагінах, знайшли дві критичні вразливості. Перша — вразливість PHP CVE-2026-109618, друга — CVE-2026-109619. 21 жовтня 2026 року PHP випустив виправлення, а 26 жовтня американське агентство CISA внесло обидві до каталогу вразливостей, які реально використовують в атаках. Нижче зібрано те, що офіційно підтвердили PHP і бази CVE, те, що залишається непідтвердженим, і порядок дій для власника сайту: як перевірити, чи оновлено сервер, хто має це робити і що робити із сайтом на PHP 8.1 або старішій версії.

Що сталося: хронологія з 20 по 26 жовтня

20 жовтня команда безпеки PHP опублікувала на php.net попереднє повідомлення: 21 жовтня о 14:00 UTC (17:00 за Києвом) вийде випуск, який закриє дві критичні вразливості з оцінкою 9,2 за шкалою CVSS v4.0. CVSS — загальноприйнята шкала небезпеки вразливостей від 0 до 10, оцінки від 9,0 належать до критичного рівня. Ще до випуску деталі витекли в мережу, і дослідники назвали подію «PHP2Shell». Цю назву вигадали не в PHP.

21 жовтня, як і було заплановано, PHP випустив версії 8.5.12, 8.4.27, 8.3.36 і 8.2.35 та опублікував бюлетень безпеки. Того ж дня записи CVE-2026-109618 і CVE-2026-109619 з’явилися в базах CVE.org і NVD, а Ubuntu випустила виправлені пакети. Debian виклала оновлення для Debian 12 і 13 у репозиторії безпеки.

23 жовтня PHP додав інформаційне повідомлення про налаштування session.upload_progress.enabled (про нього нижче). 26 жовтня CISA внесла обидві вразливості до каталогу експлуатованих вразливостей KEV із терміном усунення для федеральних відомств США до 29 жовтня. Потрапляння до KEV означає, що CISA має підтвердження атак із використанням цих вразливостей.

Що офіційно підтверджено

Джерела розділу — php.net, бюлетені PHP на GitHub, записи CVE.org і NVD, каталог CISA KEV.

• Тип вразливостей. PHP називає обидві вразливості віддаленим виконанням коду без авторизації (RCE, remote code execution): зловмисник може запустити на сервері свої команди, не маючи облікового запису. CVE-2026-109618 — «RCE через пошкодження пам’яті за нестачі пам’яті», CVE-2026-109619 — «RCE через застарілий глобальний стан». Обидві оцінено в 9,2 за CVSS v4.0; NVD додатково оцінила їх за CVSS v3.1 у 9,8 і 8,1.
• Хто під загрозою. Усі інсталяції PHP, які обслуговують вебзапити: PHP-FPM, Apache з mod_php, php-cgi, FrankenPHP і LiteSpeed. Найбільший ризик PHP бачить для mod_php: там продемонстровано атаку, за якої запит без авторизації спрацьовує до запуску коду сайту.
• Виправлені версії. 8.5.12, 8.4.27, 8.3.36 і 8.2.35. Усі раніші випуски цих гілок вразливі, зокрема 8.2.34, 8.3.35, 8.4.26 і 8.5.11 від 24 вересня 2026 року.
• Старі гілки. PHP 8.1 і старіші оновлень від проєкту PHP не отримують: підтримка 8.1 закінчилася 31 грудня 2025 року, 8.0 — у листопаді 2023-го. Через серйозність випадку команда безпеки PHP як виняток виклала на GitHub мінімальні виправлення вихідного коду для 7.4, 8.0 і 8.1. Це не готові випуски, вони розраховані на тих, хто збирає PHP із вихідників сам. Дистрибутиви Linux і постачальники розширеної підтримки отримали виправлення заздалегідь. NVD вказує вразливі діапазони з версії 7.3.0 для CVE-2026-109618 і з версії 5.4.0 для CVE-2026-109619.
• Повного захисту без оновлення немає. У кожному оголошенні про випуск PHP повторює: повних обхідних заходів не існує, оновлення — єдиний безпечний вибір. Тимчасові налаштування знижують ризик лише для окремих шляхів атаки.
• Атаки тривають. Це підтвердження CISA (каталог KEV, статус експлуатації «активна» в записах NVD). Сам PHP про помічені атаки в бюлетенях не писав.
• Підтримка 8.2 закінчується 31 грудня 2026 року. PHP нагадав про це в оголошенні про випуск 8.2.35.

Що залишається непідтвердженим

• Масштаб атак. У перші години після витоку про перші атаки повідомляв технічний директор Cloudflare, CERT-EU у бюлетені 2026-018 очікувала масової експлуатації. Факт атак CISA підтвердила, але ні PHP, ні CISA не публікували даних про кількість постраждалих сайтів і про те, які варіанти атак застосовують.
• «Вразливі всі версії починаючи з PHP 5». Формулювання прийшло із соцмереж, на нього посилалася CERT-EU. Бюлетені PHP перелічують лише гілки 8.2–8.5, а виправлення коду для старих гілок PHP випустив для 7.4, 8.0 і 8.1. Діапазон NVD для CVE-2026-109619 починається з 5.4.0, але це оцінка NVD, а не заява PHP.
• Працездатність публічних «експлойтів». Код, який у жовтні видавали за інструмент атаки, надійні джерела не перевіряли. Посилань на такий код і опису механіки атаки у статті немає: власникові сайту вони не допоможуть.

Що зробити, якщо сервер ще не оновлено

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

Як дізнатися версію PHP

У WordPress версія видна в розділі «Інструменти → Стан сайту», вкладка «Інформація», блок «Сервер». На будь-якому іншому рушії версію показує панель хостингу (cPanel, Plesk, ISPmanager і аналоги) у розділі вибору версії PHP. Усі способи, включно з перевіркою фонових завдань (cron), розібрано у статті PHP 8.1/8.2 без підтримки: що робити власникові сайту.

Порівняйте номер із виправленими: 8.2.35, 8.3.36, 8.4.27, 8.5.12 або новіше. Якщо номер менший, сайт вразливий, за одним винятком — пакети дистрибутивів Linux (про них нижче). Якщо у вас 8.1, 8.0 або 7.x, переходьте до розділу про старі версії.

Хто оновлює PHP

На звичайному (віртуальному) хостингу оновити PHP на сервері може лише хостинг-провайдер, ви можете тільки вибрати гілку в панелі. Якщо провайдер не писав про оновлення, запитайте підтримку прямо: чи встановлено випуски 8.2.35, 8.3.36, 8.4.27 і 8.5.12 або виправлені пакети дистрибутива.

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

• Після оновлення пакетів потрібно перезапустити PHP-FPM або вебсервер: запущені процеси тримають у пам’яті старий код, і без перезапуску сайт залишається вразливим. PHP у бюлетені вимагає перезапускати кожен робочий процес. Перезапуск обірве запити, які обробляються в цей момент, і відвідувачі на кілька секунд можуть побачити помилку 502. Перезапустіть і фонові PHP-процеси, наприклад обробники черг.
• У Debian, Ubuntu, RHEL та інших дистрибутивах виправлення часто переносять у пакет без зміни основної версії PHP. Приклад із цього випадку: в Ubuntu 24.04 виправлений пакет називається php8.3 8.3.6-0ubuntu0.24.04.13, і php -v, як і раніше, показує 8.3.6. Перевіряти потрібно версію пакета і бюлетень безпеки дистрибутива (для Ubuntu — USN-8948-1), а не лише цифри PHP.

PHP працює не лише на основному сайті. Перевірте тестові копії, CRM та облікові портали, образи Docker (їх потрібно перезібрати на виправленій версії) і панелі керування сервером, у яких своя збірка PHP.

Оновлення всередині гілки безпечне

Перехід із 8.3.35 на 8.3.36 і перехід із 8.2 на 8.3 — різні за ризиком операції. За правилами випуску PHP версії формату x.y.z → x.y.z+1 містять лише виправлення помилок і зберігають зворотну сумісність. У гілках 8.2 і 8.3 випуски від 21 жовтня містять рівно одну зміну — виправлення двох вразливостей. Код, який працював на 8.3.35, запрацює і на 8.3.36.

Зміна гілки (8.2 → 8.3) — інша річ. У кожній новій гілці є розділ «несумісні зміни» і список застарілих функцій, старі плагіни й модулі на ній можуть перестати працювати. Зміну гілки перевіряють на копії сайту, а виправлення безпеки всередині гілки ставлять одразу. Резервну копію перед оновленням зробіть у будь-якому разі.

Сайт на PHP 8.1 і старіших версіях

Офіційних випусків для 8.1 і раніших гілок немає і не буде: за політикою PHP гілка, термін підтримки якої закінчився, виправлень не отримує. Виправлення вихідного коду для 7.4, 8.0 і 8.1 на GitHub знадобляться лише адміністраторові, який збирає PHP сам.

Для решти шлях один — пакети дистрибутива або постачальника розширеної підтримки. Ubuntu 22.04 отримала виправлений пакет php8.1, для Ubuntu 20.04, 18.04 і 16.04 виправлення вийшли в платній програмі ESM (PHP 7.4, 7.2 і 7.0). Якщо сайт на VPS зі старою системою, запитайте адміністратора, чи вийшло виправлення для вашого пакета PHP. На звичайному хостингу поставте те саме запитання провайдерові.

Якщо виправленого пакета для вашої версії немає, варіанти такі:

1. Перевести сайт на підтримувану гілку, краще на 8.3 або новішу: підтримка 8.2 закінчується 31 грудня 2026 року. Порядок переходу описано у статті про кінець підтримки PHP 8.2.
2. Поки перехід не завершено, прибрати сайт із відкритого інтернету або закрити його фільтром (див. тимчасові заходи нижче).
3. Сайт, який не приносить грошей і не потрібен, вимкнути до переходу.

Залишати сайт на PHP 8.1 без виправлення тепер, коли атаки підтверджено, ми не радимо. На гілки без підтримки попереду чекають нові вразливості.

Тимчасові заходи за даними PHP

Жоден із заходів нижче не замінює оновлення: за формулюванням PHP, вони знижують ризик для окремих шляхів атаки, але не роблять інсталяцію безпечною. Список узято з бюлетеня PHP від 21 жовтня. До випуску офіційних рекомендацій не було, і в першій версії статті налаштування session.upload_progress.enabled подавалося як неофіційне.

Налаштування з бюлетеня PHP

Для CVE-2026-109618 PHP радить задати memory_limit=-1 так, щоб застосунок не міг перевизначити значення (через php_admin_value у пулі PHP-FPM або конфігурації Apache), і перевірити, що жодне налаштування пулу, каталогу чи сайту не повертає обмеження пам’яті назад. Другий захід — обмежити розмір запиту: post_max_size = 8M для сайтів без завантаження файлів, post_max_size = 32M, якщо завантаження потрібне; upload_max_filesize має бути меншим за post_max_size. Ліміти на розмір і склад запиту PHP рекомендує додатково задати на рівні вебсервера або проксі.

Для CVE-2026-109619 PHP радить вимкнути session.upload_progress.enabled і перезапустити всі робочі процеси. На PHP 8.5 додатково — fatal_error_backtraces=0, теж із перезапуском. Ще PHP просить прибрати з налаштувань сайту недійсні й застарілі параметри, які видають попередження під час запуску, і виправити помилки в коді, які зловмисник може викликати запитом. Приховувати попередження через error_reporting, display_errors або @ марно.

Вимкнення session.upload_progress.enabled

За посібником php.net, session.upload_progress.enabled вмикає відстеження перебігу завантаження файлів через сесію і типово увімкнене (значення 1). Налаштування потрібне лише індикаторам завантаження, які окремим запитом дізнаються в сервера прогрес із сесії PHP. Такі трапляються рідко: звичайна смужка завантаження, яку рахує браузер, від налаштування не залежить. Саме завантаження файлів після вимкнення працює як раніше. Англійська версія посібника і безвідносно до цих вразливостей радить вимикати налаштування там, де індикатори прогресу не використовують.

Де змінювати. Режим налаштування — INI_PERDIR, тобто формально його приймають php.ini, .htaccess (якщо PHP працює модулем Apache), httpd.conf і .user.ini. Але PHP у бюлетені вимагає задавати його там, де значення застосовується до розбору запиту: у php.ini, пулі PHP-FPM або конфігурації сервера. На ini_set() і на .user.ini під PHP-FPM покладатися не можна. У php.ini рядок такий:

session.upload_progress.enabled = Off

У httpd.conf (PHP модулем Apache):

php_admin_flag session.upload_progress.enabled off

php_admin_flag, на відміну від php_flag, не можна перевизначити через .htaccess. У пулі PHP-FPM на VPS — php_admin_flag[session.upload_progress.enabled] = off, після цього перезапустіть PHP-FPM.

На звичайному хостингу налаштування змінюють у панелі (розділ параметрів PHP), якщо провайдер його туди виніс. Якщо такого пункту немає, попросіть підтримку хостингу змінити налаштування на рівні сервера: файл .user.ini у корені сайту для цього заходу PHP вважає ненадійним. Потім перевірте результат: у виводі phpinfo() (його покаже адміністратор або підтримка) у session.upload_progress.enabled має стояти Off.

Чи залишати налаштування вимкненим після оновлення. 23 жовтня PHP опублікував інформаційне повідомлення: до наступного планового випуску PHP пропонує тримати session.upload_progress.enabled=0, щоб закрити ще один малоймовірний шлях атаки (CVE-2026-115560). Проблема виникає лише за незвичного поєднання налаштувань і коду застосунку, тому PHP закриває її у звичайному циклі випусків. Якщо ви вимкнули налаштування в жовтні, залиште його вимкненим; якщо індикатори прогресу завантаження вам не потрібні, є сенс вимкнути його і на оновленому сервері.

WAF

WAF (Web Application Firewall) — фільтр запитів перед сайтом. Cloudflare випустив правила для відомих варіантів атаки, вони доступні й на безкоштовному тарифі; сам Cloudflare називає їх тимчасовим заходом. Фільтр захищає лише трафік, який через нього йде: якщо адреса сервера відома, зловмисник обійде WAF і звернеться до сервера безпосередньо. WAF має сенс лише разом із правилом «сервер приймає запити лише від WAF», і навіть тоді правила ловлять лише відомі варіанти атаки.

Ізоляція

CERT-EU радила там, де оновити одразу не можна, прибрати доступні з інтернету застосунки з публічної мережі до встановлення виправлень. Для бізнесу це означає: внутрішні системи, адмінки, CRM та облікові портали на PHP закрити за VPN або обмежити доступ за IP-адресами офісу. Публічний сайт так не сховаєш, для нього залишаються WAF або тимчасове вимкнення.

Ознаки злому сайту

Виправлення вийшли 21 жовтня, атаки підтверджено. Якщо сервер оновили із затримкою в кілька днів, перевірте його на такі ознаки:

• на сервері з’явилися незнайомі PHP-файли, особливо в папках завантажень;
• в адмінці з’явилися користувачі, яких ніхто не створював;
• хостинг повідомляє про різке зростання навантаження, розсилання спаму або блокує акаунт;
• пошук або браузер показують попередження про небезпечний сайт, відвідувачів перенаправляє на чужі сторінки;
• у планувальнику завдань (cron) з’явилися невідомі завдання;
• для адміністратора сервера: процеси PHP-FPM або вебсервера запускають командну оболонку, curl або wget.

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

Чим допоможе RIVERIT

Клієнтам на техпідтримці відповідаємо протягом години, інциденти усуваємо й поза робочим часом, якщо це входить у тариф. Для VPS і виділених серверів пропонуємо адміністрування: firewall, ізоляцію сайтів один від одного, аналіз логів, а під час атак підключаємо захист від DDoS. Якщо ознаки злому вже є, беремося за відновлення сайту. Тим, кому потрібен сервер разом з обслуговуванням, пропонуємо захищений хостинг на серверах у Європі зі щоденними резервними копіями в окреме сховище.