Ukratko: WAF umjesto ažuriranja kod PHP2Shella ne funkcionira. Web aplikacijski vatrozid, dakle filtar ispred web-stranice, provjerava zahtjeve i može blokirati poznate obrasce napada. No sama ranjivost nalazi se u PHP interpreteru i nestaje tek s ažuriranjem i ponovnim pokretanjem svih PHP procesa. WAF je smislen dodatni sloj i most na nekoliko dana, a ne rješenje.
Zašto se to pitanje sada tako često postavlja
Mnogi su operateri u tjednu PHP2Shella pročitali naizgled dobru vijest: Cloudflare prema vlastitim navodima od 21. 10. 2026., 03:02 UTC, ima aktivna zaštitna pravila, i za klijente na besplatnom paketu. Tko ionako stoji iza Cloudflarea ili drugog WAF-a, razumljivo se pita žuri li ažuriranje još.
Iskren odgovor je da. Cloudflare sam to ograničava: pravila samo na temelju podataka zahtjeva nisu dovoljna, pa usluga dodatno provjerava odgovor poslužitelja. Cloudflare je uz to opazio izmijenjene obrasce napada. A zaštita djeluje samo za promet koji doista ide preko Cloudflarea. Pojedinosti o tom pružatelju opisuje Cloudflareova zaštitna pravila protiv PHP2Shella. Ovdje je riječ o načelnom odvagivanju, neovisno o pružatelju.
Što WAF vidi, a što ažuriranje mijenja
WAF stoji ispred aplikacije. Vidi svaki zahtjev, uspoređuje ga s pravilima i propušta ga, blokira ili bilježi. Ne zna kako PHP zahtjev interno obrađuje. Obje PHP2Shell ranjivosti nastaju upravo tamo: CVE-2026-109618 kod stanja nedostatka memorije (Out of Memory) dok su podaci zahtjeva tek djelomično inicijalizirani, CVE-2026-109619 zbog internog stanja koje nakon zahtjeva ostaje u istom workeru.
Ažuriranje ispravlja taj kod. Nakon toga je uzrok uklonjen, bez obzira kako zahtjev izgleda. Tko želi razumjeti na kojem mjestu u tijeku zahtjeva se to događa, osnove nalazi u članku Životni ciklus zahtjeva u PHP-u.
WAF umjesto ažuriranja: iskrena usporedba
| Kriterij | Web aplikacijski vatrozid | PHP ažuriranje s ponovnim pokretanjem |
|---|---|---|
| Što se otklanja? | Ništa, poznati obrasci se zaustavljaju | Uzrok u PHP interpreteru |
| Zaštita od novih varijanti napada | Samo ako se pravila pravodobno prilagode | Da, ranjivost više ne postoji |
| Je li zaobilaženje moguće? | Da, primjerice izravnom dostupnošću izvornog poslužitelja | Ne, pod uvjetom da su svi PHP procesi ponovno pokrenuti |
| Brzina | Često odmah aktivan | Ovisi o verziji, pristupu i prozoru održavanja |
| Nuspojave | Lažne uzbune, poremećeni obrasci ili uploadi | Rijetko, kod skokova verzije potrebni testovi kompatibilnosti |
| Korist kod sljedeće ranjivosti | Velika, ako se održava | Nikakva, svaka ranjivost treba vlastito ažuriranje |
| Pomaže li kod PHP-a 8.1 i starijeg? | Kao prijelaz | Samo putem backporta ili migracije |
Tablica pokazuje zašto obje mjere zajedno pripadaju. WAF je brz i širok, ali nikad potpun. Ažuriranje je potpuno, ali samo za određenu ranjivost i ne uvijek odmah moguće.
Jedna se točka u praksi često previđa: WAF mijenja ponašanje web-stranice. Stroga pravila mogu blokirati legitimne narudžbe, kontaktne obrasce ili učitavanje datoteka a da to netko odmah primijeti. Tko u krizi uključi WAF u strogom načinu, trebao bi zato jednom sam proći najvažnije tijekove web-stranice i pregledati zapisnike prvih dana na blokirane, ali opravdane zahtjeve.
Kako oboje smisleno kombinirati
- Odmah: Provjeriti postoji li WAF i jesu li aktivna odgovarajuća pravila. Kod Cloudflarea u plaćenim paketima prema pružatelju Managed Ruleset postaviti na Block.
- Odmah: Osigurati da je izvorni poslužitelj dostupan samo preko WAF-a, primjerice vatrozidnim odobrenjem samo za njegove adresne raspone. Inače zaštita ide u prazno.
- U idućem prozoru održavanja: Ažurirati PHP na 8.5.12, 8.4.27, 8.3.36 ili 8.2.35 ili instalirati potvrđeni backport distribucije.
- Odmah nakon toga: Ponovno pokrenuti sve PHP workere i procese te provjeriti da više ne radi nijedan stari proces. Same nove datoteke nisu dovoljne; više o tome u članku Nakon ažuriranja: ponovno pokretanje PHP-FPM-a i svih workera.
- Poslije: Zadržati WAF pravila, analizirati lažne uzbune i ciljano postavljati iznimke umjesto da se pravila isključuju paušalno.
S vlastitim WAF-om na osnovi ModSecurityja i OWASP Core Rule Seta može se postići slično; osnove opisuje Primjena ModSecurityja i OWASP Core Rule Seta. Poseban oblik je filtriranje zahtjeva za upload izvan stvarnih putova za upload, koje predlažu stručni autori. Ono je neslužbeno, može pokvariti obrasce i ulazi u rad tek nakon testa.
Ni WAF ni ažuriranje ne uklanjaju zlonamjerni softver koji je prije ubačen. Nakon zakrpe provjerite jesu li se od 17. 10. 2026. pojavile neobičnosti.
Kada Vam WAF nije potreban i kada Vam nije potreban pružatelj usluga
WAF nije obvezan za svaku web-stranicu. Mala web-stranica tvrtke kod pružatelja hostinga koji PHP pravodobno zakrpa i to potvrđuje često je bez vlastitog WAF-a dovoljno zaštićena ako su CMS i dodaci ažurni. Ni tko može u kratkom roku sam ažurirati svoj poslužitelj ne treba WAF kao most.
Smislen je kod shopova, portala i aplikacija s mnogo obrazaca, kod starih sustava koji se ne mogu odmah ažurirati i tamo gdje se više web-stranica želi zaštititi središnje. Pružatelj usluga potreban Vam je za to samo ako postavljanje, testove i trajno održavanje ne pokrivate interno.
Kako PHP SOS konkretno pomaže?
- Provjeravamo sjedi li Vaš WAF doista ispred svih pristupa i je li izvorni poslužitelj izravno dostupan.
- Postavljamo pravila ili ih prilagođavamo te testiramo obrasce, uploade i sučelja na nuspojave.
- Instaliramo PHP ažuriranje, ponovno pokrećemo sve procese i dokumentiramo stanje.
- Gdje ažuriranje potraje, premošćujemo WAF-om i virtualnim zakrpanjem te čvrstim rokom za pravu zakrpu.
Zaključak
Pitanje „WAF ili ažuriranje“ pogrešno je postavljeno. Ažuriranje zatvara ranjivost, WAF daje vremena i zaustavlja mnogo toga drugog. Tko se oslanja samo na WAF, oslanja se na pravila koja napadači mogu zaobići. Tko samo zakrpa, kod sljedeće ranjivosti ponovno stoji bez mosta.
Česta pitanja
Je li WAF dovoljna zaštita od PHP2Shella?
Ne. WAF provjerava promet i može blokirati poznate obrasce napada. Sama ranjivost nalazi se u PHP interpreteru i ostaje dok se PHP ne ažurira i ponovno pokrene. Cloudflare izričito naglašava da njegova pravila ne zamjenjuju ažuriranje.
Jesam li iza Cloudflarea automatski zaštićen?
Samo za promet koji doista ide preko Cloudflarea. Ako je izvorni poslužitelj izravno dostupan s interneta, zaštita se zaobilazi. Kod plaćenih paketa prema Cloudflareu trebate provjeriti je li Managed Ruleset postavljen na Block.
Isplati li se WAF i nakon ažuriranja?
Često da. WAF može zaustaviti masovna skeniranja, poznate napade na dodatke i zlouporabu stranica za prijavu te daje vremena kod sljedeće ranjivosti. Ali treba održavanje i testove, inače lažne uzbune smetaju radu.
Što je virtualno zakrpanje?
Time se misli na privremeno zaklanjanje ranjivosti pravilima ispred aplikacije umjesto izmjene koda. To je most do pravog ažuriranja, a ne zamjena.