PHP2Shell: krytyczne podatności w PHP i jak Cloudflare pomaga zyskać czas na aktualizację

Stan na 22 października 2026. Sytuacja zmienia się z dnia na dzień, nowe informacje dopisujemy na dole w sekcji „Aktualizacje”.

21 października zespół PHP opublikował poprawki dwóch krytycznych podatności w samym silniku PHP, znanych jako PHP2Shell (CVE-2026-109618 i CVE-2026-109619). Pozwalają one przejąć serwer bez logowania i bez żadnego błędu w kodzie strony. Ataki trwają, a pierwsze próby zaobserwowano jeszcze przed publikacją poprawek.

Poniżej wyjaśniamy, na czym polega problem, jak oceniamy go w ICWT i co realnie może zrobić Cloudflare, jeśli jest dobrze skonfigurowany.

W skrócie

• Podatne jest PHP od wersji 5.4 do 8.5.11, czyli praktycznie każda instalacja sprzed 21 października.
• Poprawki istnieją tylko dla gałęzi 8.2, 8.3, 8.4 i 8.5. Starsze wersje nie mają oficjalnej łatki.
• Jedyną pełną naprawą jest aktualizacja PHP i restart wszystkich procesów PHP.
• Cloudflare włączył reguły chroniące przed znanymi wariantami ataku automatycznie, na wszystkich planach, kilka godzin przed publikacją. To nie zastępuje aktualizacji, ale znacząco podnosi poprzeczkę dla atakujących i daje czas na spokojne łatanie.

Na czym polega problem

PHP ma limit pamięci, którą może zużyć pojedyncze żądanie. Kiedy go przekroczy albo trafi na inny błąd krytyczny, przerywa pracę natychmiast, w połowie operacji, i nie sprząta po sobie wszystkiego. Przez lata uchodziło to za kosmetyczną usterkę. Okazało się, że atakujący może celowo wywołać takie przerwanie w odpowiednim momencie, a potem wykorzystać pozostawiony bałagan w pamięci do wykonania własnego kodu na serwerze.

Ważne są trzy rzeczy:

1. Atak nie wymaga błędu w aplikacji. Problem leży w PHP, a nie w WordPressie czy sklepie. Badacze pokazali skuteczne przejęcie m.in. WordPressa, Drupala, Joomli, Magento, Nextclouda i aplikacji na Laravelu, bez logowania.
2. Wystarczy zwykłe żądanie HTTP. Do wysłania ataku służy zwykły formularz (POST). Nie ma jednego podatnego adresu, który dałoby się zablokować.
3. Ryzyko zależy od konfiguracji serwera. Najbardziej narażone są serwery z Apache i modułem mod_php, gdzie atak działa jeszcze przed uruchomieniem kodu strony. Na PHP-FPM, najpopularniejszej dziś konfiguracji, skuteczny atak potwierdzono dla jednej z dwóch podatności, choć zależy on od tego, co robi aplikacja.

Podatności oceniono na 9.2 w skali CVSS v4. Wysoka ocena wynika z tego, że atak jest zdalny, nie wymaga uwierzytelnienia i daje pełną kontrolę nad serwerem. Jednocześnie sam exploit nie jest trywialny i jego skuteczność zależy od wersji i konfiguracji serwera.

Jak to oceniamy w ICWT

Traktujemy PHP2Shell poważnie, ale bez paniki. Kilka faktów, które naszym zdaniem są ważniejsze niż nagłówki:

• Ataki są realne i trwają. Amazon zaobserwował pierwszą próbę 17 października, cztery dni przed publikacją, a od 21 października eksploitacja jest masowa. Jeśli Twój serwer z PHP był dostępny z internetu, warto przejrzeć logi od 17 października, a nie od dnia publikacji.
• Największym problemem są starsze wersje PHP. Serwer na PHP 7.4, 8.0 czy 8.1 nie dostanie oficjalnej poprawki od zespołu PHP. Część dystrybucji Linuksa (np. Debian, Ubuntu, Red Hat) przygotowuje własne paczki, ale dla wielu firm oznacza to projekt migracji, a nie szybką łatkę. Do tego czasu ochrona na brzegu sieci jest główną linią obrony.
• Sama aktualizacja nie wystarczy. Po instalacji nowej wersji trzeba zrestartować wszystkie procesy PHP (PHP-FPM, Apache). Stary kod załadowany w pamięci nadal jest podatny.
• Nie warto wierzyć w hasła typu „70% internetu zagrożone”. PHP rzeczywiście działa na ok. 70% stron, dla których znany jest język serwera (W3Techs), ale realne ryzyko konkretnego serwera zależy od wersji PHP, sposobu uruchomienia i tego, czy ruch przechodzi przez ochronę.

Co zrobił Cloudflare

