PHP попереджає про нову RCE-вразливість CVE-2026-115560 через два дні після екстреного виправлення PHP2Shell

23 жовтня PHP Foundation опублікував інформаційне повідомлення про нову вразливість віддаленого виконання коду — CVE-2026-115560. Проблема з’явилася лише через два дні після екстреного випуску патчів для двох критичних вразливостей PHP2Shell (CVE-2026-109618 і CVE-2026-109619, CVSS 9.2). Нова вразливість зачіпає вебзастосунки з нетиповою конфігурацією обробника сесій і не виправлена раніше випущеними оновленнями. PHP не планує екстреного патча і рекомендує вимкнути функцію session upload progress до наступного планового релізу. Раніше ми вже детально розбирали вразливості PHP2Shell — нова проблема розширює поверхню атаки, хоча й за більш вузьких умов.

Технічні деталі CVE-2026-115560

Вразливість CVE-2026-115560 може призвести до віддаленого виконання коду, але лише за одночасного виконання кількох умов. Застосунок має:

• Встановити параметр session.serialize_handler у значення php_binary або php_serialize у конфігурації;
• Змінити цей параметр на php під час виконання через виклик ini_set();
• Зробити це до виклику session_start();
• При цьому функція session upload progress має залишатися ввімкненою (значення за замовчуванням).

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

Важливо розмежувати масштаб впливу: на відміну від CVE-2026-115560, вразливості PHP2Shell (CVE-2026-109618 і CVE-2026-109619) зачіпають PHP у конфігураціях за замовчуванням і дозволяють неавтентифікованому зловмиснику виконати довільний код. Згідно з бюлетенем GHSA-w8hw-w9fx-j79w, CVE-2026-109618 пов’язана з пошкодженням пам’яті за умов вичерпання ресурсів (CWE-416, use-after-free). CVE-2026-109619, описана в бюлетені GHSA-6wmf-4rv5-p3rp, дозволяє глобальному стану запиту вказувати на звільнену пам’ять і бути використаним наступним запитом того ж робочого процесу. Обидві оцінені PHP Group у 9.2 за CVSS v4.0 і виправлені у версіях PHP 8.5.12, 8.4.27, 8.3.36 і 8.2.35. Версії PHP 8.1 і старші більше не отримують оновлень безпеки від проєкту PHP.

Активність зловмисників

На момент публікації повідомлення спроб експлуатації CVE-2026-115560 не зафіксовано. Однак дві раніше виправлені вразливості PHP2Shell активно скануються. За даними Cloudflare, кількість спроб експлуатації зросла з десятків тисяч у перші 45 хвилин після розкриття 21 жовтня до мільйонів до ранку 22 жовтня. Sophos і Arctic Wolf повідомляли про спроби встановлення варіанту ботнету Mirai через ці вразливості, хоча підтверджених випадків успішного виконання коду зафіксовано не було — побудова надійного експлойта виявилася складнішою, ніж очікувалося.

За даними CYFIRMA, зафіксовано кампанію цілеспрямованого сканування з 21 скомпрометованого вузла, спрямовану на 216 хостів у державному секторі, фінансових організаціях, логістиці, авіації та виробництві в США, Японії, Південній Кореї та інших країнах. Сканування ведеться в режимі «low-and-slow» — невеликими обсягами з ротацією вузлів, що ускладнює виявлення пороговими системами сповіщення. CYFIRMA з помірною впевненістю пов’язує кампанію з корейськомовним оператором, ймовірно афілійованим із екосистемою Lazarus Group, однак цю атрибуцію не підтверджено незалежними джерелами, а масову компрометацію через PHP2Shell не зафіксовано.

Слід зазначити, що Unit 42 (Palo Alto Networks) відкликав свою початкову заяву про те, що атака на європейську урядову установу була пов’язана саме з вразливостями PHP2Shell, — підтвердити цей зв’язок не вдалося. Це важливе уточнення: наразі немає незалежно підтверджених випадків успішної експлуатації PHP2Shell для отримання початкового доступу.

Рекомендації щодо виявлення

Оскільки спостережувана кампанія використовує тактику повільного сканування з ротацією IP-адрес, стандартні порогові правила сповіщення можуть її пропустити. Захисникам доцільно:

• Проводити ретроспективний аналіз журналів вебсерверів і мережевого трафіку за розширений період;
• Відстежувати ланцюжки процесів, породжені робочими процесами PHP (PHP-FPM, mod_php);
• Шукати в логах запити з маркерами PHP_SESSION_UPLOAD_PROGRESS і multipart-завантаження без корисного навантаження;
• Звертати увагу на послідовність: POST-запит із відповіддю 500, помилка вичерпання пам’яті PHP, пошкодження купи та аварійне завершення робочого процесу Apache.

Unit 42 опублікував пошукові запити для виявлення потенційної постексплуатаційної активності в контексті PHP-серверів, а також вхідних спроб експлуатації з використанням multipart-запитів і upload progress.

Практичні рекомендації

1. Оновіть PHP до версій 8.5.12, 8.4.27, 8.3.36 або 8.2.35 — це закриває CVE-2026-109618 і CVE-2026-109619.
2. Вимкніть session upload progress, встановивши session.upload_progress.enabled=0 у конфігурації PHP і перезапустивши всі робочі процеси. Цей захід одночасно пом’якшує CVE-2026-115560 і є рекомендованим тимчасовим рішенням для CVE-2026-109619. PHP попереджає, що вимкнення цього параметра не покриває всі варіанти застарілого стану.
3. Перевірте конфігурацію застосунків: якщо ваш код не перемикає session.serialize_handler під час виконання через ini_set(), ви не піддаєтеся CVE-2026-115560 через цей вектор.
4. Аудит застарілих версій: PHP 8.1 і старші не отримують оновлень безпеки від проєкту PHP. Уточніть у вашого дистрибутива або постачальника LTS-підтримки наявність бекпортованих виправлень.

Оновлення PHP на хості — єдиний повноцінний спосіб усунення вразливостей PHP2Shell. Зміна коду застосунку, оновлення плагінів CMS або правила WAF не замінюють патч рантайму. Організаціям, які вже вимкнули session upload progress після рекомендацій від 21 жовтня, додаткові дії щодо CVE-2026-115560 не потрібні. Тим, хто цього не зробив, слід застосувати це налаштування негайно й запланувати оновлення PHP до найближчого планового релізу, який міститиме повне виправлення.