Накратко: След PHP2Shell са вероятни още съобщения за PHP, защото още два дни след пача дойде трето указание, пълно съобщение (advisory) още предстои, а дистрибуциите доставят пакетите си на етапи. Който сега изгради твърд процес за наблюдение, оценка, актуализация и рестарт, реагира на следващата нова PHP уязвимост за часове вместо за дни.
Пачът не беше краят на историята
На 21 октомври 2026 г. PHP проектът затвори двете критични уязвимости CVE-2026-109618 и CVE-2026-109619 с версиите 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Много отговорници след това поставиха отметка. Два дни по-късно, на 23 октомври, обаче последва ново указание от php.net за CVE-2026-115560.
Това трето указание засяга само необичайна конфигурация на сесиите. Показва обаче модел, познат от големите случаи на сигурност: когато един компонент внезапно е под светлините на прожекторите, много специалисти едновременно гледат по-внимателно. Дали от това ще възникнат още уязвимости, днес не знае никой. Вероятно е обаче потокът от новини да не секне.
За Вас като оператор това означава: планирайте последващи съобщения, вместо всяко да Ви изненадва. Досегашния ход на събитията обобщава нашата хронология на PHP2Shell.
Защо още съобщения са вероятни
Следната оценка се основава на публично известни факти. Тя не е прогноза за конкретни уязвимости.
- Съобщението (advisory) още предстои. php.net третира CVE-2026-115560 в редовния цикъл на издания и е обявила, че ще публикува пълното съобщение със следващото издание. Дотогава
session.upload_progress.enabled=0се счита за мярка. - Подробностите бяха рано публични. Според няколко съобщения подробности са станали известни преди изтичането на ембаргото. Според съобщенията watchTowr според собствените си данни е възпроизвела CVE-2026-109618. Такива работи често водят до последващи въпроси към съседни части на кода.
- Дистрибуциите доставят на етапи. Ubuntu на 21 октомври снабди актуалните издания с USN-8948-1 и с USN-8948-2 допълнително достави поправки за 14.04 до 20.04 чрез Ubuntu Pro. Red Hat написа в бюлетина си, че някои актуализации са налични, а други са в работа.
- Засегната е и версията в разработка. Според php.net и PHP 8.6.0 RC4 съдържа поправките. Който тества предварителни версии, трябва да допълни и тези среди.
- Старите версии остават отворени. За PHP 8.1 и по-стари има само минимални backport-ове на изходния код. Всеки доставчик, който предлага такива версии, съобщава състоянието си самостоятелно и в собствени срокове.
Как нова PHP уязвимост стига до Вас
Съобщенията идват по различни пътища и с различна надеждност. Редът е почти винаги един и същ: първо PHP проектът, после дистрибуциите и хостинг доставчиците, после институциите и медиите.
| Източник | Какво научавате там | Колко надежден |
|---|---|---|
| php.net | Засегнати клонове, поправени версии, временни мерки | Първичен източник |
| Ubuntu, Debian, Red Hat | Състояние на пакетите за всяко издание, момент на доставка | Първичен източник за Вашата система |
| Хостинг доставчици и доставчици на панели | Състояние на собствените PHP компилации | Обвързващо само ако е писмено |
| BSI, CERT-Bund | Оценка на ситуацията, ниво на предупреждение, препоръки | Оценка от институция |
| Специализирана преса и фирми за сигурност | Наблюдения на атаки, числа, фонови сведения | Полезно, маркирайте като съобщение |
Важна е разликата между „има пач“ и „моята система има пача“. Първото твърдение стои на php.net. Второто трябва да докажете сами за всеки сървър.
Абонирайте се за съобщенията на php.net и на Вашата дистрибуция чрез RSS или пощенски списък и ги насочвайте към обща пощенска кутия или канал, който чете повече от един човек. Отпуската и болестта са най-честите причини за закъснели актуализации.
Какво да подготвите преди следващото съобщение
Опитът от PHP2Shell показва къде се губи време: при търсенето на сървъри, при изясняването на отговорности и при забравения рестарт. Всичко това може да се свърши предварително.
- Инвентар: Списък на всички сървъри и уебсайтове с PHP клон, режим на работа (PHP-FPM, mod_php, LiteSpeed) и източник на пакетите. Без този списък всяко съобщение започва с търсене. Как се постига това, описва статията Инвентар на всички уебсайтове и сървъри.
- Отговорност: За всяка система е определено кой пачва, кой рестартира и кой одобрява. При хостинг доставчици и агенции това принадлежи в договора.
- Решетка за оценка: Три въпроса стигат за първата оценка. Засегнат ли е нашият клон? Ползваме ли засегнатата функция или режим на работа? Има ли пач или само временни мерки?
- Път за тестване: Staging среда, в която PHP актуализация може да се провери за кратко време.
- Доказателство: Устойчив формат, в който се записват състояние на пакета, попадение в changelog и време на рестарта.
Как такъв процес функционира като рутина вместо като пожарна акция, е описано в Управление на пачовете като процес. Основни сведения за отношението на PHP проекта към уязвимостите дава страницата Как PHP проектът обработва уязвимостите в сигурността.
Собствената конфигурация като система за ранно предупреждение
Част от последващите съобщения засягат само определени настройки. CVE-2026-115560 е пример за това: php.net посочва като условие, че приложение променя в хода на изпълнение serializer-а на сесиите, докато upload progress е активен. Приложения, които никога не го правят, според php.net не са засегнати.
Който познава действащата си конфигурация, може по-бързо да оцени такива съобщения. Затова за всеки клон записвайте кои стойности са зададени на сървъра и кои приложения могат да ги презаписват. Простото сравнение на активните настройки вече помага:
# Действащи стойности на командния ред (уеб конфигурацията може да се различава)
php -i | grep -E "session.upload_progress.enabled|session.serialize_handler|memory_limit|post_max_size"
# Зададени стойности в FPM пуловете (пътят е различен според дистрибуцията)
grep -RhE "php_(admin_)?value" /etc/php/*/fpm/pool.d/ 2>/dev/null
Командният ред не показва непременно какво важи в уеб контекста. Яснота носят конфигурацията на пула или на VirtualHost и, за кратко и защитено, страница с phpinfo.
Още едно предимство: който знае кои временни стойности са останали от седмицата на PHP2Shell, може да ги провери съзнателно след следващото редовно издание. Някои настройки, например изключеният upload progress, могат да останат трайно смислени. Други, като много тесни граници за качване, трябва да приведете отново към действителната нужда след уточняване с отделите.
Как помага PHP SOS конкретно?
- Следим съобщенията на php.net, дистрибуциите и BSI и оценяваме новите указания за Вашите конкретни системи.
- Изготвяме с Вас инвентара на всички PHP инсталации и определяме отговорности за всеки сървър.
- В рамките на договор за поддръжка на сигурността инсталираме актуализации, рестартираме всички процеси и документираме състоянието.
- При съобщения без пач задаваме временни мерки така, че да не могат да бъдат презаписвани, и ги проверяваме впоследствие.
Често задавани въпроси
Има ли вече нова PHP уязвимост след PHP2Shell?
На 23 октомври 2026 г. php.net публикува указание за CVE-2026-115560. Изпълнение на код според него е възможно само при необичайна конфигурация на сесиите. Пълно съобщение (advisory) трябва да последва със следващото редовно издание.
Трябва ли да действам веднага след всяко ново съобщение?
Не всяко съобщение изисква същата бързина. Решаващи са степента на тежест, засегнатостта на Вашата конфигурация и въпросът дали има наличен пач. Определен процес помага това да се оцени за минути вместо за дни.
Къде научавам първо за нови PHP уязвимости?
Първичните източници са съобщенията на php.net и указанията за сигурност на Вашата дистрибуция, например Ubuntu Security Notices, Debian Security Tracker или Red Hat. BSI информира чрез предупредителни съобщения. Медийните съобщения са полезни, но често по-късни и по-неточни.
Защо дистрибуциите понякога съобщават с дни по-късно от php.net?
Дистрибуциите трябва да вземат поправката в собствените си пакети, да ги изградят и да ги тестват. За по-старите издания това може да отнеме повече време или да става само чрез допълнителни предложения. Затова си струва двата източника да се следят поотделно.