# Опасни погрешни съвети за PHP2Shell, които в момента циркулират

> Съветите за PHP2Shell на проверка: кои циркулиращи препоръки не защитават или дори вредят и какво вместо това съветват php.net, BSI и авторите.

Източник: https://phpsos.de/bg/blog/gefaehrliche-falschtipps/  
Актуалност: 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, които в момента циркулират във форуми и социални мрежи, не защитават или дори вредят: блокиране на заявки със сесийна бисквитка, скриване на съобщения за грешки, задаване на настройки чрез `.user.ini` или актуализиране само на CMS. php.net е категорична: няма пълни временни мерки, а PHP актуализацията с рестарт на всички процеси е единственият сигурен път.

## Защо погрешните съвети са опасни в тази ситуация

При критична уязвимост с голямо внимание възниква пазар за бързи решения. Съветите се споделят, съкращават и препредават, често без ограниченията на първоначалния източник. При PHP2Shell се добавя и това, че подробности според съобщенията са станали известни още преди официалния срок и ситуацията през първите дни беше неясна.

Един погрешен съвет вреди двойно. Оставя уязвимостта отворена и създава усещането, че нещо е направено. Именно това усещане води до това, че същинската актуализация остава неизвършена. Някои съвети допълнително парализират собствения уебсайт.

## Девет съвета на проверка

Следната таблица обобщава какво често четохме през последните дни и противопоставя на това твърденията на първичните източници.

| Циркулиращ съвет | Защо не издържа | Какво важи вместо това |
|---|---|---|
| Блокиране на всички заявки с `PHPSESSID` | Изрично отхвърлен от специализирани автори; парализира влизания и кошници | Актуализирайте PHP |
| `session.upload_progress.enabled=0` стига | Според специализирани доклади не затваря и двете уязвимости | Смислена временна мярка, актуализацията остава задължителна |
| Задаване на стойности чрез `ini_set()` или `.user.ini` | php.net изрично го отсъвква | На ниво сървър в php.ini, FPM пул или конфигурация на сървъра |
| Скриване на съобщенията за грешки | Според php.net `error_reporting`, `display_errors` или `@` не помагат | Актуализация; изходът на грешки въпреки това не се показва публично |
| Ограничаване на паметта чрез `RLIMIT_AS` или `RLIMIT_DATA` | php.net предупреждава, че именно това може да предизвика уязвимата ситуация | Ограничение чрез контейнер или cgroup |
| Актуализиране на WordPress или добавките | Уязвимостта е в PHP интерпретатора, не в CMS | Актуализирайте PHP средата за изпълнение |
| Cloudflare или друг WAF стига | Защита само за трафик през услугата; директно достъпните сървъри остават отворени | WAF като допълнителен слой, не като заместител |
| Презареждане на услугата вместо рестарт | Според Red Hat презареждането не стига, съществуващите worker-и могат да запазят старото състояние | Рестартирайте напълно всички worker-и |
| Пачнато значи чисто | Пачът не премахва зловреден софтуер, внесен преди това | Запазете логове от 20.10. и проверете за следи |

## Трите най-чести заблуди, обяснени по-подробно

### Забраната на бисквитката

Съветът да се отхвърлят всички заявки със сесийната бисквитка `PHPSESSID` звучи технически и решително. Специализираните автори го отхвърлят изрично. На практика той разваля всичко, което се нуждае от сесия: клиентски акаунти, кошници, администраторски зони, формуляри със защита от подправяне. Защита срещу уязвимостта той не е.

### Единствената настройка, която решава всичко

`session.upload_progress.enabled=0` стои в препоръките на php.net и е посочената мярка срещу CVE-2026-115560. В някои статии от това стана „PHP2Shell изключена“. Според специализирани доклади тази настройка сама обаче не затваря и двете уязвимости. И `memory_limit=-1` според php.net премахва само управляемия задействащ фактор; грешка с паметта на по-дълбоко ниво може все пак да достигне уязвимия път. При PHP 8.5 `fatal_error_backtraces=0` според php.net блокира само потвърдения път през backtrace-ове.

