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. 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.
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
- 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.
- 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.
- 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.
- 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.
- 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. 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.
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 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.