Krótko: Cloudflare ma według własnych informacji od 21 października 2026, godz. 03:02 UTC, aktywne reguły ochronne przeciw PHP2Shell, także dla klientów planu bezpłatnego. Reguły obniżają ryzyko dla ruchu przechodzącego przez Cloudflare. Nie działają, gdy serwer źródłowy jest osiągalny bezpośrednio, i nie zastępują aktualizacji PHP. Kto korzysta z Cloudflare, powinien sprawdzić tryb reguł, ochronę źródła i stan poprawek.
Punkt wyjścia: ochrona jeszcze przed poprawką
Cloudflare wyprzedził w przypadku PHP2Shell innych niezwykle wcześnie. Według bloga Cloudflare reguły ochronne działały już kilka godzin przed oficjalną publikacją aktualizacji PHP o godz. 14:00 UTC. Cloudflare poinformował ponadto, że zaobserwował próby ataków na klientów oraz że atakujący zmieniali wzorce, aby obejść reguły.
Wielu operatorów wywnioskowało z tego: „Jesteśmy za Cloudflare, więc jesteśmy chronieni.” To prawda tylko częściowo. Ten artykuł wyjaśnia, co reguły faktycznie obejmują. Ogólne rozważenie między zaporą a aktualizacją oferuje artykuł WAF czy aktualizacja?.
Co Cloudflare wdrożył przeciw PHP2Shell
Według informacji z bloga Cloudflare istnieją trzy elementy:
| Plan | Ochrona według Cloudflare | Co należy zrobić |
|---|---|---|
| Free | nowe reguły w Managed Free Ruleset, aktywne automatycznie | sprawdzić, czy domena działa przez Cloudflare |
| Pro, Business, Enterprise | odpowiednie reguły w Managed Ruleset | upewnić się, że ruleset jest ustawiony na „Block” |
| wszystkie plany | reguła domyślna w nowej zaporze odpowiedzi | niczego nie wyłączać, obserwować zdarzenia |
Trzeci element jest nowy. Cloudflare nazywa go „full transaction detection”: WAF analizuje nie tylko żądanie, ale także odpowiedź serwera. Powód według Cloudflare: samo żądanie nie zawsze wystarcza, aby pewnie odróżnić atak od normalnego ruchu. PHP2Shell to pierwsze zastosowanie tej funkcji w regułach zarządzanych.
Granice reguł Cloudflare
Choć reguły są pomocne, mają wyraźne granice, które Cloudflare po części sam wskazuje:
- Tylko ruch przez Cloudflare: Reguły sprawdzają to, co przepływa przez Cloudflare. Jeśli serwer źródłowy jest osiągalny bezpośrednio pod swoim adresem IP, atakujący może obejść ochronę.
- Brak cofania skutków: Według Cloudflare reguła po stronie odpowiedzi może zatrzymać odpowiedź, ale nie cofnie tego, co na serwerze już się wydarzyło.
- Zmienne wzorce ataków: Cloudflare na bieżąco dostosowuje reguły, ponieważ atakujący zmieniają swoje żądania. Między nowym wariantem a nową regułą może istnieć luka.
- Brak zastępstwa aktualizacji: Cloudflare wyraźnie zaleca zaktualizowanie PHP mimo WAF. Aktualizacja kodu aplikacji lub wtyczek również nie usuwa luk.
- Przypadek szczególny CVE-2026-115560: Według uzupełnienia Cloudflare z 23 października reguła nie działa, jeśli zmieniono w konfiguracji nazwę dla session upload progress. Więcej o tym komunikacie pod hasłem CVE-2026-115560.
Co mówią zablokowane żądania, a czego nie
Wielu klientów zagląda po komunikacie do swoich zdarzeń bezpieczeństwa i znajduje tam zablokowane żądania. Pokazuje to najpierw tylko, że Państwa domena była sprawdzana i reguła zadziałała. Włamanie nie jest przez to udowodnione. Odwrotnie, pusta lista zdarzeń nie jest odwołaniem alarmu: jeśli atak szedł bezpośrednio na serwer źródłowy lub przed 21 października, nie pojawi się u Cloudflare w ogóle.
Bardziej wiarygodne jest porównanie z logami samego serwera WWW. Żądania, które tam docierają, ale nie pochodzą z adresów Cloudflare, wskazują na bezpośredni dostęp. Proszę zabezpieczyć te logi od 20 października, jak radzi prasa branżowa. Cloudflare zwraca ponadto uwagę, że ograniczenia dla przesyłania plików mogą zmniejszyć ryzyko, ale nie zastępują aktualizacji PHP.
Najczęstszą słabością za Cloudflare nie jest reguła, lecz droga obok niej: serwer źródłowy, który odpowiada bezpośrednio pod swoim adresem IP lub przez niechronioną subdomenę.
Lista kontrolna dla klientów Cloudflare
Te kroki Państwo lub Państwa usługodawca mogą wykonać w krótkim czasie:
- Sprawdzić plan i tryb reguł: W płatnych planach skontrolować w dashboardzie, czy Managed Ruleset jest aktywny w trybie „Block”.
- Przejrzeć zdarzenia bezpieczeństwa: W Security Events sprawdzić, czy pojawiają się zablokowane żądania. Pokazuje to, czy Państwa domeny były już celem.
- Przejść przez wpisy DNS: Każdy wpis, który wskazuje na serwer WWW, ale nie działa przez Cloudflare, jest możliwym objazdem. Typowe są subdomeny dla stagingu, FTP lub poczty na tym samym serwerze.
- Odizolować źródło: Skonfigurować serwer WWW tak, aby przyjmował HTTP i HTTPS tylko od Cloudflare, na przykład przez zaporę z opublikowanymi przez Cloudflare zakresami adresów lub przez tunel. Jak to zrobić ogólnie, opisuje artykuł Zapora dla serwera WWW.
- Przetestować dostęp bezpośredni: Sprawdzić z zewnątrz, czy źródło odpowiada bez Cloudflare.
- Zaktualizować PHP i zrestartować: Reguły są drugą linią. Pierwszą jest PHP w naprawionym stanie z restartem wszystkich procesów PHP.
Do kroku 5 wystarczy nieszkodliwy test, który odpytuje tylko nagłówki. Adres IP jest zastępczy dla Państwa serwera źródłowego:
# Czy serwer źródłowy odpowiada bezpośrednio, z pominięciem Cloudflare?
curl -sI --resolve www.example.de:443:203.0.113.10 https://www.example.de/
Jeśli otrzymają Państwo tu zwykłą odpowiedź swojej strony, źródło jest osiągalne bezpośrednio, a ochronę Cloudflare można obejść.
Jak konkretnie pomaga PHP SOS?
- Sprawdzenie konfiguracji: Sprawdzamy tryb reguł, wpisy DNS i bezpośredni dostęp do serwera źródłowego.
- Zabezpieczenie źródła: Ograniczamy serwer WWW do ruchu przez Cloudflare, nie przerywając działania Państwa strony.
- Poprawka i dowód: Aktualizujemy PHP, restartujemy wszystkie procesy i dokumentujemy stan.
- Analiza zdarzeń: Przeglądamy zablokowane żądania i porównujemy je z logami serwera.
Jak łączymy reguły WAF ze środkami przejściowymi, opisuje WAF i wirtualne łatanie.
Podsumowanie
Reguły Cloudflare przeciw PHP2Shell to prawdziwy zysk, zwłaszcza że pojawiły się wcześnie i także w planie bezpłatnym. Są jednak tarczą przed drzwiami, a nie zamkiem w drzwiach. Kto siedzi za Cloudflare, powinien zapewnić trzy rzeczy: reguły w trybie Block, brak drogi omijającej proxy i PHP w naprawionym stanie.
Częste pytania
Czy z bezpłatnym planem Cloudflare jestem chroniony przed PHP2Shell?
Według Cloudflare także klienci planu Free otrzymują reguły ochronne automatycznie. Działają one jednak tylko dla ruchu przechodzącego przez Cloudflare i nie zastępują aktualizacji PHP na serwerze. Jeśli serwer źródłowy jest osiągalny bezpośrednio, ochrona nie zadziała.
Co muszę ustawić w płatnych planach Cloudflare?
Cloudflare radzi klientom planów Pro, Business i Enterprise sprawdzić, czy Managed Ruleset działa w trybie Block. Jeśli ustawiono tylko rejestrowanie, ataki są wprawdzie odnotowywane, ale nie są powstrzymywane.
Czym jest full transaction detection?
To nowa funkcja WAF Cloudflare, która analizuje nie tylko żądanie, ale także odpowiedź serwera. Dzięki temu można rozpoznać, czy próba ataku odniosła skutek, a odpowiedź można zatrzymać. Tego, co zostało już wykonane na serwerze, według Cloudflare nie cofa.
Czy Cloudflare obejmuje także CVE-2026-115560?
Cloudflare uzupełnił swój wpis 23 października o CVE-2026-115560. Według Cloudflare odpowiednia reguła nie działa, jeśli zmieniono w konfiguracji PHP nazwę dla postępu przesyłania sesji (session upload progress). Niezależnie od tego php.net zaleca ustawienie session.upload_progress.enabled=0.