Cloudflare włączył reguły WAF wykrywające znane warianty ataku 21 października o 5:02 czasu polskiego, około 9 godzin przed oficjalną publikacją poprawek. Reguły zadziałały automatycznie na wszystkich planach, także na darmowym. Cloudflare udostępnia też regułę, która analizuje odpowiedź serwera i może ją zatrzymać, zanim dane trafią do atakującego (warto sprawdzić, czy jest włączona).

Sam Cloudflare mówi wprost, że to rozwiązanie tymczasowe, a jedyną pełną naprawą jest aktualizacja PHP. Zgadzamy się z tym. Rola WAF w tej sytuacji jest inna: ma odsiać jak największą część ataków, zanim w ogóle dotrą do serwera, i kupić czas na zaplanowaną, przetestowaną aktualizację zamiast łatania w nocy.

Ma to szczególne znaczenie przy masowych skanerach. Automaty przeczesujące internet zwykle korzystają z publicznie dostępnych exploitów bez większych zmian, a właśnie takie wzorce reguły Cloudflare rozpoznają najlepiej. Nie da się zagwarantować, że WAF zatrzyma każdy wariant, zwłaszcza dopracowany ręcznie pod konkretny serwer. Daje jednak dużą szansę, że serwer nie padnie ofiarą pierwszej fali automatycznych ataków.

Co sprawdziliśmy sami

W naszym środowisku testowym wysłaliśmy do stref za Cloudflare serię nieszkodliwych żądań. Naśladowały one wyłącznie kształt znanych ataków, bez żadnego złośliwego ładunku. Domyślne reguły Cloudflare zablokowały wszystkie żądania o kształcie jednego z najczęściej opisywanych publicznych wariantów ataku. Inne podejrzane wzorce, opisywane przez niezależnych badaczy, przechodziły już bez blokady.

To nie jest słabość Cloudflare, tylko cecha każdej ochrony opartej na sygnaturach. Reguły zarządzane działają jednocześnie u milionów stron, więc muszą celować we wzorce, które z dużą pewnością oznaczają atak, i nie mogą psuć legalnego ruchu. Są też takie same dla wszystkich. Każdy, także atakujący, może założyć własne konto Cloudflare, postawić za nim testową stronę i sprawdzać kolejne zmodyfikowane wersje exploita, aż któraś przejdzie. Cloudflare sam informuje, że atakujący już modyfikują exploity, i na bieżąco aktualizuje reguły.

Masowe skanery zwykle nie zadają sobie tego trudu. Zdeterminowany atakujący, który celuje w konkretną firmę, może jednak to zrobić. Dlatego przygotowaliśmy własny zestaw reguł, który wychwytuje szerszy zakres sygnałów, w tym takie, których reguły domyślne nie mogą bezpiecznie blokować u wszystkich klientów. Atakujący nie zna ich treści i nie ma jak przetestować na nich swoich modyfikacji. Ponieważ zaczynamy od trybu logowania, reguły można dopasować do konkretnej aplikacji bez ryzyka, że zablokują prawdziwych użytkowników. Więcej o nich niżej.

Cloudflare chroni tylko wtedy, gdy jest dobrze wdrożony

W praktyce największe ryzyko widzimy nie w samych regułach, tylko w konfiguracji wokół nich. Najczęstsze problemy:

• Reguły zarządzane są w trybie „Log” zamiast „Block” albo zostały globalnie wyłączone lub zmienione przy okazji wcześniejszych prac. Na planach płatnych warto sprawdzić, czy nowe reguły faktycznie blokują.
• Wyjątki omijające WAF. Reguły typu „pomiń WAF dla panelu administracyjnego”, „pomiń dla API” albo „pomiń dla IP biura” często obejmują dokładnie te adresy, które obsługuje PHP.
• Serwer dostępny z pominięciem Cloudflare. Jeśli serwer odpowiada bezpośrednio pod swoim adresem IP (stare rekordy DNS, środowisko testowe, subdomena api), atakujący może po prostu ominąć WAF. Dlatego warto przyjmować ruch wyłącznie z Cloudflare, np. przez Authenticated Origin Pulls albo Cloudflare Tunnel.
• Brak reguły analizującej odpowiedzi serwera. Warto upewnić się, że jest włączona.

Które reguły powinny być w trybie Block

Na planach Pro, Business i Enterprise ataki PHP2Shell wykrywają reguły z zestawu Cloudflare Managed Ruleset (ID zestawu efb7b8c949ac4650a09736fc376e9aee). Sprawdź, czy każda z poniższych reguł ma akcję Block i czy nie nadpisuje jej wyjątek albo zmiana ustawień całego zestawu:

• Generic Rules - Anomalous Execution - 1: c1d409ad838f47f59446f21cc438d5dd
• Generic Rules - Anomalous Execution - 2: f9a45927414245e3a64bb12d0a0c2f64
• Generic Rules - Anomalous Execution - 3: 771c654ae1154d4daa72f4e1545d163c
• Generic Rules - Anomalous Execution - 4: 217005865f0145f392300bac212afcc9
• Generic Rules - Anomalous Execution - 5: 38efdb17ea594501bb55a1d71867b12e
• Generic Rules - Anomalous Execution - 6: 4148ae686fdb4d01be673fab9d9c073d
• Generic Rules - Anomalous Execution - 7: 1389aa259617437392ce149c48143645

