Накратко: При уязвимост в PHP като PHP2Shell при уеб хостинга за актуализацията на PHP отговаря доставчикът, а не Вие. Вашата задача е да получите писмено потвърждение, да изберете в менюто за клиенти поддържана версия на PHP и да проверите уебсайта си за следи от атака. Пачът на доставчика не премахва зловреден софтуер, попаднал на Вашия уебсайт преди това.
Ситуацията с прости думи
PHP е езикът за програмиране, на който работят повечето уебсайтове, магазини и CMS като WordPress. PHP2Shell означава две критични грешки в самия PHP (CVE-2026-109618 и CVE-2026-109619). Чрез тях нападатели могат без парола да изпълняват собствен код на сървъра. BSI (Федерална служба за информационна сигурност на Германия) обяви ниво на предупреждение 3 (оранжево) и препоръчва незабавна актуализация.
При споделения хостинг много клиенти делят един сървър. Техниката отдолу, т.е. операционната система, уеб сървърът и PHP, се управлява от доставчика. Вие управлявате само своя уебсайт, база данни и достъпи. Затова не можете да внесете актуализацията на PHP сами и не е нужно.
Уеб хостинг и уязвимост в PHP: кой отговаря за какво?
Разпределението следва от Вашия договор. В повечето тарифи важи приблизително следното разпределение:
| Задача | Доставчик | Вие като клиент |
|---|---|---|
| Актуализиране на PHP пакетите | да | не |
| Рестартиране на PHP процесите | да | не |
| Задаване на временни стойности за целия сървър | да | не |
| Избор на версия на PHP за Вашия уебсайт | предоставя | избирате |
| Актуализиране на CMS, добавки, теми | не | да |
| Данни за достъп и администраторски акаунти | не | да |
| Проверка на уебсайта за зловреден код | отчасти | да |
| Оценка по законодателството за защита на данните | не | да |
Важен е последният ред: ако на Вашия уебсайт възникне инцидент с лични данни, по правило отговаряте Вие като оператор, а не доставчикът. Повече по темата има в Задължение за уведомяване по ОРЗД.
Какво да направите сега сами
1. Получете потвърждение. Попитайте доставчика писмено дали версиите на PHP във Вашия пакет са защитени срещу двете CVE, от кога и дали всички PHP процеси са рестартирани. Готов образец ще намерите в Попитайте хостинг доставчика за състоянието на пача. Не се учудвайте, ако в менюто за клиенти продължава да стои по-стар номер на версия като 8.2.34: някои доставчици внасят корекциите като бекпорт, без номерът да се променя.
2. Проверете версията на PHP. Погледнете в менюто за клиенти коя версия на PHP ползва Вашият уебсайт. PHP 8.1 и по-стари вече не получават официални актуализации от проекта PHP. PHP 8.2 достига края на поддръжката на 31.12.2026 г. Дали Вашата CMS поддържа по-нова версия, проверете по системните изисквания на производителя, например на wordpress.org.
3. Прегледайте уебсайта. Обърнете внимание на непознати администраторски акаунти, неочаквани пренасочвания, чужди файлове във FTP достъпа и предупреждения в Google Search Console. Списък с типични признаци има в Вече компрометиран ли съм?.
4. Направете резервно копие. Изтеглете актуално копие на файловете и базата данни и го съхранявайте отделно. Помолете доставчика също да запази протоколите за достъп до Вашия пакет от 20.10.2026 г. нататък.
След потвърждението на доставчика сменете превантивно паролите за менюто за клиенти, FTP/SFTP, базата данни и администраторите на CMS и където е възможно, включете двуфакторното удостоверяване.
Какво не можете да решите сами при споделения хостинг
Временните мерки, препоръчани от php.net, например session.upload_progress.enabled=0, действат само ако са зададени в конфигурацията на сървъра. Запис в .user.ini или чрез ini_set() в кода според php.net не е достатъчен. Ограниченията на паметта на ниво cgroup и рестартът на PHP процесите също са работа на доставчика.
Ако доставчикът не отговаря или отговаря уклончиво, имате три възможности: да настоите и да поставите срок, да преведете уебсайта временно в режим на поддръжка или да преминете към доставчик с ясна позиция. BSI препоръчва уеб сървърите да се изключат временно от мрежата, ако актуализацията не е възможна веднага.
Проверете и дали тарифата Ви е все още актуална. Пакетите, които години наред работят непроменени, понякога са на по-стари поколения сървъри с по-стари версии на PHP, които доставчикът поддържа само ограничено. Преминаването към актуална тарифа на същия доставчик често изисква малко усилия и носи по-нови версии на PHP. Попитайте за това, ако отговорът за състоянието на пача е незадоволителен.
Ако уебсайтът вече изглежда подозрителен
Пачът при доставчика затваря уязвимостта за в бъдеще. Той обаче не премахва задна врата, монтирана от нападателите преди това, и не доказва, че преди това нищо не се е случило. Ако откриете нещо необичайно, не изтривайте файлове на случаен принцип. Първо запазете състоянието, за да остане причината проследима по-късно.
Как помага PHP SOS конкретно?
- Формулираме заедно с Вас запитването до доставчика и оценяваме техническата страна на неговия отговор.
- Проверяваме уебсайта Ви за уеб шелове, чужди акаунти и манипулирани файлове и при находка го почистваме чрез нашето премахване на зловреден софтуер.
- При остро подозрение поемаме спешната помощ за хакнати уебсайтове със запазване на доказателствата.
- Помагаме при избора на подходяща версия на PHP и след това тестваме уебсайта.
Често задавани въпроси
Трябва ли като клиент на хостинг сам да актуализирам PHP?
По правило не, защото при споделения хостинг PHP е част от платформата на доставчика. В менюто за клиенти често обаче можете да изберете версията на PHP. Ако там е зададена версия без официални актуализации, сменете я или попитайте доставчика как я защитава.
Уебсайтът ми е офлайн. Хакнали ли са ме?
Не непременно. Някои доставчици са изключили уебсайтове от мрежата превантивно, за да затворят уязвимостта. Попитайте доставчика за причината и поискайте потвърждение дали има данни за атака срещу Вашия пакет.
Мога ли сам да задам временните мерки в .user.ini?
За session.upload_progress.enabled php.net изрично посочва, че .user.ini и ini_set() не са достатъчни. Тази настройка трябва да бъде зададена от доставчика в конфигурацията на сървъра.
Какво трябва да имам писмено от доставчика?
Потвърждение, че версиите на PHP във Вашия пакет са защитени срещу CVE-2026-109618 и CVE-2026-109619, от кога е така и че PHP процесите са рестартирани. Съхранете този отговор заедно със своите документи.