PHP2Shell: як UAhosting усунув CVE-2026-109618 та CVE-2026-109619

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

На всіх серверах спільного хостингу UAhosting встановлено виправлення CVE-2026-109618 та CVE-2026-109619. Необхідні серверні заходи для усунення саме цих двох вразливостей виконано. Інформація актуальна на 26 жовтня 2026 року.

Що таке PHP2Shell і в чому небезпека

21 жовтня розробники PHP опублікували виправлення двох критичних вразливостей, відомих під спільною назвою PHP2Shell. Їхня оцінка — 9,2 бала за CVSS v4.0. За певних умов вони дозволяють віддалене виконання коду без авторизації: зловмиснику не обов’язково знати пароль адміністратора сайту.

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

Це помилки самого PHP. Оновлення WordPress, OpenCart або плагінів не виправляє серверний інтерпретатор. PHP наголошує, що ризик стосується різних обробників вебзапитів, зокрема PHP-FPM і LiteSpeed; найвищим його визнано для Apache з mod_php. Подробиці наведено в офіційному повідомленні PHP та бюлетені японської агенції IPA.

Які заходи виконав UAhosting

Ми встановили оновлені пакети PHP на всіх серверах спільного хостингу. Також застосували системні оновлення, включно з доступними оновленнями ядра, та перезавантажили сервери. Перезапуск забезпечив використання виправленого коду новими PHP-процесами.

Наявність виправлень перевіряли за встановленими пакетами та їхніми журналами змін. Додатково перевірили роботу Imunify360/ModSecurity: у журналах підтверджено блокування запитів, які відповідали відомому способу експлуатації PHP2Shell. Про виконані роботи повідомили клієнтам у розсилці.

Для клієнта спільного хостингу це означає: самостійно встановлювати серверні патчі або терміново перемикати сайт на іншу гілку PHP через ці дві CVE не потрібно.

Чому номер PHP міг залишитися попереднім

Офіційні виправлені випуски PHP — 8.2.35, 8.3.36, 8.4.27 та 8.5.12. Проте CloudLinux спочатку переніс патчі у власні збірки зі збереженням номерів 8.2.34, 8.3.35, 8.4.26 і 8.5.11. Такий підхід називається backport.

Тому сам напис «PHP 8.5.11» не доводить відсутності захисту. Важливі конкретний випуск пакета та внесені виправлення. Згодом CloudLinux також випустив пакети з новими номерами PHP і підтвердив: попередні виправлені збірки вже захищають від обох CVE. Це пояснено в офіційній хронології інциденту.

Що з PHP 7.4 та старими магазинами

Один із запитів стосувався магазину на OpenCart: перехід на PHP 8 потребував би адаптації модулів. У цьому випадку потрібно розрізняти оновлення безпеки PHP та зміну його основної гілки.

CloudLinux надає виправлення для старіших гілок у межах власної підтримки, зокрема HardenedPHP. Встановлені нами оновлення закривають зазначені CVE без обов’язкового переходу магазину з PHP 7.4 на PHP 8. Водночас патч PHP не усуває можливі помилки CMS, теми чи модулів: їхню підтримку й майбутню міграцію варто планувати окремо.

Яку роль відіграє Imunify360

За повідомленням CloudLinux, Imunify360 отримав правила для блокування відомих шкідливих запитів і публічних інструментів атаки. Це додатковий рівень захисту. Виробник прямо зазначає: WAF не замінює оновлення PHP, оскільки вразливості ширші за один сценарій завантаження файлів. На UAhosting застосовано обидва заходи — виправлення PHP та захист веббрандмауера.

Нові перемикачі в налаштуваннях PHP

Після звернення клієнта ми додали можливість самостійно обирати значення session.upload_progress.enabled і fatal_error_backtraces. Відкрийте cPanel → Select PHP Version → Options («Опції»).

session.upload_progress.enabled керує відстеженням прогресу завантаження файлів через PHP-сесії. Значення Off не забороняє завантажувати файли, але вимикає саме цей механізм прогресу та скасування. Якщо сайт його не використовує, функцію доцільно вимкнути. Після зміни перевірте форми завантаження. Документація PHP російською.

fatal_error_backtraces визначає, чи додавати ланцюжок викликів до фатальних помилок. Перемикач доступний лише для PHP 8.5+. Його вимкнення зменшує деталізацію діагностики; після встановлення патчів обох CVE це не обов’язкова умова захисту. Для робочого сайту окремо слід вимкнути показ помилок відвідувачам через display_errors. Опис параметра PHP.

Важливе уточнення: 23 жовтня PHP повідомив про окрему проблему CVE-2026-115560 за рідкісного поєднання налаштувань сесій і коду застосунку. До чергового виправлення розробники рекомендують session.upload_progress.enabled=0. Це окрема рекомендація, яку не скасовують патчі двох початкових CVE.

Що потрібно власникам сайтів і серверів

Клієнтам спільного хостингу варто підтримувати CMS та модулі в актуальному стані. Якщо потрібна перевірка PHP або нових опцій, зверніться до підтримки й зазначте домен. Докладніше про вибір середовища — в нашій інструкції зі зміни версії PHP.

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