Как все пак да зададете настройката правилно и трайно, описва статията [Изключване на session.upload_progress](https://phpsos.de/bg/blog/session-upload-progress-abschalten/). Пълният списък с временни мерки е в [Незабавни мерки без пач](https://phpsos.de/bg/php2shell/sofortmassnahmen-ohne-patch/).

### Щитът отпред

Според собствените си данни Cloudflare има активни правила за защита от 21 октомври, и то за клиенти в безплатния план. Самата Cloudflare обаче посочва граници: защитата действа само за трафик, който минава през Cloudflare. Ако първоизточникът на сървъра е достъпен директно, тя се заобикаля. Освен това Cloudflare допълнително проверява отговора на сървъра, защото заявката сама не винаги стига. Защо WAF не заместава актуализацията, обяснява статията [WAF или актуализация](https://phpsos.de/bg/blog/waf-oder-update/).

## Съвет с риск: филтриране на заявки за качване по периферията

Не всеки неудобен съвет е грешен. Специализираните автори предлагат като временна, неофициална мярка да се блокират заявки `multipart/form-data` извън истинските пътища за качване на прокси или в WAF. Това може да намали повърхността за атака, но разваля формулярите и качванията, ако списъкът с разрешените пътища е непълен.

Който тръгне по този път, трябва да го провери предварително в тестова среда, да го съгласува с отделите и да го документира като срочна мярка. Заместител на актуализацията не е и той.

Много WAF решения предлагат за това режим на наблюдение, в който правилата първоначално само записват вместо да блокират. Оставете ново правило да работи така няколко дни и анализирайте кои легитимни заявки биха били засегнати. Едва след това превключете на блокиране. Така избягвате формуляри за кандидатстване, клиентски портали или качване на снимки в магазина да спрат незабелязано.

## Как да проверите един съвет, преди да го приложите

Четири въпроса отделят използваемите от опасните съвети:

1. **Източник:** Препоръката идва ли от php.net, Вашата дистрибуция, BSI или от поименно назован специализиран автор?
2. **Претенция:** Мярката описана ли е като преход или като решение? При PHP2Shell решение е само актуализацията.
3. **Страничен ефект:** Какво се разваля, когато мярката действа? Съвет без указание за странични ефекти е непълен.
4. **Място на прилагане:** Настройката задава ли се на ниво сървър и така, че да не може да се презаписва, следвана от рестарт на всички worker-и?

> **Важно:**
> Записвайте кои временни мерки кога сте задали. Така по-късно можете целенасочено да ги проверите и да разпознаете дали мнима защита е забавила същинската актуализация.

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

- Проверяваме мерките, които вече са приложени при Вас, и отделяме действените от безполезните.
- Инсталираме PHP актуализацията, рестартираме всички процеси и доказваме състоянието.
- Където актуализация още не е възможна, задаваме временни мерки по php.net на ниво сървър и документирано.
- С [WAF и виртуален пач](https://phpsos.de/bg/leistungen/waf-virtuelles-patching/) допълваме защитата по периферията, без да заместваме актуализацията.


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

**Защитава ли блокирането на заявки с PHPSESSID?**  
Не. Специализираните автори изрично отхвърлят този циркулиращ съвет. Той парализира влизанията, кошниците и формулярите, без да затваря уязвимостта в интерпретатора.

**Стига ли session.upload_progress.enabled=0 срещу PHP2Shell?**  
Не. Настройката е една от няколко временни мерки и според специализирани доклади не затваря и двете уязвимости. Тя е смислена, но не заместава PHP актуализацията.

**Помага ли изключването на display_errors?**  
За PHP2Shell - не. php.net посочва, че скриването на диагностика чрез error_reporting, display_errors или оператора @ не помага. В продукция display_errors все пак трябва да е изключено по други причини.

**По какво разпознавам сериозен съвет?**  
Сериозният съвет посочва източника си, описва границите и назовава временните мерки като такива. Който обещава, че една-единствена настройка прави актуализацията излишна, греши при PHP2Shell.

## Източници

- [php.net: Съобщения за сигурност](https://www.php.net/)
- [Red Hat: CVE-2026-109618](https://access.redhat.com/security/cve/CVE-2026-109618)
- [Dr. Web: PHP2Shell и PHP версиите](https://www.drweb.de/php2shell-update-php-versionen/)
- [Блог на Cloudflare](https://blog.cloudflare.com/)