# Защо актуализацията на WordPress не помага срещу PHP2Shell

> Защо актуализацията на WordPress не помага срещу PHP уязвимостта PHP2Shell, кой слой е решаващ и какво да проверят вместо това операторите на WordPress.

Източник: https://phpsos.de/bg/blog/warum-wordpress-update-nicht-hilft/  
Актуалност: 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

**Накратко:** Актуализацията на WordPress не помага срещу PHP уязвимостта PHP2Shell, защото грешката не е в WordPress, а в PHP, софтуера на сървъра, който изпълнява WordPress. Според Dr. Web затова WordPress.org не планира и собствена актуализация. Защитава само PHP актуализация на сървъра с рестарт на всички PHP процеси. Тя по правило се инсталира от Вашия хостинг доставчик или оператор на сървъра.

## Поводът: „Нали актуализирахме всичко“

След първите заглавия за PHP2Shell много оператори направиха очевидното: отвориха таблото на WordPress, натиснаха „Актуализирай сега“, а заедно с това и добавките и темите. След това всичко е зелено и усещането казва: готово.

При тази уязвимост усещането лъже. Това не е заради WordPress, а заради мястото, където е грешката. И Cloudflare в съобщението си посочва, че актуализация на кода на приложението или на добавките не отстранява уязвимостите.

## Актуализация на WordPress и PHP уязвимост: моделът на слоевете

Един уебсайт на WordPress се състои от няколко слоя, които се надграждат един върху друг. Всеки слой има собствени актуализации и често собствени отговорници:

| Слой | Пример | Кой типично актуализира | Засегнат ли е от PHP2Shell? |
|---|---|---|---|
| Операционна система | Debian, Ubuntu, AlmaLinux | хостинг доставчик или администратор на сървъра | не, но често доставя PHP пакета |
| Уеб сървър | Apache, Nginx, LiteSpeed | хостинг доставчик или администратор на сървъра | режимът на работа влияе на риска |
| PHP среда за изпълнение | PHP-FPM, mod_php | хостинг доставчик или администратор на сървъра | да, тук е уязвимостта |
| Ядро на WordPress | WordPress | оператор или агенция | не |
| Добавки и теми | WooCommerce, Page-Builder | оператор или агенция | не |

