PHP2Shell: що власнику сайту на DLE треба знати про дві RCE в PHP

21 жовтня 2026 року навколо PHP з'явилася термінова причина перевірити серверну частину сайту. У проєкті виправили CVE-2026-109618 і CVE-2026-109619 — помилки, за яких запит ззовні здатен призвести до виконання коду на неоновленому веб-обробнику. Для власника DLE-сайту головний висновок простий: версія рушія і встановлені модулі не скасовують ризик, бо вразливий компонент розташований на рівні PHP.

Релізи з виправленнями від самого PHP: 8.2.35, 8.3.36, 8.4.27 і 8.5.12. Зі старими гілками 8.1, 8.0 і 7.4 порівняння лише за коротким рядком версії ненадійне. Їхню стандартну підтримку завершено, а постачальник хостингу чи дистрибутива може перенести виправлення у свій пакет, зберігши базовий номер.

Коротко#

• Уразливості мають ідентифікатори CVE-2026-109618 і CVE-2026-109619; обидві оцінено в 9,2 з 10 за CVSS v4.0.
• Ризик є у PHP-FPM, Apache з mod_php та в інших веб-обробників, зокрема php-cgi з LiteSpeed.
• php -v в SSH показує версію командного рядка. Вона може не збігатися з PHP, який відповідає відвідувачам сайту.
• WAF, Cloudflare, обмеження завантаження файлів і вимкнення одного розширення не замінюють оновлення. Тимчасові заходи лише зменшують окремі варіанти атаки.
• Після встановлення оновлення треба переконатися, що перезапущено саме веб-обробник PHP і сторінки сайту працюють уже на виправленій версії.

Що сталося#

В екстреному повідомленні PHP ідеться про два дефекти керування пам'яттю в самому інтерпретаторі. Це не чергова проблема конкретного шаблону, плагіна чи CMS.

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

В обох випадках відправна точка — HTTP-запит до доступного ззовні сайту. Вхід в адмін-панель, уразливий модуль DLE чи завантаження розширення не є обов'язковою умовою. Тому публічні проєкти треба ставити на початок черги на оновлення.

PHP окремо вказує, що найбільший ризик зараз пов'язують із mod_php: там підтверджено сценарій, за якого неавторизований запит запускає атаку ще до виконання коду самого застосунку. Але вважати PHP-FPM безпечним лише тому, що він інший, не можна. В офіційному списку вразливих веб-інсталяцій перелічено різні варіанти: PHP-FPM, php-cgi, FrankenPHP; LiteSpeed.

Кого стосується проблема#

Власник сайту на DLE зазвичай дивиться на версію рушія і версії модулів. У цій ситуації порядок інший: спершу треба з'ясувати, який PHP запускає сторінку сайту.

Під перевірку потрапляють:

• сайт на звичайному віртуальному хостингу;
• VPS з nginx і PHP-FPM;
• Apache з mod_php або PHP-FPM;
• сервер під керуванням ISPmanager, Hestia, Plesk, cPanel та аналогічних панелей;
• кілька сайтів на одному сервері, навіть якщо лише один із них використовує DLE;
• панелі й готові продукти, всередині яких PHP працює як залежність.

В останньому пункті легко помилитися. Наприклад, Plesk окремо оновлює користувацькі PHP-обробники і свій внутрішній sw-engine. Якщо оновити лише PHP для сайтів, це не означає, що оновлено сам компонент панелі. Конкретний список версій і статус патчів треба дивитися у свого постачальника панелі, а не переносити таблицю з чужої інструкції.

Які версії закривають проблему#

Для підтримуваних гілок проєкту PHP фікс вийшов 21 жовтня:

Для PHP, зібраного з вихідних кодів проєкту, менший номер означає, що треба перейти на вказану виправлену версію. У пакетного PHP спершу перевірте advisory свого дистрибутива: постачальник може перенести патч у версію з іншим номером. «У мене PHP 7.4.33» саме собою не відповідає на запитання. Upstream-гілки 7.4, 8.0 і 8.1 завершили стандартну підтримку. PHP підготував мінімальні вихідні backport-гілки, а деякі дистрибутиви та LTS-постачальники включили виправлення у свої пакети. Номер базової версії при цьому може залишитися тим самим. Це видно і в таблиці Plesk для EOL-гілок.

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

Чому php -v — лише початок перевірки#

На VPS звично виконати:

php -v

Команда корисна, але вона показує PHP для командного рядка. Сайт може обслуговуватися іншою гілкою PHP-FPM, альтернативним бінарником панелі чи окремим обробником LiteSpeed. Бувають і заплутаніші варіанти: у CLI вже встановлено нову версію, а старі FPM-воркери продовжують тримати в пам'яті попередній рантайм.

Порядок перевірки має бути таким:

1. Дізнайтеся в панелі хостингу або налаштуваннях сайту призначену йому версію PHP і обробник.
2. Порівняйте її з версією встановленого пакета, якщо є доступ по SSH.
3. Після оновлення перезапустіть саме службу, яка виконує веб-запити сайту.
4. Перевірте версію через закритий від сторонніх діагностичний механізм панелі або тимчасову захищену сторінку. Не залишайте публічний phpinfo() у корені сайту: він розкриває зайві деталі про сервер.
5. Відкрийте сайт і виконайте звичайні дії користувача: вхід у панель, завантаження зображення, збереження новини, робота форми зворотного зв'язку. Потім перегляньте журнал помилок PHP і веб-сервера.

На віртуальному хостингу найчастіше це робить провайдер. Ваше завдання — не писати в підтримку «оновіть PHP», а назвати конкретний сайт, PHP-handler і дві CVE. Якщо панель дозволяє вибрати PHP 8.4, вибір «8.4» ще не дорівнює 8.4.27: попросіть показати повну версію обробника.

