Krótko: Wiele porad o PHP2Shell, które teraz krążą na forach i w sieciach społecznościowych, nie chroni, a nawet szkodzi: blokowanie żądań z cookie sesji, ukrywanie komunikatów o błędach, ustawianie wartości przez .user.ini lub aktualizowanie tylko CMS. php.net jest jednoznaczny: nie ma pełnych środków przejściowych, a aktualizacja PHP z restartem wszystkich procesów jest jedyną bezpieczną drogą.
Dlaczego fałszywe porady są w tej sytuacji niebezpieczne
Przy krytycznej luce, która przyciąga dużą uwagę, powstaje rynek szybkich rozwiązań. Rady są udostępniane, skracane i przekazywane dalej, często bez ograniczeń ze źródła pierwotnego. Przy PHP2Shell dochodzi to, że szczegóły stały się według doniesień znane jeszcze przed oficjalnym terminem, a sytuacja w pierwszych dniach była niejasna.
Fałszywa porada szkodzi podwójnie. Zostawia lukę otwartą i wywołuje poczucie, że coś zrobiono. Właśnie to poczucie sprawia, że właściwa aktualizacja leży odłogiem. Niektóre rady paraliżują dodatkowo własną stronę.
Dziewięć rad w sprawdzeniu faktów
Poniższa tabela podsumowuje to, co w ostatnich dniach często czytaliśmy, i zestawia te wypowiedzi z tym, co mówią źródła pierwotne.
| Krążąca porada | Dlaczego się nie sprawdza | Co obowiązuje zamiast tego |
|---|---|---|
Blokować wszystkie żądania z PHPSESSID |
Wyraźnie odrzucone przez autorów fachowych; paraliżuje logowania i koszyki | Zaktualizować PHP |
session.upload_progress.enabled=0 wystarcza |
Według doniesień fachowych nie zamyka obu luk | Sensowny środek przejściowy, aktualizacja pozostaje obowiązkiem |
Ustawiać wartości przez ini_set() lub .user.ini |
php.net wyraźnie temu odradza | Po stronie serwera w php.ini, puli FPM lub konfiguracji serwera |
| Ukrywać komunikaty o błędach | Według php.net nie pomagają error_reporting, display_errors ani @ |
Aktualizacja; wyświetlania błędów i tak nie pokazywać publicznie |
Ograniczać pamięć przez RLIMIT_AS lub RLIMIT_DATA |
php.net ostrzega, że właśnie to może wywołać podatną sytuację | Limit przez kontener lub cgroup |
| Aktualizować WordPressa lub wtyczki | Luka leży w interpreterze PHP, a nie w CMS | Zaktualizować środowisko PHP |
| Cloudflare lub inny WAF wystarczy | Ochrona tylko dla ruchu przez usługę; serwery osiągalne bezpośrednio pozostają otwarte | WAF jako dodatkowa warstwa, a nie zastępstwo |
| Przeładować usługę zamiast zrestartować | Według Red Hat przeładowanie nie wystarcza, istniejące workery mogą zachować stary stan | Zrestartować w pełni wszystkie workery |
| Załatane znaczy czyste | Poprawka nie usuwa wcześniej wprowadzonego złośliwego oprogramowania | Zabezpieczyć logi od 20.10. i sprawdzić ślady |
Trzy najczęstsze błędne przekonania dokładniej
Zakaz cookies
Porada, by odrzucać wszystkie żądania z cookie sesji PHPSESSID, brzmi technicznie i stanowczo. Autorzy fachowi wyraźnie ją odrzucają. W praktyce łamie wszystko, co potrzebuje sesji: konta klientów, koszyki, strefy administracyjne, formularze z ochroną przed fałszerstwem. Ochroną przed luką nie jest.
Jedno ustawienie, które wszystko rozwiązuje
session.upload_progress.enabled=0 znajduje się w zaleceniach php.net i jest podanym rozwiązaniem dla CVE-2026-115560. W niektórych artykułach zrobiono z tego „PHP2Shell wyłączone”. Według doniesień fachowych samo to ustawienie nie zamyka jednak obu luk. Także memory_limit=-1 usuwa według php.net tylko sterowalny wyzwalacz; błąd pamięci na głębszym poziomie może nadal dotrzeć do podatnej ścieżki. Na PHP 8.5 fatal_error_backtraces=0 blokuje według php.net tylko potwierdzoną drogę przez backtrace.
Jak mimo to ustawić to rozwiązanie poprawnie i na stałe, opisuje artykuł Wyłączanie session.upload_progress. Pełna lista środków przejściowych znajduje się pod hasłem Środki doraźne bez poprawki.
Tarcza z przodu
Cloudflare ma według własnych informacji od 21 października aktywne reguły ochronne, także dla klientów planu bezpłatnego. Sam Cloudflare wskazuje jednak granice: ochrona działa tylko dla ruchu przechodzącego przez Cloudflare. Jeśli serwer źródłowy jest osiągalny bezpośrednio, zostaje ominięta. Ponadto Cloudflare sprawdza dodatkowo odpowiedź serwera, ponieważ samo żądanie nie zawsze wystarcza. Dlaczego WAF nie zastępuje aktualizacji, wyjaśnia artykuł WAF czy aktualizacja.
Porada z ryzykiem: filtrować żądania przesyłania na brzegu
Nie każda niewygodna rada jest fałszywa. Autorzy fachowi proponują jako tymczasowy, nieoficjalny środek blokowanie żądań multipart/form-data poza prawdziwymi ścieżkami przesyłania na proxy lub w WAF. Może to zmniejszyć powierzchnię ataku, ale łamie formularze i przesyłanie plików, jeśli lista dozwolonych ścieżek jest niekompletna.
Kto idzie tą drogą, powinien wcześniej sprawdzić ją w środowisku testowym, uzgodnić z działami merytorycznymi i udokumentować jako środek ograniczony w czasie. Zastępstwem aktualizacji nie jest i ta rada.
Wiele rozwiązań WAF oferuje do tego tryb obserwacji, w którym reguły najpierw tylko rejestrują zamiast blokować. Proszę pozwolić nowej regule działać tak przez kilka dni i przeanalizować, które uprawnione żądania zostałyby dotknięte. Dopiero potem przełączyć na blokowanie. W ten sposób unikają Państwo tego, że formularze aplikacyjne, portale klientów lub przesyłanie obrazów w sklepie przestaną działać niepostrzeżenie.
Jak sprawdzić poradę, zanim ją Państwo wdrożą
Cztery pytania oddzielają przydatne rady od niebezpiecznych:
- Źródło: Czy zalecenie pochodzi z php.net, Państwa dystrybucji, BSI (niemieckiego Federalnego Urzędu ds. Bezpieczeństwa w Technice Informatycznej) lub z imiennie wskazanego autora fachowego?
- Zakres twierdzenia: Czy środek jest opisany jako przejściowy, czy jako rozwiązanie? Przy PHP2Shell rozwiązaniem jest tylko aktualizacja.
- Skutek uboczny: Co się psuje, gdy środek zadziała? Porada bez wskazówki o skutkach ubocznych jest niekompletna.
- Miejsce wdrożenia: Czy ustawienie jest wprowadzane po stronie serwera w sposób niemożliwy do nadpisania, a po nim następuje restart wszystkich workerów?
Proszę zapisać, jakie środki przejściowe i kiedy zostały ustawione. W ten sposób można je później sprawdzić celowo i rozpoznać, czy rzekoma ochrona nie opóźniła właściwej aktualizacji.
Jak konkretnie pomaga PHP SOS?
- Sprawdzamy środki, które zostały już u Państwa wdrożone, i oddzielamy skuteczne od nieskutecznych.
- Instalujemy aktualizację PHP, restartujemy wszystkie procesy i dokumentujemy stan.
- Tam, gdzie aktualizacja nie jest jeszcze możliwa, wdrażamy środki przejściowe według php.net po stronie serwera i z dokumentacją.
- Dzięki WAF i wirtualnemu łataniu uzupełniamy ochronę na brzegu, nie zastępując aktualizacji.
Częste pytania
Czy blokowanie żądań z PHPSESSID chroni?
Nie. Autorzy fachowi wyraźnie odrzucają tę krążącą poradę. Paraliżuje ona logowania, koszyki i formularze, nie zamykając luki w interpreterze.
Czy session.upload_progress.enabled=0 wystarcza przeciw PHP2Shell?
Nie. To ustawienie jest jednym z kilku środków przejściowych i według doniesień fachowych nie zamyka obu luk. Ma sens, ale nie zastępuje aktualizacji PHP.
Czy pomaga wyłączenie display_errors?
Dla PHP2Shell nie. php.net zwraca uwagę, że ukrywanie diagnostyki przez error_reporting, display_errors lub operator @ nie pomaga. W produkcji display_errors powinno mimo to być wyłączone z innych powodów.
Po czym poznać rzetelną poradę?
Rzetelna porada podaje swoje źródło, opisuje granice i określa środki przejściowe jako takie. Kto obiecuje, że pojedyncze ustawienie czyni aktualizację zbędną, myli się w przypadku PHP2Shell.