Бутонът за актуализация в таблото достига само долните два реда. PHP средата за изпълнение е под тях и за WordPress е невидима. Как други системи се надграждат върху PHP, описва статията [CMS и магазини върху PHP](https://phpsos.de/bg/php/cms-und-shops-auf-php/).

## Защо WordPress не може да затвори уязвимостта

Може да се помисли, че WordPress може да „програмира около проблема“. При PHP2Shell това не работи по две причини.

Първо, и двете грешки са в начина, по който PHP обработва заявките и след това почиства. Това се случва независимо коя програма работи в PHP. Второ, PHP екипът е показал за Apache с mod_php експлойт, който действа, преди изобщо да се изпълни код на приложението. WordPress, добавките му и всяка добавка за сигурност тогава изобщо не стигат до изпълнение.

По същата причина не помага и никаква „добавка за заздравяване“, която променя настройки чрез `ini_set()`. php.net изрично съветва временните мерки да не се задават по този начин.

### А при управляван WordPress?

При предложения за управляван WordPress доставчикът често се грижи не само за актуализациите на WordPress, но и за сървъра под него. За PHP2Shell това е предимство, но не автоматизъм. Питайте конкретно дали PHP актуализацията е инсталирана и всички PHP процеси са рестартирани. Твърдението „Поддържаме Вашия WordPress актуален“ не отговаря на този въпрос.

### Много уебсайтове, една PHP инсталация

Агенциите и фирмите с няколко уебсайта трябва да знаят една особеност: на един сървър често много инсталации на WordPress споделят една и съща PHP версия. Ако тя е непачната, всички са засегнати, независимо колко добре е поддържан всеки отделен уебсайт. Обратно, една PHP актуализация защитава всички инсталации наведнъж, при условие че след това всички принадлежащи PHP процеси са рестартирани. Който работи с няколко PHP версии паралелно, трябва да актуализира всяка поотделно.

> **Важно:**
> Зелено табло на WordPress не казва нищо за PHP2Shell. Решаващо е състоянието на пача на PHP на сървъра и рестартът на всички PHP процеси.

## Как да прочетете правилно PHP версията в WordPress

WordPress показва PHP версията: в таблото под Инструменти, Състояние на сайта, в раздела Информация при секцията Сървър. Това е добра първа индикация, но не е доказателство.

Ако там стои клон като 8.1 или по-стар, това е ясен предупредителен сигнал, защото за него вече няма официални актуализации. Ако там стои 8.2.35, 8.3.36, 8.4.27 или 8.5.12, поправеното състояние е инсталирано. Ако там стои по-стар номер на поддържан клон, въпреки това може да е инсталиран backport. Дистрибуциите и хостинг доставчиците при това често не променят номера. Яснота дава само потвърждението на хостинг доставчика или поглед в changelog-а на пакета. Как се прави това, пише в [Проверка на PHP версията и състоянието на пача](https://phpsos.de/bg/php2shell/php-version-pruefen/).

## Какво да направят вместо това операторите на WordPress

1. **Питайте хостинг доставчика или оператора на сървъра:** PHP пачнат ли е, кога и рестартирани ли са всички PHP процеси? Отговор писмено.
2. **Проверете PHP клона:** Ако уебсайтът работи на 8.1 или по-стар, планирайте преминаване към поддържан клон. Коя версия поддържа Вашата версия на WordPress, пише в системните изисквания на wordpress.org. Смяната в клиентското меню описва [Смяна на PHP версията в клиентската зона на хостинга](https://phpsos.de/bg/blog/php-version-hosting-aendern/).
3. **Проверете за следи:** нови PHP файлове в `wp-content/uploads`, непознати администраторски акаунти, чужди записи в `mu-plugins`. Типичните скривалища описва страницата [WordPress и PHP2Shell](https://phpsos.de/bg/plattformen/wordpress/).
4. **Въпреки това поддържайте WordPress актуален:** Ядрото, добавките и темите затварят други уязвимости. Това остава задължение, само че друго.
5. **Изяснете отговорността:** Ако агенция поддържа уебсайта, запишете дали тя отговаря и за PHP, или само за WordPress.

Именно последната точка често създава пролуки. Агенцията поддържа WordPress, хостинг доставчикът сървъра, и всеки вярва, че другият следи PHP2Shell.

## Как помага PHP SOS конкретно?

- **Изясняване на слоевете:** Установяваме кой при Вашия уебсайт на WordPress за кой слой отговаря.
- **Актуализиране на PHP:** На собствени или управлявани сървъри инсталираме PHP актуализацията и рестартираме всички процеси.
- **Проверка на WordPress:** Търсим следи от атака във файловете, базата данни и акаунтите.
- **Доказателство:** Получавате състоянието на пача писмено, също и за предаване на агенция или клиенти.

Процесът описва [услугата за пач на PHP](https://phpsos.de/bg/leistungen/php-patch-service/).

## Заключение

Актуализацията на WordPress е добра поддръжка, но срещу PHP2Shell е грешният слой. Уязвимостта е един етаж по-надолу, в PHP на сървъра. Който разбира това, задава правилния въпрос на правилното място: PHP пачнат ли е, рестартиран ли е и доказано ли е?


## Често задавани въпроси

**Излиза ли актуализация на WordPress за сигурност срещу PHP2Shell?**  
Според Dr. Web WordPress.org не планира актуализация срещу PHP2Shell, защото уязвимостта е в PHP интерпретатора на сървъра. Помага само PHP актуализация от хостинг доставчика или оператора на сървъра.

**Къде виждам PHP версията в WordPress?**  
В таблото под Инструменти, Състояние на сайта, в раздела Информация при секцията Сървър. Показаният номер обаче не казва със сигурност дали пачът е инсталиран, защото хостинг доставчиците често вграждат поправките като backport без нов номер на версията.

**Защитава ли добавка за сигурност от PHP2Shell?**  
Само много ограничено. Една добавка сама работи в PHP и става активна едва след като WordPress е зареден. При Apache с mod_php според PHP екипа е показан експлойт още преди изобщо да се изпълни кодът на приложението. Там добавката не може да се намеси.

**Да актуализирам ли WordPress въпреки това?**  
Да. Актуалните версии на WordPress, темите и добавките затварят други уязвимости и са част от добрата поддръжка. Те просто не решават проблема PHP2Shell.

## Източници

- [Dr. Web: PHP2Shell, актуализация на PHP версиите](https://www.drweb.de/php2shell-update-php-versionen/)
- [php.net: Съобщения за сигурност](https://www.php.net/)
- [WordPress.org](https://wordpress.org/)
- [Блог на Cloudflare: Cloudflare deploys protections against php2shell vulnerability](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/)