Як діяти на VPS#

На сервері не можна наосліп копіювати одну команду з інтернету: Debian, Ubuntu, AlmaLinux, панелі керування і сторонні репозиторії постачають PHP по-різному. Безпечна послідовність однакова.

Спершу зробіть резервну копію конфігурацій і зафіксуйте поточні версії пакетів. Потім оновіть пакети з довіреного репозиторію дистрибутива або репозиторію вашої панелі. Якщо використовується PHP-FPM, перезапустіть потрібний пул або сервіс після оновлення. Для Apache з mod_php знадобиться перезапуск Apache. Після цього повторіть перевірку через веб, а не лише в SSH.

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

Якщо ви використовуєте Hestia, ISPmanager, Plesk або cPanel, спершу подивіться документацію саме панелі. Вона може керувати окремими пакетами PHP та їхніми версіями незалежно від системного /usr/bin/php. Самостійне встановлення стороннього репозиторію «аби отримати нову цифру» іноді ламає зв'язку з панеллю і не закриває той обробник, який фактично обслуговує сайт.

Що робити, якщо сайт працює на PHP 7.4, 8.0 або 8.1#

З PHP 7.4, 8.0 і 8.1 ситуація складніша. DLE-сайт може роками працювати на PHP 7.4, бо старий шаблон чи модуль не готовий до нової гілки. Але «працює» не означає «можна не оновлювати». Проєкт PHP більше не випускає для цих гілок звичайні оновлення.

Далі є три реалістичні шляхи.

Перший — отримати підтверджений backport від хостера або постачальника Linux. Це тимчасове рішення, яке закриває саме поточні CVE, але не повертає гілці повноцінну підтримку.

Другий — перейти на підтримувану гілку PHP і доопрацювати несумісний код. Це вимагає підготовки й резервної копії, зате перестає перетворювати кожну нову вразливість на термінову пошукову операцію.

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

У Plesk для деяких EOL-гілок виправлений пакет може зберегти той самий номер, але мати іншу дату збірки. Отже, перевірки за рядком 7.4.33 недостатньо. Потрібні дані панелі, дата пакета або офіційна відповідь провайдера.

Тимчасові заходи: що вони дають і чого не дають#

У PHP є рекомендації для тих, хто фізично не встигає оновитися. Їх не можна перетворювати на заголовок «як захиститися без оновлення». Офіційна позиція жорстка: повним захистом залишається лише встановлення виправленого PHP.

Для CVE-2026-109618 проєкт PHP радить прибрати керовану застосунком верхню межу memory_limit, обмежити розмір POST-запитів і стежити, щоб ліміт завантаження був нижчим за загальний ліміт POST. Це скорочує підтверджений шлях через контрольовану нестачу пам'яті, але не виключає реальної помилки виділення пам'яті й не закриває другу CVE. Повні межі цих заходів перелічено в advisory PHP.

Для CVE-2026-109619 згадується вимкнення session.upload_progress.enabled на рівні конфігурації, що застосовується до розбору запиту, та обов'язковий перезапуск воркерів. Це перекриває підтверджені шляхи через сесії, але не всі можливі варіанти. Зміни через ini_set() усередині DLE-модуля чи .user.ini недостатньо: на момент виконання коду запит уже розібрано.

Cloudflare, WAF і фільтри запитів не виправляють пам'ять PHP і не мають бути причиною відкласти оновлення. Те саме стосується видалення форми завантаження файлів: воно не є доказом безпеки всього рантайму.

Що перевірити на сайті DLE після оновлення#

Одного відкриття головної сторінки після оновлення недостатньо. Оновлення PHP може зачепити розширення, OPcache, обробку зображень, старі виклики функцій і налаштування кодування.

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

На сайті з чергами, парсерами чи cron-завданнями перевірте й їх. Вони можуть використовувати інший CLI-PHP, ніж веб, тому в завданні планувальника має бути вказана та сама виправлена гілка або підтверджений пакет із backport. Не змінюйте версію в бою одночасно для всіх сайтів без резервної копії та плану відкату.

Якщо є підозра на злам#

Патч зупиняє відомий шлях, але не видаляє вже залишений на сервері код. На публічному сайті пріоритет — обмежити доступ або поставити виправлення; не відкладайте це заради довгого аудиту. Якщо ситуація дозволяє, збережіть журнали веб-сервера і PHP, список нещодавно змінених файлів, завдання cron і дані про нових користувачів панелі до робіт або одразу після них. Потім перевірте підозрілі PHP-файли в папках завантажень, невідомі завдання cron, додаткові облікові записи адміністраторів, зміни в .htaccess і вихідні з'єднання.

Не варто оголошувати сайт чистим лише тому, що антивірус нічого не знайшов. І не варто автоматично вважати будь-який дивний файл наслідком цієї вразливості: потрібна перевірка дат, журналів і призначення файлу. Британський NCSC радить тим, хто не може швидко оновитися чи вимкнути сервіс, оцінити систему на ознаки компрометації до робіт і за потреби залучити фахівців із реагування.

Джерела#

• PHP: Security advisory: Critical remote code execution vulnerabilities, update now
• ENISA: Joint statement on critical PHP vulnerabilities
• NCSC UK: Critical security issue affecting PHP
• Ubuntu: php2shell vulnerability fixes available
• Plesk: PHP RCE in PHP shipped with Plesk

Перевірено за джерелами: 22.10.2026. Технічні рекомендації треба звіряти з документацією свого хостингу і панелі: склад пакетів і способи перезапуску в постачальників різняться.

Перевірено на: Официальные источники PHP, ENISA, NCSC, Ubuntu и Plesk — 22.10.2026