Накратко: Уязвимостите в PHP се докладват поверително, за предпочитане през частния формуляр за advisory в GitHub хранилището php/php-src, алтернативно на security@php.net. Разработчиците на PHP оценяват находката като висока, средна или ниска; тежките грешки се коригират в отделно хранилище за сигурност и се публикуват едва с изданието, заедно с GitHub Security Advisory и най-често с номер CVE. При PHP2Shell този процес протече с ускорено темпо: предварително съобщение на 20.10.2026 г., пачове на 21.10.2026 г., допълнителна бележка на 23.10.2026 г.
Кой се грижи за сигурността в PHP?
PHP е проект с отворен код. Политиката за сигурност в wiki го описва като проект на доброволци без бюджет за награди. За всяка версия има release мениджъри, които отговарят за публикуванията. Към това се добавя PHP Foundation, която според собственото си представяне наема екип от разработчици на непълно и на пълно работно време, работещи по поддръжката, сигурността и новите функции на PHP.
За фирмите това означава: няма производител с договор, горещ телефон или гарантирани времена за реакция. Който се нуждае от обвързващи ангажименти, получава ги от своята Linux дистрибуция, от своя хостинг доставчик или от доставчик на дългосрочна поддръжка, а не от самия проект PHP. Тази верига на доставка трябва да я познавате.
Как се докладва уязвимост
Пътят е описан в политиката за сигурност в GitHub:
- Докладване: през частния формуляр за Security Advisories в хранилището
php/php-src. Който не може да го използва или иска да обсъди тема, която не е доклад за грешка, пише на security@php.net. - Кратко описание: Желан е кратък пример, който показва грешката, а не дълъг доклад за възможните последици. Така екипът може да прегледа по-бързо.
- Поверителност: Докладът остава частен до публикуването.
- Посочване: Докладчиците се посочват като участници по системата за признания (credit) на MITRE.
По-старата страница на wiki допълнително назовава класическия tracker за грешки с тип „Security“. Днес меродавен е пътят през GitHub.
Какво проектът PHP счита за уязвимост
Не всеки срив е уязвимост. Wiki назовава четири критерия: грешката позволява неоторизирани действия, надхвърля граници на сигурността, отваря достъп до чужди данни или сериозно затруднява достъпността или производителността. Оценката е по три степени:
| Степен | Значение според политиката | Номер CVE |
|---|---|---|
| Висока | трети лица могат да компрометират повечето инсталации, да изпълняват код или да четат файлове | по правило да |
| Средна | подобно въздействие, но само при по-редки условия, например рядко разширение или конфигурация | най-често да |
| Ниска | теоретично възможна, практически много трудна за експлоатация | най-често не |
Също толкова показателен е списъкът с онова, което изрично не е уязвимост: злонамерен код, който се изпълнява нарочно, заобикаляне на open_basedir и disable_functions, злонамерени входни данни към unserialize(), използването на FFI и обикновено прекъсване поради памет, при което memory_limit действа и приключва само текущата заявка. За операторите това означава: disable_functions е разумно заздравяване, но не защитна стена.
От корекцията до публикуването
Корекциите за високи и средни уязвимости според wiki се внасят в отделно хранилище за сигурност, преди да се създаде изданието. Грешките с ниска оценка преминават като обикновени корекции на грешки. Уязвимостта се публикува по принципа на отговорното разкриване: първо корекцията, после подробностите. Изданията според wiki излизат най-често в четвъртък, често в рамките на редовните месечни публикации.
С изданието излиза GitHub Security Advisory със собствен идентификатор (GHSA) и степен на тежест. В хранилището например на 24.09.2026 г. излязоха няколко advisory за stream wrappers, FastCGI и филтри със степени на тежест от ниска до висока. Пакетите с изходен код на php.net се предлагат със SHA-256 контролни суми и GPG подписи на release мениджърите; git таговете са подписани. Кои клонове на версиите изобщо още получават корекции за сигурност, показва страницата за версиите на PHP и жизнения цикъл на изданията.
PHP2Shell като пример за критичен случай
PHP2Shell показва как протича процесът под натиск:
- 20.10.2026 г.: php.net обявява критично издание за сигурност за 21.10.2026 г. в 14:00 UTC и си запазва правото да публикува по-рано, ако подробностите станат публични или се появят атаки. Според няколко доклада подробностите наистина са станали известни преди изтичането на срока на ембаргото; предисторията осветлява Защо уязвимостта на PHP стана известна преди пача.
- 21.10.2026 г.: излизат PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35, заедно с advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618) и GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), и двете оценени като критични. Според php.net Linux дистрибуциите и доставчиците на дългосрочна поддръжка са получили корекциите предварително. За 7.4, 8.0 и 8.1 има минимални backport.
- 23.10.2026 г.: Информативна бележка за CVE-2026-115560 препоръчва
session.upload_progress.enabled=0; пълното advisory следва със следващото издание.
Какво следва за операторите
- Абониране за източниците: php.net, GitHub advisory на
php/php-srcи съобщенията за сигурност на Вашата дистрибуция. - Познаване на веригата на доставка: Кой доставя Вашия пакет с PHP и колко бързо там пристигат backport?
- Планиране на времеви прозорец: Критичните издания могат да излязат извън обичайния ритъм; прозорец за пач трябва да е възможен в кратък срок.
- Планиране на рестартирането: Актуализацията действа едва когато всички PHP процеси са рестартирани.
- Осигуряване на доказателство: Документирайте версията, състоянието на пакета и момента.
Как помага PHP SOS конкретно?
С услугата за PHP пачове поемаме частта, която е при Вас:
- Следене на съобщенията: Наблюдаваме php.net, advisory и съобщенията на дистрибуциите и преценяваме дали Вашите системи са засегнати.
- Внедряване на пача: Актуализация от подходящия източник, рестартиране на всички процеси, проверка на работещата версия.
- Осигуряване на преходния период: Където актуализацията се бави, прилагаме официалните временни мерки.
- Документиране: Получавате доказателство с версии, състояния на пакетите и моменти.
Често задавани въпроси
Как се докладва уязвимост в PHP?
За предпочитане през частния формуляр за Security Advisories в GitHub хранилището php/php-src. Който не може да го използва, пише на security@php.net. Докладът остава поверителен до публикуването.
Плаща ли проектът PHP награда за намерени уязвимости?
Не. Според политиката за сигурност PHP е проект на доброволци без средства за bug bounty. Докладчиците обаче се посочват като участници.
Заобикалянето на disable_functions уязвимост ли е?
Според политиката на проекта PHP – не. Заобикалянето на open_basedir и disable_functions не се счита за проблем със сигурността на PHP. Настройките са заздравяване, но не и надеждна граница на сигурността.
Къде научавам за нови уязвимости в PHP?
На началната страница на php.net със съобщенията за издания и в Security Advisories на GitHub хранилището php/php-src. Който получава PHP от дистрибуция, следи допълнително и нейните съобщения за сигурност.
Защо PHP2Shell беше публикувана в сряда?
Според wiki изданията излизат най-често в четвъртък. За PHP2Shell php.net обяви на 20.10.2026 г. издание за сигурност за сряда, 21.10.2026 г., 14:00 UTC, и си запази правото да публикува по-рано, ако подробностите станат публични.