PHP попереджає про невиправлений ризик RCE у вузькій конфігурації після екстрених патчів PHP2Shell

PHP попередив про ще один спосіб запустити код на сервері через два дні після екстрених виправлень критичних вад PHP2Shell. Нову проблему відстежують як CVE-2026-115560; вона зачіпає лише застосунки з незвичайною конфігурацією. PHP вважає ризик малоймовірним і не випускає екстреного виправлення.

Нова консультація та рекомендоване пом'якшення

Попередження опубліковано 23 жовтня в короткій консультації. PHP радить вимкнути session upload progress до виправлення в наступному плановому випуску. Дія — один рядок: задайте session.upload_progress.enabled=0 до наступного планового випуску з виправленнями.

Це той самий параметр, який PHP уже назвав пом'якшенням у консультації від 21 жовтня для CVE-2026-109619. Хто застосував його тоді й не вимикав, для нової проблеми більше нічого не робить. Функція session upload progress увімкнена за замовчуванням; вона дає застосунку відстежувати перебіг завантаження файлу.

Ризик у вузькій конфігурації

PHP каже, що проблема може виникнути, коли вебзастосунок установлює session.serialize_handler у php_binary або php_serialize, потім у роботі змінює його на php через ini_set() до session_start(). Функція session upload progress також має бути увімкнена.

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

PHP не повідомив, які версії уражені, у яких випусках буде фікс або який бал тяжкості. Не сказав він і чи нова проблема має спільну першопричину з CVE-2026-109619. Про експлуатацію CVE-2026-115560 не повідомлялося.

Раніші вади PHP2Shell та активність атак

Ця проблема з'явилася після екстреного випуску 21 жовтня, який виправив дві критичні вади PHP2Shell, CVE-2026-109618 і CVE-2026-109619, що дозволяли неавтентифікованому зловмиснику виконувати код. Їх виправлено в PHP 8.5.12, 8.4.27, 8.3.36 і 8.2.35. Ця проблема окрема, і ці випуски її не виправляють.

Після 21 жовтня атаки націлені на дві раніші вади PHP2Shell; спроби їх експлуатації різко зросли. Amazon заявила, що honeypots зафіксували спробу експлуатації CVE-2026-109618 і CVE-2026-109619 17 жовтня, за чотири дні до розкриття. Cloudflare заявила, що спроби зросли від десятків тисяч за 45 хвилин після розкриття 21 жовтня до мільйонів до ранку 22 жовтня.

Sophos і Arctic Wolf кажуть, що зловмисники намагалися встановити варіант ботнету Mirai. Спроби поки не вдалися: Previdian, Wordfence та інші бачать сканування й зондування, але не підтверджене виконання коду; надійний експлойт створити складніше, ніж очікували. Ця активність стосується двох вад, виправлених 21 жовтня, а не CVE-2026-115560, щодо якої атак не повідомлялося.

Попередні матеріали: PHP2Shell виправлено: що під загрозою і як захистити сайти на PHP · VulnCheck створила експлойт PHP2Shell, що обходить ASLR у виробничих системах

Джерела: The Hacker News · PHP · CERT-EU