# Често задавани въпроси за PHP2Shell и спешната помощ

> Отговори на често задавани въпроси за PHP2Shell и отдалечената спешна помощ.

Източник: https://phpsos.de/bg/faq/  
Актуалност: 25.10.2026  
Доставчик: PHP SOS, Спешна помощ за PHP и сигурност на сървъри. Незабавна помощ по WhatsApp: https://wa.me/491736494914?text=%D0%97%D0%B4%D1%80%D0%B0%D0%B2%D0%B5%D0%B9%D1%82%D0%B5%2C%20PHP%20SOS%2C%20%D0%B8%D0%BC%D0%B0%D0%BC%D0%B5%20%D0%BD%D1%83%D0%B6%D0%B4%D0%B0%20%D0%BE%D1%82%20%D0%BF%D0%BE%D0%BC%D0%BE%D1%89%20%D1%81%20%D0%BD%D0%B0%D1%88%D0%B8%D1%8F%20PHP%20%D1%81%D1%8A%D1%80%D0%B2%D1%8A%D1%80.%20%D0%A4%D0%B8%D1%80%D0%BC%D0%B0%3A%20%E2%80%A6%20%D0%A3%D0%B5%D0%B1%D1%81%D0%B0%D0%B9%D1%82%3A%20%E2%80%A6

## Какво е PHP2Shell?

PHP2Shell е името на две критични уязвимости в самия PHP (CVE-2026-109618 и CVE-2026-109619, CVSS 9,2). Те могат да позволят на атакуващи да изпълняват злонамерен код на сървъра без вход в системата. Корекции (пачове) има от 21.10.2026 г.

## Кои версии на PHP са сигурни?

Корекциите са включени в PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Хостинг доставчиците и дистрибуциите понякога внасят backport корекции, без да променят номера на версията. Решаващо е състоянието на пакета или писменото потвърждение от доставчика.

## Достатъчна ли е актуализация на WordPress или на магазина?

Не. Уязвимостта е в PHP, а не в CMS. Актуализацията на CMS не я отстранява. А пачът за PHP не премахва злонамерен код, който вече е бил внедрен преди това.

## Колко бързо можете да помогнете?

Работим отдалечено и започваме, щом получим достъпите. Пишете ни по WhatsApp за системата, версията на PHP и какво сте забелязали. След това веднага уточняваме действията.

## Работите ли и за агенции и клиенти на хостинг доставчици?

Да. Работим директно за фирми, на заден план по поръчка на агенции и в съгласуване с Вашия хостинг доставчик, когато той администрира сървъра.

## Трябва ли да съобщим за инцидента?

Ако може да са засегнати лични данни, по чл. 33 от ОРЗД по правило важи срок за уведомяване от 72 часа от узнаването. Дали този срок се прилага в случая, уточнете със своето длъжностно лице по защита на данните. Ние предоставяме необходимата техническа документация.

## PHP2Shell уязвимост на WordPress ли е?

Не. Уязвимостите са в PHP, т.е. в езика за програмиране, върху който работят WordPress, Shopware, TYPO3 и много други системи. Затова актуализация на CMS не ги затваря. Решаващо е състоянието на PHP на сървъра.

## Трябва ли аз като клиент на хостинг доставчик сам да направя нещо?

При споделен хостинг по правило хостинг доставчикът внася актуализацията на PHP. Все пак трябва да поискате писмено потвърждение, че използваната от Вас PHP версия е пачната и рестартирана. Дали преди пача е станало нещо, актуализацията не показва.

## Откъде идва името PHP2Shell?

Името описва последицата: чрез PHP атакуващият може в най-лошия случай да получи команден ред, т.е. shell, на сървъра. Официалните означения са номерата CVE-2026-109618 и CVE-2026-109619.

## Означава ли изключването на уебсайта ми офлайн, че вече е бил атакуван?

Не непременно. Някои доставчици са изключили уебсайтове от мрежата превантивно, както препоръчва BSI, когато актуализацията не е възможна веднага. Това е защитна мярка, а не доказателство за атака.

## Достатъчно ли е, че хостинг доставчикът ми е актуализирал PHP?

Може да е достатъчно, ако хостинг доставчикът потвърди писмено състоянието на пакета и всички PHP процеси са рестартирани. Показаният номер на версията сам по себе си не е доказателство, защото дистрибуциите внасят backport-ове. Дали сървърът е бил атакуван преди това, пачът така или иначе не показва.

## Трябва ли уебсайтът ми да бъде изключен за спешната помощ?

Не непременно. BSI препоръчва уеб сървърите да се изключват временно от мрежата, когато актуализацията не е възможна веднага. Дали това е нужно при Вас, решаваме заедно след описа.

## Предпазва ли актуализация на WordPress или Shopware от PHP2Shell?

Не. PHP2Shell е в самия PHP, а не в CMS. Актуализацията на CMS остава разумна, но тази уязвимост не затваря.

## Какво се случва при PHP 8.1 или по-стар?

За тези версии проектът PHP вече не издава официални актуализации, а само минимални backport-ове на изходния код за 7.4, 8.0 и 8.1. Защитаваме сървъра временно и заедно с Вас планираме преминаване към поддържана версия.

## От кога тече срокът от 72 часа?

Според чл. 33 от ОРЗД от момента, в който администраторът е узнал за нарушението. Кога може да се приеме това в конкретния случай, е правна преценка. Затова документирайте точно кой кога каква информация е имал.

## Трябва ли да се съобщава за всяка уязвимост в сигурността?

Не. Самата уязвимост още не е нарушение на сигурността на личните данни. Задължение за уведомяване може да възникне, ако има данни, че неоправомощени лица са имали или са могли да имат достъп до такива данни и от това възниква риск за засегнатите лица.

## Какво да направя, ако след 72 часа още не знам всичко?

Чл. 33, пар. 4 от ОРЗД позволява информацията да се предоставя поетапно, ако не може да бъде предоставена едновременно. Забавено уведомление трябва да се обоснове. Изчакването на пълна яснота по правило не е причина да оставите срока да изтече.

## Кой уведомява, ако доставчикът на хостинг е бил засегнат?

Задължен да уведоми е администраторът, т.е. по правило фирмата, която управлява уебсайта. Обработващ лични данни като доставчика на хостинг трябва да информира администратора без забавяне съгласно чл. 33, пар. 2 от ОРЗД.

## Къде да съобщя за нарушение на сигурността на данните?

На компетентния надзорен орган по защита на данните, за фирмите най-често органа на федералната провинция, в която е седалището им. Повечето органи предлагат за това онлайн формуляри.
