PHP2Shell: Чому організації повинні негайно усунути критичні вразливості PHP 

● CVE-2026-109618 пов’язана з пошкодженням пам’яті під час обробки ситуацій з нестачею пам'яті. Зловмисник може використовувати спеціально сформовані завантаження, щоб перервати запит у момент, коли внутрішні дані запиту ініціалізовані лише частково. Ця перерва спричиняє некоректне очищення пам'яті, через що недійсні дані можуть оброблятися як валідні. 

21 жовтня 2026 року проєкт PHP випустив екстрені оновлення. Організаціям слід оновитися до однієї з наступних версій: ● PHP 8.5.12 ● PHP 8.4.27 ● PHP 8.3.36 ● PHP 8.2.35 (підтримка завершується 31 грудня) 
Попередні релізи у цих гілках також є вразливими. PHP 8.1 та старіші версії більше не отримують регулярних оновлень від PHP. Деякі дистрибутиви Linux та вендори з довгостроковою підтримкою (LTS) можуть надавати виправлення, адаптовані для старих версій, а команда безпеки PHP оприлюднила мінімальні адаптації вихідного коду для PHP 7.4, 8.0 та 8.1. Організаціям, які використовують застарілі гілки, слід підтвердити наявність підтримки у свого вендора та спланувати міграцію на підтримувану версію, замість того щоб припускати, що застаріла інсталяція захищена. 
Інвентаризація не повинна обмежуватися лише тими серверами, де адміністратори свідомо встановлювали PHP. Сторонні додатки, контейнери, мережеві пристрої, інтерфейси управління та мережеві продукти можуть містити власне середовище виконання PHP. Ці компоненти можуть вимагати оновлення від конкретного виробника, а не прямого апгрейду PHP. NCSC-NL створив оперативне сховище для допомоги в ідентифікації потенційно вразливого ПЗ, хоча й попереджає, що цей перелік залишається неповним. 

Офіційне повідомлення PHP містить кроки для зменшення ризиків у випадках, коли організація не може оновитися негайно. Вони включають зміни обмежень пам'яті та завантажень, вимкнення session.upload_progress, перезапуск усіх робочих процесів та налаштування параметра трасування для PHP 8.5. 
Ці заходи нейтралізують відомі вектори атак, але не усувають самі вразливості. PHP наголошує, що єдиним повноцінним рішенням є встановлення оновлення. CERT-EU радить організаціям, які не можуть оперативно застосувати патч, розглянути можливість ізоляції публічних додатків від зовнішніх мереж до моменту застосування та перевірки виправлення. 

Команди безпеки не повинні припускати, що застосування оновлення автоматично повертає систему до безпечного стану. Публічні технічні деталі та концептуальні докази збільшують ймовірність швидкого сканування та зловживання вразливостями. CERT-EU 21 жовтня попередив про початок циркуляції перших концепцій атак (PoC). 
Після встановлення патча команди мають переконатися, що всі PHP-процеси та контейнери перезапустилися на виправленій збірці. Необхідно проаналізувати телеметрію вебсервера, зворотного проксі-сервера, додатка, кінцевих точок та мережі на наявність підозрілої активності, що передувала усуненню вразливості. 
Під час розслідування слід шукати:

У разі підозри на компрометацію ізолюйте вразливу систему, збережіть докази, змініть компрометовані облікові дані та за потреби відновіть систему на основі надійної базової конфігурації.