CVE-2026-115560: Нова незакрита уразливість PHP RCE вимагає негайних заходів

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

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

Нова вразливість також важлива, оскільки встановлення PHP 8.5.12, 8.4.27, 8.3.36 або 8.2.35 — релізи, що виправили дві попередні уразливості PHP2Shell — не not усуває CVE-2026-115560. Повністю оновлені системи можуть залишатися вразливими, якщо їхні додатки відповідають специфічним передумовам конфігурації.

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

AI-Нативна Платформа Виявлення Інтелекту SOC Prime дозволяє командам безпеки посилювати покриття для експлуатації нових уразливостей та пов’язаної поведінки після компромісу в середовищах SIEM, EDR та Data Lake.

Натисніть Дослідити Виявлення щоб отримати доступ до відповідного контенту виявлення та логіки полювання. Для виявлення CVE-2026-115560 захисники повинні поєднувати оцінку конфігурації PHP з веб, кінцевою точкою, додатком та телеметрією зворотного проксі, поки патч від постачальника буде недоступним.

Фахівці з безпеки також можуть використовувати Prime Architect для перетворення щойно відкритої інтелектуальності про уразливість у правила Sigma та запити полювання, перевірки логіки виявлення та перекладу відповідних виявлень на підтримувані платформи безпеки.

Зв’язатися з Відділом Продаж

Аналіз CVE-2026-115560

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

За даними команди безпеки PHP, додаток повинен задовольнити кілька специфічних умов, перш ніж проблема може виникнути:

• session.serialize_handler спочатку має бути налаштовано як php_binary або php_serialize.
• Код додатка повинен згодом змінити обробник на php під час виконання за допомогою ini_set().
• Ця зміна повинна відбутися до виклику session_start().
• session.upload_progress.enabled має залишатися увімкненою.

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

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

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

Виходячи з викладених умов, уразливість виглядає, пов’язаною з неконсистентною обробкою даних сесії, коли приклад змінює формати серіалізації під час обробки запитів, поки механізм прогресу завантаження PHP активний. Однак точний експлуатаційний примітив не повинен виводитися за межі того, що PHP формально розкрив.

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

Це означає, що адміністратори не повинні визначати вплив виключно за встановленою версією PHP. Натомість вони повинні оцінити конфігурацію додатків та сервера.

Корисним першим кроком є перевірка, чи включено прогрес завантаження сесії:

session.upload_progress.enabled=1

Адміністраторам слід також визначити будь-який код додатка, що викликає ini_set() для зміни session.serialize_handler, особливо переходи з php_binary або php_serialize на php.

Нова уразливість відрізняється від CVE-2026-109619, хоча зменшення ризику перекривається. Вимкнення прогресу завантаження сесії вже рекомендувалося як захід зменшення ризику для однієї з оригінальних вразливостей PHP2Shell. Організації, які залишили цю опцію вимкненою після екстреного оновлення 21 жовтня, вже захищені від нововиявленого шляху, за словами PHP.

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

Це помітно відрізняється від попередніх уразливостей PHP2Shell, для яких виникли різні спроби докази концепції та діяльність з експлуатації навколо розкриття. Ці атаки не слід приписувати новій уразливості.

За станом на 26 жовтня 2026 року, ніяких експлуатаційних зусиль щодо CVE-2026-115560 не було повідомлено. The Hacker News спеціально відрізняє триваюче сканування PHP2Shell і спроби експлуатації від цієї нової уразливості, зазначаючи, що спостережувана діяльність націлена на CVE-2026-109618 та CVE-2026-109619.

Як результат, IOCs CVE-2026-115560, такі як шкідливі IP-адреси, домени, хеші, корисні навантаження або підтверджені шаблони запитів експлойту, в даному часі недоступні.

Поки не з’являться більш технічні деталі, захисники повинні зосередитися на поведінкових та конфігураційних індикаторах, включаючи:

• PHP додатки, що змінюють session.serialize_handler під час виконання
• Прогрес завантаження сесії залишається увімкненим на додатках з кастомною логікою сесій
• Неочікуваний багаточастинний трафік POST до додатків, що обробляють сесії PHP
• PHP-FPM, php-cgi, Apache або інші процеси, що обслуговують PHP, породжують оболонки чи інтерпретатори сценаріїв
• Несподівані вихідні мережеві з’єднання від працівників PHP
• Нещодавно створені файли в коренях веб або в каталогах, до яких дозволено запис
• Незвичайні зміни в файлах сесій або сховищах сесій
• Веб-шелли, заплановані завдання чи несанкціоноване продовження, створене обліковими записами сервісів PHP

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

