Екипът по сигурността на PHP предупреди за нова уязвимост за отдалечено изпълнение на код (RCE), идентифицирана като CVE-2026-115560. Рискът засяга приложения с необичайна комбинация от настройки за обработка на сесии. Междувременно опитите за експлоатация на две други критични уязвимости, известни като PHP2Shell, вече са засечени в интернет.

Необичайна комбинация от настройки създава риска

PHP е един от най-широко използваните езици за сървърна уеб разработка. По данни на W3Techs той се използва от близо 70% от уебсайтовете, за които е известна сървърната технология. Оценки на VirusTotal сочат над 5,1 милиона изложени в интернет PHP хоста, като около 3,8 милиона имат поне един отворен порт. Тези числа описват общата експозиция, а не броя на системите, уязвими конкретно към новия дефект.

Според публикуваното на 23 октомври предупреждение на PHP уязвимостта CVE-2026-115560 може да бъде задействана само при специфична последователност от конфигурационни настройки и операции в приложния код.

Необходимо е да са изпълнени едновременно следните условия:

1. Приложението задава session.serialize_handler със стойност php_binary или php_serialize в конфигурацията си.
2. След това променя параметъра по време на изпълнение на php чрез ini_set().
3. Промяната се извършва преди извикването на session_start().
4. Функцията за проследяване на напредъка при качване на файлове чрез сесии остава активирана.

Следователно не е достатъчно само да се използва PHP или да е включено проследяването на качванията. Рискът е свързан с конкретната комбинация от първоначална конфигурация, промяна на обработчика по време на изпълнение и последващо стартиране на сесията.

PHP екипът определя този сценарий като малко вероятен в практиката и планира да публикува пълно техническо предупреждение с предстояща редовна версия. Към момента на оповестяването няма налична корекция за CVE-2026-115560.

Каква е точната последователност в кода

Рисковият модел може да бъде илюстриран със следния опростен пример:

<?php
// Първоначална конфигурация:
// session.serialize_handler = php_binary
// или session.serialize_handler = php_serialize

ini_set('session.serialize_handler', 'php');
session_start();

Примерът показва последователността, описана от PHP, а не самостоятелен експлойт. За да е налице разглежданият сценарий, функцията session.upload_progress също трябва да е активирана.

Това уточнение е важно за администраторите: проверката не бива да се ограничава само до php.ini. Необходимо е да се прегледа и приложният код за динамични промени на session.serialize_handler, включително в компоненти и библиотеки на трети страни.

Временното решение е известно от предходния бюлетин

Докато бъде публикувана корекция, разработчиците препоръчват изключване на функцията за проследяване на напредъка при качване на файлове чрез настройката:

session.upload_progress.enabled = 0

Тя трябва да бъде зададена в конфигурацията на PHP. При PHP-FPM може да се наложи административно налагане на настройката в конфигурацията на съответния пул:

php_admin_flag[session.upload_progress.enabled] = off

След промяната администраторите трябва да проверят дали тя действително се прилага към обслужващите уеб заявки процеси и при необходимост да ги рестартират. Проверка само през PHP CLI не гарантира, че същата стойност е активна и в PHP-FPM или друга производствена среда.

Изключването на функцията може да засегне приложения, които показват напредъка при качване на файлове. Затова е необходимо да се провери дали тя се използва оперативно.

Мярката не е нова: същата настройка вече беше препоръчана във връзка с CVE-2026-109619, една от двете уязвимости PHP2Shell. Ако администраторите вече са я приложили, PHP екипът посочва, че не са необходими допълнителни действия конкретно за CVE-2026-115560.

PHP2Shell вече е обект на атаки

Новото предупреждение идва само два дни след публикуването на спешни корекции за CVE-2026-109618 и CVE-2026-109619, известни общо като PHP2Shell.

Няколко компании за киберсигурност, сред които Cloudflare, watchTowr, Previdian, Hadrian и Patchstack, са регистрирали опити за експлоатация още преди публичното разкриване на уязвимостите. Част от информацията за дефектите и препоръките за ограничаване на риска е изтекла предварително.

Amazon Threat Intelligence съобщи, че опитите за атаки са започнали четири дни преди публикуването на корекциите. Според главния директор по информационна сигурност на AWS CJ Moses използваните полезни товари и инфраструктура за прикриване на произхода са се различавали, което предполага участие на няколко различни участници. Все още не е установено дали някой от тези опити би успял срещу реални системи.

Екипът TRACE на Dataminr също е наблюдавал сканиране, идентифициране на системи и използване на неработещи експлойти след публичното разкриване на PHP2Shell. Към момента на доклада не са били известни потвърдени компрометирания от наблюдаваната активност.

Корекциите за PHP2Shell са публикувани във версии 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Организациите трябва да актуализират засегнатите инсталации, вместо да разчитат единствено на временни конфигурационни мерки.

Какво трябва да направят организациите

За CVE-2026-115560 непосредствената стъпка е изключването на session.upload_progress.enabled, ако това още не е направено. Следва да се проверят конфигурациите и приложният код за описаната последователност с session.serialize_handler.

Отделно трябва да се потвърди, че корекциите за PHP2Shell са инсталирани във всички производствени среди, включително публично достъпни уеб приложения, контейнери и облачни инстанции. Самото актуализиране на CMS или друго уеб приложение не гарантира, че използваната от него PHP среда е коригирана.

Новата уязвимост засега се отличава с ограничен и специфичен сценарий за задействане. Това обаче не отменя необходимостта от реакция: широко използваната сървърна технология, наличието на публично достъпни системи и вече наблюдаваните опити за атаки срещу PHP2Shell правят проверката на конфигурациите и навременното инсталиране на корекции особено важни.