# WAF czy aktualizacja: dlaczego potrzebują Państwo obu > WAF zamiast aktualizacji przy PHP2Shell? Co potrafi Web Application Firewall, gdzie się kończy i dlaczego lukę zamyka tylko aktualizacja PHP z restartem. Źródło: https://phpsos.de/pl/blog/waf-oder-update/ Stan: 25.10.2026 Dostawca: PHP SOS, Pomoc awaryjna PHP i bezpieczeństwo serwerów. Natychmiastowa pomoc przez WhatsApp: https://wa.me/491736494914?text=Dzie%C5%84%20dobry%2C%20PHP%20SOS%2C%20potrzebujemy%20pomocy%20z%20naszym%20serwerem%20PHP.%20Firma%3A%20%E2%80%A6%20Strona%20internetowa%3A%20%E2%80%A6 **Krótko:** WAF zamiast aktualizacji nie działa przy PHP2Shell. Web Application Firewall, czyli filtr przed stroną, sprawdza żądania i może blokować znane wzorce ataków. Sama luka tkwi jednak w interpreterze PHP i znika dopiero z aktualizacją oraz restartem wszystkich procesów PHP. WAF to sensowna dodatkowa warstwa i pomost na kilka dni, a nie rozwiązanie. ## Dlaczego to pytanie pada właśnie teraz tak często Wielu operatorów przeczytało w tygodniu PHP2Shell pozornie dobrą wiadomość: Cloudflare ma według własnych informacji od 21.10.2026, 03:02 UTC, aktywne reguły ochronne, także dla klientów w planie bezpłatnym. Kto i tak stoi za Cloudflare lub innym WAF, pyta zrozumiale, czy aktualizacja jest jeszcze pilna. Uczciwa odpowiedź brzmi: tak. Sam Cloudflare zastrzega: same reguły oparte na danych żądania nie wystarczają, dlatego usługa dodatkowo sprawdza odpowiedź serwera. Cloudflare zaobserwował ponadto zmienione wzorce ataków. A ochrona działa tylko dla ruchu, który faktycznie przechodzi przez Cloudflare. Szczegóły dotyczące tego dostawcy opisuje artykuł [Reguły ochronne Cloudflare przeciwko PHP2Shell](https://phpsos.de/pl/blog/cloudflare-waf-php2shell/). Tutaj chodzi o zasadnicze rozważenie, niezależnie od dostawcy. ## Co widzi WAF, a co zmienia aktualizacja WAF stoi przed aplikacją. Widzi każde żądanie, porównuje je z regułami i przepuszcza, blokuje lub rejestruje. Nie wie, jak PHP przetwarza żądanie wewnętrznie. Obie luki PHP2Shell powstają jednak właśnie tam: CVE-2026-109618 przy stanie braku pamięci (out of memory), gdy dane żądania są tylko częściowo zainicjowane, CVE-2026-109619 przez stan wewnętrzny, który po żądaniu pozostaje w tym samym procesie worker. Aktualizacja koryguje ten kod. Potem przyczyna jest usunięta, niezależnie od tego, jak wygląda żądanie. Kto chce zrozumieć, w którym miejscu przebiegu żądania to się dzieje, znajdzie podstawy w artykule [Cykl życia żądania w PHP](https://phpsos.de/pl/php/request-lebenszyklus/). ## WAF zamiast aktualizacji: uczciwe porównanie | Kryterium | Web Application Firewall | Aktualizacja PHP z restartem | |---|---|---| | Co zostaje naprawione? | Nic, znane wzorce są przechwytywane | Przyczyna w interpreterze PHP | | Ochrona przy nowych wariantach ataku | Tylko jeśli reguły zostaną w porę dostosowane | Tak, luka już nie istnieje | | Czy możliwe jest ominięcie? | Tak, na przykład przez bezpośrednią dostępność serwera źródłowego | Nie, o ile wszystkie procesy PHP zostały zrestartowane | | Szybkość | Często aktywny od razu | Zależy od wersji, dostępu i okna serwisowego | | Skutki uboczne | Fałszywe alarmy, zakłócone formularze lub przesyłanie plików | Rzadko, przy skokach wersji potrzebne testy zgodności | | Pożytek przy następnej luce | Wysoki, jeśli utrzymywany | Żaden, każda luka wymaga własnej aktualizacji | | Czy pomaga przy PHP 8.1 i starszych? | Jako rozwiązanie przejściowe | Tylko przez backport lub migrację | Tabela pokazuje, dlaczego oba środki należą do siebie. WAF jest szybki i szeroki, ale nigdy kompletny. Aktualizacja jest kompletna, ale tylko dla określonej luki i nie zawsze możliwa od razu. W praktyce często przeocza się jeden punkt: WAF zmienia zachowanie strony. Ścisłe reguły mogą blokować uprawnione zamówienia, formularze kontaktowe lub przesyłanie plików, zanim ktokolwiek to zauważy. Kto w kryzysie uruchamia WAF w trybie ostrym, powinien więc raz samodzielnie przeklikać najważniejsze procesy strony i sprawdzić protokoły z pierwszych dni pod kątem zablokowanych, ale uprawnionych żądań. ## Jak sensownie połączyć jedno z drugim 1. **Od razu:** Sprawdzić, czy WAF istnieje i czy właściwe reguły są aktywne. W przypadku Cloudflare w planach płatnych ustawić według dostawcy Managed Ruleset na blokowanie. 2. **Od razu:** Upewnić się, że serwer źródłowy jest dostępny tylko przez WAF, na przykład przez zezwolenie w zaporze tylko dla jego zakresów adresów. W przeciwnym razie ochrona idzie na marne. 3. **W najbliższym oknie serwisowym:** Zaktualizować PHP do 8.5.12, 8.4.27, 8.3.36 lub 8.2.35 albo zainstalować potwierdzony backport dystrybucji. 4. **Zaraz potem:** Zrestartować wszystkie procesy worker i procesy PHP i skontrolować, że nie działa już żaden stary proces. Same nowe pliki nie wystarczą; więcej w artykule [Po aktualizacji: zrestartować PHP-FPM i wszystkie procesy worker](https://phpsos.de/pl/php2shell/php-fpm-neustart/). 5. **Potem:** Zachować reguły WAF, analizować fałszywe alarmy i ustawiać wyjątki celowo, zamiast wyłączać reguły hurtowo. Podobne efekty można osiągnąć własnym WAF opartym na ModSecurity i OWASP Core Rule Set; podstawy opisuje artykuł [Stosowanie ModSecurity i OWASP Core Rule Set](https://phpsos.de/pl/blog/modsecurity-owasp-crs/). Szczególną formą jest zaproponowane przez autorów fachowych filtrowanie żądań uploadu poza prawdziwymi ścieżkami uploadu. Jest nieoficjalne, może psuć formularze i do eksploatacji nadaje się dopiero po teście. > **Ważne:** > Ani WAF, ani aktualizacja nie usuwają złośliwego oprogramowania wprowadzonego wcześniej. Proszę sprawdzić po poprawce, czy od 17.10.2026 wystąpiły jakieś nieprawidłowości. ## Kiedy nie potrzebują Państwo WAF i kiedy usługodawcy WAF nie jest obowiązkowy dla każdej strony. Mała strona firmowa u firmy hostingowej, która szybko łata PHP i to potwierdza, jest często wystarczająco chroniona bez własnego WAF, jeśli CMS i wtyczki są aktualne. Także kto potrafi samodzielnie zaktualizować serwer w krótkim czasie, nie potrzebuje WAF jako pomostu. Sens ma on w sklepach, portalach i aplikacjach z wieloma formularzami, w starych systemach, których nie da się od razu zaktualizować, oraz tam, gdzie chce się centralnie chronić wiele stron. Usługodawcy potrzebują Państwo do tego tylko wtedy, gdy konfiguracja, testy i bieżąca pielęgnacja nie są pokryte wewnętrznie. ## Jak konkretnie pomaga PHP SOS? - Sprawdzamy, czy Państwa WAF faktycznie stoi przed wszystkimi dostępami i czy serwer źródłowy jest dostępny bezpośrednio. - Konfigurujemy reguły lub dostosowujemy je i testujemy formularze, przesyłanie plików i interfejsy pod kątem skutków ubocznych. - Instalujemy aktualizację PHP, restartujemy wszystkie procesy i dokumentujemy stan. - Tam, gdzie aktualizacja trwa, przeczekujemy [WAF-em i wirtualnym łataniem](https://phpsos.de/pl/leistungen/waf-virtuelles-patching/) oraz stałym terminem prawdziwej poprawki. ## Podsumowanie Pytanie „WAF czy aktualizacja” jest źle postawione. Aktualizacja zamyka lukę, WAF daje czas i przechwytuje wiele innych rzeczy. Kto stawia tylko na WAF, polega na regułach, które atakujący mogą ominąć. Kto tylko łata, przy następnej luce znów stoi bez pomostu. ## Częste pytania **Czy WAF wystarczy jako ochrona przed PHP2Shell?** Nie. WAF kontroluje ruch i może blokować znane wzorce ataków. Sama luka tkwi w interpreterze PHP i pozostaje, dopóki PHP nie zostanie zaktualizowane i zrestartowane. Cloudflare wyraźnie podkreśla, że jego reguły nie zastępują aktualizacji. **Czy za Cloudflare jestem automatycznie chroniony?** Tylko dla ruchu, który faktycznie przechodzi przez Cloudflare. Jeśli serwer źródłowy jest dostępny bezpośrednio z internetu, ochrona jest omijana. W planach płatnych powinni Państwo według Cloudflare sprawdzić, czy Managed Ruleset jest ustawiony na blokowanie. **Czy WAF ma sens także po aktualizacji?** Często tak. WAF może przechwytywać masowe skanowania, znane ataki na wtyczki i nadużycia stron logowania, a przy następnej luce daje czas. Wymaga jednak pielęgnacji i testów, w przeciwnym razie fałszywe alarmy zakłócają działanie. **Czym jest wirtualne łatanie?** Chodzi o tymczasowe osłonięcie podatności regułami przed aplikacją zamiast zmiany kodu. To pomost do prawdziwej aktualizacji, a nie jej zamiennik. ## Źródła - [Blog Cloudflare](https://blog.cloudflare.com/) - [OWASP ModSecurity Core Rule Set](https://coreruleset.org/) - [php.net: komunikaty o bezpieczeństwie](https://www.php.net/) - [PHP 8 ChangeLog (dziennik zmian)](https://www.php.net/ChangeLog-8.php)