Накратко: WAF вместо ъпдейт при PHP2Shell не работи. Web Application Firewall, тоест филтър пред уебсайта, проверява заявките и може да блокира познати модели на атака. Самата уязвимост обаче е в интерпретатора на PHP и изчезва едва с ъпдейта и рестарта на всички PHP процеси. WAF е разумен допълнителен слой и мост за няколко дни, а не решението.
Защо въпросът се задава толкова често именно сега
Много оператори прочетоха през седмицата на PHP2Shell привидно добра новина: Cloudflare според собствените си данни има от 21.10.2026 г., 03:02 UTC, активни защитни правила, и за клиентите на безплатния план. Който така или иначе стои зад Cloudflare или друга WAF, разбираемо се пита дали ъпдейтът тогава още е спешен.
Честният отговор е да. Самият Cloudflare прави уговорка: правила само по данните на заявката не стигат, затова услугата проверява допълнително и отговора на сървъра. Cloudflare наблюдава освен това променени модели на атака. И защитата действа само за трафик, който действително минава през Cloudflare. Подробностите за този доставчик описва Защитните правила на Cloudflare срещу PHP2Shell. Тук става дума за принципната преценка, независимо от доставчика.
Какво вижда WAF и какво променя ъпдейтът
WAF стои пред приложението. Тя вижда всяка заявка, сравнява я с правила и я пропуска, блокира или протоколира. Не знае как PHP обработва заявката вътрешно. Двете уязвимости на PHP2Shell обаче възникват точно там: CVE-2026-109618 при състояние Out-of-Memory, докато данните на заявката са само частично инициализирани, CVE-2026-109619 поради вътрешно състояние, което остава след една заявка в същия worker.
Ъпдейтът поправя този код. След това причината е премахната, независимо как изглежда една заявка. Който иска да разбере на кое място от хода на една заявка се случва това, ще намери основите в Жизнения цикъл на заявката в PHP.
WAF вместо ъпдейт: честното сравнение
| Критерий | Web Application Firewall | Ъпдейт на PHP с рестарт |
|---|---|---|
| Какво се отстранява? | Нищо, познатите модели се улавят | Причината в интерпретатора на PHP |
| Защита при нови варианти на атака | Само ако правилата се адаптират навреме | Да, уязвимостта вече не съществува |
| Възможно ли е заобикаляне? | Да, например чрез директна достъпност на изходния сървър | Не, при условие че всички PHP процеси са рестартирани |
| Скорост | Често активна веднага | Зависи от версията, достъпа и прозореца за поддръжка |
| Странични ефекти | Фалшиви аларми, нарушени формуляри или качвания | Редки, при скокове във версиите са нужни тестове за съвместимост |
| Полза при следващата уязвимост | Висока, ако е поддържана | Никаква, всяка уязвимост изисква собствен ъпдейт |
| Помага ли при PHP 8.1 и по-стари? | Като преход | Само чрез backport или миграция |
Таблицата показва защо двете мерки са свързани. WAF е бърза и широка, но никога не е пълна. Ъпдейтът е пълен, но само за определена уязвимост и не винаги е възможен веднага.
Една точка често се пропуска на практика: WAF променя поведението на уебсайта. Строгите правила могат да блокират легитимни поръчки, контактни формуляри или качване на файлове, без някой веднага да го забележи. Който включи WAF в строг режим в криза, затова трябва веднъж сам да мине през най-важните процеси на уебсайта и да провери протоколите от първите дни за блокирани, но основателни заявки.
Как да комбинирате двете разумно
- Веднага: Проверете дали има WAF и дали подходящите правила са активни. При Cloudflare в платените планове според доставчика настройте Managed Ruleset на Block.
- Веднага: Погрижете се изходният сървър да е достъпен само през WAF, например чрез разрешение във firewall само за нейните адресни диапазони. Иначе защитата остава напразна.
- В рамките на следващия прозорец за поддръжка: Актуализирайте PHP до 8.5.12, 8.4.27, 8.3.36 или 8.2.35 или инсталирайте потвърдения backport на дистрибуцията.
- Веднага след това: Рестартирайте всички PHP worker и процеси и проверете, че не работи стар процес. Само нови файлове не стигат; повече за това в След ъпдейта: рестартиране на PHP-FPM и на всички работници.
- След това: Запазете правилата на WAF, оценете фалшивите аларми и задавайте изключения целенасочено, вместо да изключвате правила общо.
Със собствена WAF на основата на ModSecurity и OWASP Core Rule Set може да се постигне подобно нещо; основите описва Използване на ModSecurity и OWASP Core Rule Set. Особена форма е предложеното от специалисти филтриране на заявки за качване извън истинските пътища за качване. То е неофициално, може да счупи формуляри и влиза в експлоатация само след тест.
Нито WAF, нито ъпдейтът премахват зловреден софтуер, внесен преди това. Проверете след пача дали от 17.10.2026 г. насам са се появили необичайни неща.
Кога не Ви трябва WAF и кога не Ви трябва доставчик
WAF не е задължителна за всеки уебсайт. Малък фирмен уебсайт при хостинг доставчик, който пачва PHP своевременно и го потвърждава, често е достатъчно защитен и без собствена WAF, ако CMS и добавките са актуални. И който може сам да актуализира сървъра си за кратко време, няма нужда от WAF като мост.
Смислена става тя при магазини, портали и приложения с много формуляри, при стари системи, които не могат да се актуализират веднага, и там, където няколко уебсайта трябва да се защитават централно. Доставчик Ви трябва за това само ако настройката, тестовете и текущата поддръжка не са покрити вътрешно.
Как помага PHP SOS конкретно?
- Проверяваме дали Вашата WAF действително стои пред всички достъпи и дали изходният сървър е достъпен директно.
- Настройваме правила или ги адаптираме и тестваме формуляри, качвания и интерфейси за странични ефекти.
- Инсталираме ъпдейта на PHP, рестартираме всички процеси и документираме състоянието.
- Където ъпдейтът отнема време, го преодоляваме с WAF и виртуално пачване и с твърд срок за истинския пач.
Извод
Въпросът „WAF или ъпдейт“ е зададен погрешно. Ъпдейтът затваря уязвимостта, WAF дава време и улавя много други неща. Който разчита само на WAF, се осланя на правила, които нападателите могат да заобиколят. Който само пачва, при следващата уязвимост отново остава без мост.
Често задавани въпроси
Достатъчна ли е WAF като защита срещу PHP2Shell?
Не. WAF проверява трафика и може да блокира познати модели на атака. Самата уязвимост е в интерпретатора на PHP и остава, докато PHP не бъде актуализиран и рестартиран. Cloudflare изрично подчертава, че неговите правила не заместват ъпдейта.
Автоматично ли съм защитен зад Cloudflare?
Само за трафика, който действително минава през Cloudflare. Ако изходният сървър е достъпен директно от интернет, защитата се заобикаля. При платените планове според Cloudflare трябва да проверите дали Managed Ruleset е настроен на Block.
Има ли смисъл от WAF и след ъпдейта?
Често да. WAF може да улавя масови сканирания, познати атаки срещу добавки и злоупотреба със страници за вход и дава време при следващата уязвимост. Нуждае се обаче от поддръжка и тестове, иначе фалшивите аларми пречат на работата.
Какво е виртуално пачване?
Имат се предвид временното екраниране на уязвимост с правила пред приложението, вместо промяна на кода. Това е мост до истинския ъпдейт, а не заместител.