21 жовтня 2026 року команда PHP випустила термінові оновлення для двох критичних вразливостей віддаленого виконання коду (RCE), що отримали загальну назву PHP2Shell. Вразливості CVE-2026-109618 і CVE-2026-109619 знаходяться в самому рушії PHP, а не в будь-якому застосунку, тому вразливий будь-який сервер, що обробляє веб-запити через PHP — включно з PHP-FPM, Apache mod_php, php-cgi, FrankenPHP і LiteSpeed. Обидві вразливості оцінені в 9,2 бала за CVSS v4.0 і дозволяють неавтентифікованому зловмиснику виконати довільний код. Виправлення доступні у версіях PHP 8.5.12, 8.4.27, 8.3.36 і 8.2.35 — оновлення рантайму є єдиним повноцінним рішенням.
Технічні деталі вразливостей
Обидві вразливості належать до класу Use After Free (CWE-416), але експлуатують різні механізми всередині PHP.
CVE-2026-109618 — RCE через пошкодження пам’яті під час обробки помилки нестачі пам’яті (OOM). Згідно з офіційним бюлетенем безпеки, PHP використовує longjmp() для обробки OOM-помилок, і в певних контекстах запит може бути перерваний, коли внутрішні дані ще не повністю ініціалізовані. При цьому процедура завершення запиту обробляє невалідні дані як коректні. У конфігурації Apache mod_php це особливо небезпечно: процедура shutdown викликається безумовно навіть у разі невдалого старту запиту, а автоматичний парсинг тіла запиту може вичерпати ліміт пам’яті до того, як почне виконуватися код застосунку.
CVE-2026-109619 — RCE через застарілий глобальний стан. Як зазначено в бюлетені безпеки, внутрішній стан, що належить запиту, може зберегтися після звільнення пам’яті. Наступний запит, оброблений тим самим воркером, може використати цей застарілий стан до того, як штатна ініціалізація його скине. Підтверджене виконання коду через шлях fatal backtrace на mod_php і через життєвий цикл сесій як на mod_php, так і на PHP-FPM.
Окрім виконання коду, зловмисник може читати пам’ять робочого процесу PHP, яка може містити паролі, токени автентифікації, ключі API й сертифікати інших запитів — без попереднього отримання RCE.
Зачеплені версії та конфігурації
Уразливі всі версії PHP нижче 8.2.35, 8.3.36, 8.4.27 і 8.5.12. Уразливий код присутній у PHP понад десять років, зачіпаючи версії аж до PHP 5.4. PHP виділяє Apache mod_php як конфігурацію з найвищим підтвердженим ризиком: для CVE-2026-109618 продемонстровано експлойт, що спрацьовує до виконання будь-якого коду застосунку. PHP-FPM також піддається атаці: для CVE-2026-109619 підтверджено шлях експлуатації через життєвий цикл сесій.
Реакція галузі
Ще до виходу патчів Cloudflare, за даними CTO компанії Дейна Кнехта, зафіксувала ранні спроби експлуатації й розгорнула термінові правила WAF, назвавши їх тимчасовим заходом. При цьому жодне джерело не підтвердило успішного зламу. Компанія watchTowr, що відтворювала CVE-2026-109618, станом на 11:26 UTC 21 жовтня не зафіксувала експлуатації в дикій природі. За даними Huntress, публічний код експлойта на момент публікації їхнього звіту також не був доступний.
Низка організацій превентивно вимкнула сервіси. BambooHR призупинила роботу у США, Канаді та Ірландії, попередивши про перебої в обробці зарплат. У Нідерландах були відключені державні портали MijnOverheid, DigiD, сайт нижньої палати парламенту, національний центр кібербезпеки та низка освітніх систем.
Чому налаштування session.upload_progress.enabled — не захист
До виходу патчів у спільноті активно поширювалася рекомендація встановити session.upload_progress.enabled=0 як тимчасове рішення. Токійська компанія GMO Flatt Security спершу запропонувала цей захід, але згодом відкликала рекомендацію, заявивши, що налаштування саме по собі не є повноцінним виправленням і очікуються способи його обходу.
Розробниця ядра PHP Джина Пітер Банярд написала прямо: «Єдине, що я можу сказати — єдиний захід захисту — це оновлення PHP. На жаль, я знаю занадто багато».
Опубліковані бюлетені безпеки підтвердили: вимкнення session.upload_progress.enabled блокує лише підтверджені шляхи експлуатації CVE-2026-109619 через сесії, але не охоплює інші варіанти й жодним чином не впливає на CVE-2026-109618. Компанія watchTowr оцінює зміни INI-файлів як неефективні для запобігання експлуатації.
Рекомендації щодо оновлення та тимчасових заходів
Оновлення рантайму PHP — єдине повноцінне рішення. Необхідно оновити саме той PHP, який обслуговує веб-запити (PHP-FPM, mod_php або CGI), а потім перезапустити Apache, PHP-FPM і всі довгоживучі воркери. Оновлення застосунків (WordPress, Laravel тощо) не оновлює PHP-рантайм.
Якщо негайне оновлення неможливе, згідно з офіційним бюлетенем безпеки PHP, такі заходи знижують ризик за конкретними шляхами атаки, але не роблять сервер безпечним:
- Для CVE-2026-109618: встановити
memory_limit=-1так, щоб застосунки не могли перевизначити значення; триматиpost_max_sizeнизьким; застосувати обмеження розміру запитів на рівні веб-сервера або проксі. PHP попереджає: не використовуйте RLIMIT_AS або RLIMIT_DATA як заміну — вони можуть активувати той самий уразливий шлях. - Для CVE-2026-109619: встановити
session.upload_progress.enabled=0і перезапустити всі воркери; на PHP 8.5 додатково встановитиfatal_error_backtraces=0. - Ізоляція: CERT-EU рекомендує розглянути ізоляцію інтернет-доступних PHP-застосунків від публічних мереж до встановлення патча — через VPN, списки дозволених клієнтів або автентифікацію на периметрі.
- Мінімізація наслідків компрометації: скоротити обсяг даних на сервері, прибрати збережені облікові дані й хмарні ролі, знизити привілеї, забезпечити ведення логів у захищеному сховищі.
Непідтримувані версії PHP
PHP 8.1 і старші не отримують оновлень від проєкту PHP. Однак, з огляду на критичність вразливостей, команда безпеки PHP опублікувала мінімальні бекпорти вихідного коду для PHP 7.4, 8.0 і 8.1. Дистрибутиви Linux і LTS-вендори можуть надати власні виправлення — перевіряйте changelog пакета на наявність CVE, а не номер версії, як рекомендує Debian.
Виявлення та моніторинг
За рекомендацією Huntress, експлуатація подібних вразливостей найчастіше проявляється як підозрілі дочірні процеси, породжені PHP-воркерами — оболонки, інтерпретатори, утиліти завантаження та команди розвідки. Ці індикатори є загальними ознаками компрометації PHP, а не специфічними для PHP2Shell.
Дослідники, які виявили вразливості, рекомендують після оновлення перевірити логи на наявність: незвичних multipart-запитів, що супроводжуються помилками ліміту пам’яті або повторюваними HTTP 500; аномально великих cookie PHPSESSID у відповідях; незрозумілих перезапусків PHP-воркерів.
PHP2Shell — рідкісний випадок, коли вразливість зачіпає не конкретний застосунок, а сам мовний рантайм, роблячи вразливим навіть сервер із найпростішою сторінкою. Пріоритет оновлення максимальний: у першу чергу — сервери з Apache mod_php, далі — PHP-FPM. Для непідтримуваних версій — застосувати бекпорти або ізолювати сервери від інтернету. WAF-правила й зміни конфігурації знижують ризик за окремими шляхами, але не замінюють патч.
