Na kratko: WAF namesto posodobitve pri PHP2Shell ne deluje. Požarni zid za spletne aplikacije (Web Application Firewall), torej filter pred spletno stranjo, preverja zahteve in lahko blokira znane vzorce napadov. Vrzel sama pa je v interpreterju PHP in izgine šele s posodobitvijo ter ponovnim zagonom vseh procesov PHP. WAF je smiselna dodatna plast in most za nekaj dni, ne rešitev.
Zakaj se to vprašanje zdaj postavlja tako pogosto
Mnogi upravljavci so v tednu PHP2Shell prebrali na videz dobro novico: Cloudflare ima po lastnih navedbah od 21. 10. 2026, 03:02 UTC, aktivna zaščitna pravila, tudi za stranke v brezplačnem paketu. Kdor je tako ali tako za Cloudflare ali drugim WAF, se razumljivo sprašuje, ali posodobitev potem še nujna.
Pošten odgovor je da. Cloudflare sam omejuje: pravila samo na podlagi podatkov zahteve ne zadoščajo, zato storitev dodatno preverja odgovor strežnika. Cloudflare je opazil tudi spremenjene vzorce napadov. In zaščita deluje samo za promet, ki dejansko teče prek Cloudflare. Podrobnosti o tem ponudniku opisuje Zaščitna pravila Cloudflare proti PHP2Shell. Tu gre za načelno tehtanje, neodvisno od ponudnika.
Kaj WAF vidi in kaj spremeni posodobitev
WAF stoji pred aplikacijo. Vidi vsako zahtevo, jo primerja s pravili in jo spusti, blokira ali zabeleži. Ne ve, kako PHP zahtevo interno obdela. Obe vrzeli PHP2Shell pa nastaneta prav tam: CVE-2026-109618 pri stanju pomanjkanja pomnilnika (out-of-memory), medtem ko so podatki zahteve le delno inicializirani, CVE-2026-109619 zaradi notranjega stanja, ki po zahtevi v istem delavcu ostane.
Posodobitev to kodo popravi. Potem je vzrok odpravljen, ne glede na to, kako zahteva izgleda. Kdor želi razumeti, na katerem mestu v poteku zahteve se to zgodi, najde osnove na strani Življenjski cikel zahteve v PHP.
WAF namesto posodobitve: pošteno primerjanje
| Merilo | Požarni zid za spletne aplikacije | Posodobitev PHP s ponovnim zagonom |
|---|---|---|
| Kaj se odpravi? | Nič, znani vzorci se prestrežejo | Vzrok v interpreterju PHP |
| Zaščita pri novih različicah napadov | Samo če se pravila pravočasno prilagodijo | Da, vrzeli ni več |
| Ali je zaobhod mogoč? | Da, na primer prek neposredne dosegljivosti izvornega strežnika | Ne, če so vsi procesi PHP znova zagnani |
| Hitrost | Pogosto takoj aktivno | Odvisno od različice, dostopa in vzdrževalnega okna |
| Stranski učinki | Lažni alarmi, motnje obrazcev ali nalaganj | Redki, pri skokih različic so potrebni preizkusi združljivosti |
| Korist pri naslednji vrzeli | Velika, če je vzdrževan | Nobena, vsaka vrzel potrebuje lastno posodobitev |
| Ali pomaga pri PHP 8.1 in starejših? | Kot prehod | Samo prek prenosa popravka (backport) ali selitve |
Tabela kaže, zakaj oba ukrepa sodita skupaj. WAF je hiter in širok, a nikoli popoln. Posodobitev je popolna, a samo za določeno vrzel in ni vedno takoj mogoča.
Eno točko v praksi pogosto spregledajo: WAF spreminja obnašanje spletne strani. Stroga pravila lahko blokirajo zakonita naročila, kontaktne obrazce ali nalaganje datotek, ne da bi to kdo takoj opazil. Kdor v krizi WAF zaostri, naj zato najpomembnejše postopke spletne strani enkrat sam preizkusi in v zapisnikih prvih dni preveri blokirane, a upravičene zahteve.
Tako oboje smiselno združite
- Takoj: Preverite, ali WAF obstaja in ali so ustrezna pravila aktivna. Pri Cloudflare v plačljivih paketih po navedbah ponudnika Managed Ruleset nastavite na Block.
- Takoj: Zagotovite, da je izvorni strežnik dosegljiv samo prek WAF, na primer s sprostitvijo požarnega zidu samo za njihove naslovne razpone. Sicer zaščita gre v prazno.
- V naslednjem vzdrževalnem oknu: PHP posodobite na 8.5.12, 8.4.27, 8.3.36 ali 8.2.35 ali namestite potrjen prenos popravka (backport) distribucije.
- Takoj zatem: Znova zaženite vse delavce in procese PHP in preverite, da ne teče noben star proces. Same nove datoteke ne zadoščajo; več na strani Po posodobitvi: ponovni zagon PHP-FPM in vseh delavcev.
- Nato: Pravila WAF obdržite, lažne alarme ovrednotite in izjeme postavite ciljno, namesto da bi pravila pavšalno izklopili.
Z lastnim WAF na osnovi ModSecurity in OWASP Core Rule Set je mogoče doseči podobno; osnove opisuje Uporaba ModSecurity in OWASP Core Rule Set. Posebna oblika je filtriranje zahtev za nalaganje zunaj pravih poti nalaganja, ki so ga predlagali strokovni avtorji. Je neuradno, lahko pokvari obrazce in sodi v delovanje samo po preizkusu.
Ne WAF ne posodobitev ne odstranita škodljive programske opreme, vnesene prej. Po popravku preverite, ali so se od 17. 10. 2026 pojavile nenavadnosti.
Kdaj WAF ne potrebujete in kdaj ne ponudnika
WAF ni obvezen za vsako spletno stran. Majhna spletna stran podjetja pri ponudniku gostovanja, ki PHP pravočasno popravi in to potrdi, je brez lastnega WAF pogosto dovolj zaščitena, če sta CMS in vtičniki ažurna. Tudi kdor lahko strežnik v kratkem času posodobi sam, WAF kot mostu ne potrebuje.
Smiseln postane pri trgovinah, portalih in aplikacijah z mnogo obrazci, pri starih sistemih, ki jih ni mogoče takoj posodobiti, in tam, kjer je treba centralno zaščititi več spletnih strani. Ponudnika za to potrebujete samo, če namestitev, testi in tekoče vzdrževanje niso pokriti interno.
Kako PHP SOS pomaga konkretno?
- Preverimo, ali vaš WAF dejansko stoji pred vsemi dostopi in ali je izvorni strežnik neposredno dosegljiv.
- Vzpostavimo pravila ali jih prilagodimo ter preizkusimo obrazce, nalaganja in vmesnike glede stranskih učinkov.
- Namestimo posodobitev PHP, znova zaženemo vse procese in stanje dokumentiramo.
- Kjer posodobitev traja, premostimo z WAF in virtualnim popravljanjem in stalnim terminom za pravi popravek.
Sklep
Vprašanje »WAF ali posodobitev« je napačno zastavljeno. Posodobitev zapre vrzel, WAF pridobi čas in prestreže marsikaj drugega. Kdor se zanese samo na WAF, se zanese na pravila, ki jih napadalci lahko zaobidejo. Kdor samo popravlja, pri naslednji vrzeli spet stoji brez mostu.
Pogosta vprašanja
Ali WAF zadošča kot zaščita pred PHP2Shell?
Ne. WAF preverja promet in lahko blokira znane vzorce napadov. Vrzel sama je v interpreterju PHP in ostane, dokler PHP ni posodobljen in znova zagnan. Cloudflare izrecno poudarja, da njegova pravila posodobitve ne nadomeščajo.
Ali sem za Cloudflare samodejno zaščiten?
Samo za promet, ki dejansko teče prek Cloudflare. Če je izvorni strežnik neposredno dosegljiv z interneta, se zaščita zaobide. Pri plačljivih paketih naj bi po navedbah Cloudflare preverili, ali je Managed Ruleset nastavljen na Block.
Ali se WAF po posodobitvi še splača?
Pogosto da. WAF lahko prestreže množična skeniranja, znane napade na vtičnike in zlorabo prijavnih strani ter pri naslednji vrzeli pridobi čas. Potrebuje pa vzdrževanje in teste, sicer lažni alarmi motijo delovanje.
Kaj je virtualno popravljanje?
S tem je mišljeno začasno zavarovanje ranljivosti s pravili pred aplikacijo, namesto da bi se spremenila koda. Je most do prave posodobitve, ne nadomestilo.