Розкриття відбувається під час вже активного періоду діяльності з експлуатації PHP. Оригінальні вразливості PHP2Shell були виправлені 21 жовтня, і декілька компаній з безпеки згодом спостерігали широке сканування та спроби експлуатації. Проте PHP та дослідники безпеки не пов’язують ці кампанії із CVE-2026-115560.

Пом’якшення CVE-2026-115560

PHP наразі рекомендує один прямий захисний захід:

session.upload_progress.enabled=0

Адміністраторам слід застосувати установку через php.ini, конфігурацію пулу PHP-FPM, конфігурацію Apache або інший серверний механізм, який набирає чинності до обробки запитів.

Організації, які вимкнули цю функцію під час зменшення ризику CVE-2026-109619 та залишили її вимкненою, не потребують додаткової зміни конфігурації для цієї уразливості.

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

Адміністратори можуть перевірити ефективне налаштування через інспекцію конфігурації PHP замість того, щоб припускати, що центральне значення php.ini застосовується скрізь. Розгортання PHP часто поєднують налаштування з:

• Глобальний php.ini
• файли conf.d
• конфігурація пулу PHP-FPM
• директиви Apache
• конфігурація специфічна для контейнера
• Файли .user.ini на рівні додатка
• виклики до ini_set() в час виконання

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

ini_set(‘session.serialize_handler’, ‘php’)

Додатки, які ніколи не змінюють серіалізатор з php_binary або php_serialize на php до session_start(), не підпадають під уразливу ситуацію, яку розкрив PHP.

Незважаючи на це, організаціям слід зберегти оновлення безпеки PHP2Shell від 21 жовтня. Вимкнення прогресу завантаження вирішує нововиявлений шлях, але не замінює термінові виправлення для CVE-2026-109618 та CVE-2026-109619.

Тому підтримувані інсталяції повинні залишатися принаймні на:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

Ці випуски виправляють попередні проблеми PHP2Shell, але не нововиявлену уразливість.

Команди безпеки також повинні інвентаризувати непідтримувані інсталяції PHP. PHP 8.1 та більш ранні випуски вже не отримують регулярні upstream-оновлення безпеки, що означає, що організації, що працюють у застарілих середовищах, можуть мати труднощі з визначенням повної експозиції після оприлюднення остаточного консультативного звіту CVE.

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

Як додаткові запобіжні заходи, захисники можуть:

• Обмежте зовнішній доступ до чутливих застосунків PHP.
• Застосуйте обмежувальні правила зворотного проксі для непотрібних кінцевих точок завантаження файлів.
• Моніторте багаточастинні запити, пов’язані з сесіями PHP.
• Сповіщайте про аномальні дочірні процеси працівників PHP.
• Застосуйте найменше привілей до облікових записів PHP-FPM та веб-сервера.
• Запобігайте запису сервісами PHP в каталоги, що виконуються, де це можливо.
• Обмежте вихідну підключення з навантажень веб-додатків.
• Моніторте веб-корені та тимчасові каталоги на наявність несанкціонованого створення файлів.

AWS також зазначив, що його правила WAF PHP для додатків можуть блокувати POST-запити, що поєднують ідентифікатори сесій PHP з полем PHP_SESSION_UPLOAD_PROGRESS, забезпечуючи ще один захисний шар для середовищ, які не можуть одразу внести зміни в конфігурацію. Такий тип фільтрації все ще слід вважати захистом в глибину, а не заміною рекомендуваної PHP зміни конфігурації.

Як тільки PHP випустить регулярне оновлення з виправленням постійної проблеми, організації повинні негайно розгорнути його, навіть якщо тимчасове зменшення ризику вже увімкнено.

Після патчінгу адміністратори можуть вирішити, чи потрібно знову вмикати прогрес завантаження сесій, виходячи з вимог додатку.

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

Оскільки успішна експлуатація може потенційно призвести до виконання коду з привілеями працівника PHP, респонденти повинні змінити відповідні облікові дані додатка, секрети бази даних, токени API, ключі хмари та іншу конфіденційну інформацію, якщо компрометацію неможливо вилучити з розгляду.

Відмова від відповідальності: Зміст виявлення може бути недоступним для кожного CVE. Перевірте платформу SOC Prime на наявність поточного покриття. Якщо відповідні виявлення ще не доступні, перевірте знову, оскільки нові розвідки загроз а також контент виявлення постійно додаються.