# WAF ili ažuriranje: zašto Vam treba oboje > WAF umjesto ažuriranja kod PHP2Shella? Što web aplikacijski vatrozid može, gdje završava i zašto ranjivost zatvara samo PHP ažuriranje s ponovnim pokretanjem. Izvor: https://phpsos.de/hr/blog/waf-oder-update/ Stanje: 25.10.2026 Pružatelj: PHP SOS, PHP hitna pomoć i sigurnost poslužitelja. Hitna pomoć putem WhatsAppa: https://wa.me/491736494914?text=Pozdrav%20PHP%20SOS%2C%20trebamo%20pomo%C4%87%20s%20na%C5%A1im%20PHP%20poslu%C5%BEiteljem.%20Tvrtka%3A%20%E2%80%A6%20Web-stranica%3A%20%E2%80%A6 **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](https://phpsos.de/hr/blog/cloudflare-waf-php2shell/). 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](https://phpsos.de/hr/php/request-lebenszyklus/). ## 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 1. **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. 2. **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. 3. **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. 4. **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](https://phpsos.de/hr/php2shell/php-fpm-neustart/). 5. **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](https://phpsos.de/hr/blog/modsecurity-owasp-crs/). 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. > **Važno:** > 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](https://phpsos.de/hr/leistungen/waf-virtuelles-patching/) 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. ## Izvori - [Cloudflare blog](https://blog.cloudflare.com/) - [OWASP ModSecurity Core Rule Set](https://coreruleset.org/) - [php.net: sigurnosne objave](https://www.php.net/) - [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)