Накратко: Много съвети за 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. Пълният списък с временни мерки е в Незабавни мерки без пач.
Щитът отпред
Според собствените си данни Cloudflare има активни правила за защита от 21 октомври, и то за клиенти в безплатния план. Самата Cloudflare обаче посочва граници: защитата действа само за трафик, който минава през Cloudflare. Ако първоизточникът на сървъра е достъпен директно, тя се заобикаля. Освен това Cloudflare допълнително проверява отговора на сървъра, защото заявката сама не винаги стига. Защо WAF не заместава актуализацията, обяснява статията WAF или актуализация.
Съвет с риск: филтриране на заявки за качване по периферията
Не всеки неудобен съвет е грешен. Специализираните автори предлагат като временна, неофициална мярка да се блокират заявки multipart/form-data извън истинските пътища за качване на прокси или в WAF. Това може да намали повърхността за атака, но разваля формулярите и качванията, ако списъкът с разрешените пътища е непълен.
Който тръгне по този път, трябва да го провери предварително в тестова среда, да го съгласува с отделите и да го документира като срочна мярка. Заместител на актуализацията не е и той.
Много WAF решения предлагат за това режим на наблюдение, в който правилата първоначално само записват вместо да блокират. Оставете ново правило да работи така няколко дни и анализирайте кои легитимни заявки биха били засегнати. Едва след това превключете на блокиране. Така избягвате формуляри за кандидатстване, клиентски портали или качване на снимки в магазина да спрат незабелязано.
Как да проверите един съвет, преди да го приложите
Четири въпроса отделят използваемите от опасните съвети:
- Източник: Препоръката идва ли от php.net, Вашата дистрибуция, BSI или от поименно назован специализиран автор?
- Претенция: Мярката описана ли е като преход или като решение? При PHP2Shell решение е само актуализацията.
- Страничен ефект: Какво се разваля, когато мярката действа? Съвет без указание за странични ефекти е непълен.
- Място на прилагане: Настройката задава ли се на ниво сървър и така, че да не може да се презаписва, следвана от рестарт на всички worker-и?
Записвайте кои временни мерки кога сте задали. Така по-късно можете целенасочено да ги проверите и да разпознаете дали мнима защита е забавила същинската актуализация.
Как помага PHP SOS конкретно?
- Проверяваме мерките, които вече са приложени при Вас, и отделяме действените от безполезните.
- Инсталираме PHP актуализацията, рестартираме всички процеси и доказваме състоянието.
- Където актуализация още не е възможна, задаваме временни мерки по php.net на ниво сървър и документирано.
- С WAF и виртуален пач допълваме защитата по периферията, без да заместваме актуализацията.
Често задавани въпроси
Защитава ли блокирането на заявки с PHPSESSID?
Не. Специализираните автори изрично отхвърлят този циркулиращ съвет. Той парализира влизанията, кошниците и формулярите, без да затваря уязвимостта в интерпретатора.
Стига ли session.upload_progress.enabled=0 срещу PHP2Shell?
Не. Настройката е една от няколко временни мерки и според специализирани доклади не затваря и двете уязвимости. Тя е смислена, но не заместава PHP актуализацията.
Помага ли изключването на display_errors?
За PHP2Shell - не. php.net посочва, че скриването на диагностика чрез error_reporting, display_errors или оператора @ не помага. В продукция display_errors все пак трябва да е изключено по други причини.
По какво разпознавам сериозен съвет?
Сериозният съвет посочва източника си, описва границите и назовава временните мерки като такива. Който обещава, че една-единствена настройка прави актуализацията излишна, греши при PHP2Shell.