Reguły najłatwiej znaleźć w panelu Cloudflare w ustawieniach Managed Rules: przy edycji zestawu Cloudflare Managed Ruleset wyszukaj regułę po jej ID i sprawdź kolumnę z akcją.

Czego WAF nie zrobi

Żeby było uczciwie:

• nie zobaczy ruchu, który omija Cloudflare,
• nie ma wglądu w pamięć i konfigurację PHP na serwerze, a niektóre warianty ataku nie zostawiają w ruchu HTTP charakterystycznego śladu,
• nie cofnie tego, co już zostało wykonane na serwerze,
• opiera się na wzorcach, a atakujący zmieniają exploity. Cloudflare na bieżąco aktualizuje reguły, ale zawsze jest to wyścig.

Dlatego WAF traktujemy jako bufor bezpieczeństwa na czas aktualizacji, a nie jako jej zamiennik.

Co zrobić teraz

1. Zaktualizuj PHP do 8.2.35, 8.3.36, 8.4.27 lub 8.5.12 (albo do poprawionej paczki Twojej dystrybucji) i zrestartuj wszystkie procesy PHP.
2. Jeśli nie możesz zaktualizować od razu, zastosuj mitygacje zalecane przez zespół PHP, m.in. wyłącz session.upload_progress.enabled, ogranicz rozmiar żądań i zablokuj formularze typu multipart tam, gdzie aplikacja ich nie potrzebuje. Szczegóły są w komunikacie php.net.
3. Sprawdź konfigurację Cloudflare: tryb reguł, wyjątki, dostępność serwera z pominięciem Cloudflare.
4. Przejrzyj logi od 17 października pod kątem nietypowych błędów pamięci, serii błędów 500 i restartów procesów PHP.
5. Rozważ rotację haseł, kluczy API i tokenów na serwerach PHP wystawionych do internetu, bo jeden z wariantów ataku pozwala odczytać fragmenty pamięci serwera.

Jak możemy pomóc

Bezpłatne sprawdzenie reguł PHP2Shell. Sprawdzimy, czy reguły Cloudflare odpowiedzialne za blokowanie tych ataków działają na Twoich strefach tak, jak powinny: czy są w trybie blokowania, czy nie wyłączają ich wyjątki lub reguły pomijające WAF, czy włączona jest reguła analizująca odpowiedzi i czy w zdarzeniach widać już próby ataku. Potrzebujemy do tego wyłącznie dostępu tylko do odczytu.

9 dodatkowych reguł detekcji dla planu Enterprise, bezpłatnie dla klientów ICWT. Na podstawie advisory PHP, analiz niezależnych badaczy i własnych testów przygotowaliśmy zestaw 9 reguł, które uzupełniają reguły Cloudflare o dodatkowe sygnały związane z obsługą sesji, przesyłanymi plikami, nietypową budową formularzy i odpowiedziami serwera. Jedna z nich wychwytuje też oznaki prawdopodobnie skutecznej eksploitacji, czyli sygnał, że atak mógł się już powieść i serwer wymaga sprawdzenia. Reguły wymagają inspekcji treści żądań, która w Cloudflare jest dostępna na planie Enterprise. Zalecamy włączyć je co najmniej w trybie logowania. Dzięki temu w Security Analytics zobaczysz, czy ktoś próbuje wykorzystać PHP2Shell w Twojej infrastrukturze, nawet jeśli żądanie nie zostało zablokowane. Po kilku dniach obserwacji można zdecydować, które z nich przełączyć na blokowanie.

Treści reguł celowo nie publikujemy, żeby nie ułatwiać atakującym szukania sposobów na ich obejście. Udostępniamy je naszym klientom i pomagamy we wdrożeniu.

Jeśli chcesz pójść dalej, w ramach naszych standardowych usług wykonujemy pełny audyt konfiguracji Cloudflare.

Umów bezpłatne sprawdzenie reguł PHP2Shell albo napisz do nas: [email protected].

Źródła

• Cloudflare: ochrona WAF przed podatnościami PHP
• AWS: wykrycie eksploitacji przed publikacją (MadPot)
• PHP Foundation: opis wydania i osi czasu

Aktualizacje

• 22.10.2026: pierwsza wersja wpisu.
• 22.10.2026 20:30: dodaliśmy listę ID reguł Cloudflare Managed Ruleset, które powinny być ustawione na Block.
• 22.10.2026 21:15: zestaw reguł ICWT dla klientów rozszerzyliśmy z 8 do 9. Nowa reguła wykrywa oznaki prawdopodobnie skutecznej eksploitacji i utrudnia atakującym analizę skuteczności ich działań.