Krótko: To, czy wyłączyć stronę z powodu luki w PHP, zależy od jednego pytania: czy PHP na tym serwerze działa udokumentowanie w poprawionej wersji i czy wszystkie procesy zostały zrestartowane? Jeśli tak, wyłączenie nie jest potrzebne. Jeśli aktualizacja nie jest możliwa od razu, BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej) zaleca tymczasowe odłączenie serwera WWW od sieci. Czekanie jest uzasadnione tylko wtedy, gdy system nie używa PHP, nie jest publicznie dostępny lub dostawca pisemnie potwierdził poprawkę.
Sytuacja, w której muszą Państwo zdecydować
PHP2Shell obejmuje dwie luki w samym PHP, CVE-2026-109618 i CVE-2026-109619, obie ocenione na CVSS v4.0 9,2. Umożliwiają one zdalne wykonanie złośliwego kodu bez logowania. Poprawione wersje są dostępne od 21.10.2026: 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Dla PHP 8.1 i starszych nie ma już oficjalnych aktualizacji.
BSI wydało poziom ostrzegawczy pomarańczowy i radzi natychmiastową aktualizację, a zastępczo tymczasowe wyłączenie. Według doniesień medialnych miasto Moguncja (Mainz), jednostki rządu krajowego Hesji i inne instytucje publiczne prewencyjnie odłączyły strony od sieci; hesyjska kancelaria państwowa nie zgłosiła żadnego ataku. Co firmy mogą z tego wywnioskować, wyjaśnia artykuł Urzędy odłączają strony od sieci.
Dla osób odpowiedzialnych w firmach pytanie jest bardziej praktyczne: co robimy dziś z naszym sklepem, portalem, stroną firmy?
Wyłączyć stronę, łatać czy czekać: trzy opcje w porównaniu
Poniższa tabela zestawia opcje obok siebie. Nie zastępuje oceny Państwa indywidualnego przypadku, ale uwidacznia rozważania.
| Kryterium | Załatać od razu | Tymczasowo wyłączyć | Czekać |
|---|---|---|---|
| Ochrona przed PHP2Shell | Wysoka, jeśli poprawka i restart są udokumentowane | Wysoka na czas wyłączenia | Żadna, dopóki nie załatane |
| Przerwa w działaniu | Krótka, na aktualizację i restart | Godziny do dni | Brak |
| Warunek | Obsługiwana wersja PHP, dostęp, okno serwisowe | Decyzja zarządu, statyczna strona zastępcza | Udokumentowany powód, dlaczego nie ma ryzyka |
| Nakład | Niski do średniego | Niski technicznie, wysoki organizacyjnie | Niski, ale nakład na sprawdzenie dowodu |
| Typowy przypadek | Serwer z PHP 8.2 do 8.5 | Stary system z PHP 8.1 lub starszym, niejasny stan | System bez PHP lub dostępny tylko wewnętrznie |
| Ryzyko resztkowe | Wcześniejsze włamanie nadal możliwe | Wcześniejsze włamanie nadal możliwe | W pełni utrzymane |
Jeden wiersz zasługuje na uwagę: ani poprawka, ani wyłączenie nie wyjaśniają, czy wcześniej coś się już wydarzyło. Według doniesień medialnych pierwsza zaobserwowana próba ataku miała miejsce 17.10.2026, a więc przed poprawką. Spojrzenie na możliwe ślady należy więc do każdej opcji.
W pięciu pytaniach do decyzji
Proszę przejść pytania po kolei. Pierwsza jednoznaczna odpowiedź zwykle prowadzi do decyzji.
- Czy w systemie w ogóle działa PHP i czy jest dostępny z internetu? Jeśli nie, system nie jest bezpośrednio dotknięty przez PHP2Shell. Proszę udokumentować, jak to ustalono.
- Czy stan poprawek jest udokumentowany? Udokumentowany oznacza: poprawiona wersja lub backport z numerami CVE w dzienniku zmian pakietu i restart wszystkich procesów PHP. Wyświetlenie wersji w panelu nie wystarcza. Jak to sprawdzić, wyjaśnia artykuł Jak prawidłowo sprawdzić wersję PHP i stan poprawek.
- Czy aktualizację można zainstalować w ciągu najbliższych godzin? Jeśli tak: łatać, zrestartować, skontrolować. Do tego czasu mogą pomóc środki tymczasowe.
- Czy to niemożliwe, na przykład z powodu PHP 8.1 lub braku dostępu? Wtedy tymczasowe wyłączenie jest według BSI drogą do wyboru. Środki tymczasowe według php.net obniżają ryzyko, ale nie chronią w pełni; szczegóły podaje artykuł Środki natychmiastowe, gdy jeszcze nie można łatać.
- Czy są oznaki kompromitacji? Wtedy pytanie nie brzmi już „łatać czy wyłączyć”, lecz „obsłużyć incydent”. Wyłączyć, zabezpieczyć dowody, nie usuwać pochopnie.
Jeśli wyłączają Państwo: wyłączyć prawidłowo
Wyłączenie ma usunąć powierzchnię ataku, a nie tylko ukryć stronę główną. Strona konserwacyjna, która nadal jest generowana przez PHP, tego celu nie spełnia. Lepsza jest statyczna strona HTML, którą serwer WWW serwuje bez PHP, albo przekierowanie na inny serwer.
Proszę pomyśleć o wszystkim, co zależy od tego samego PHP: podstrony, interfejsy dla aplikacji lub systemu zarządzania towarami, obszary administracyjne, zwrotne wywołania płatności. Jeśli dotknięty jest sklep, proszę wcześniej porozmawiać z dostawcą płatności i logistyką. I poinformować pracowników i klientów jasnymi słowami: strona jest prewencyjnie offline, kontakt odbywa się telefonicznie i e-mailem. To lepsze niż milczenie, które karmi spekulacje.
Ważny jest też koniec wyłączenia. Proszę określić, pod jakim warunkiem strona wraca online, na przykład „PHP w poprawionej wersji, restart skontrolowany, pierwsza kontrola śladów bez ustaleń”. W ten sposób z hamulca bezpieczeństwa powstaje uporządkowany przebieg.
Wyłączenie nie jest porażką. Według doniesień medialnych kilka instytucji publicznych zrobiło dokładnie to, choć nie było ataku. Prewencyjne wyłączenie nie oznacza automatycznie, że strona została zhakowana.
Kiedy nie potrzebują Państwo usługodawcy
Nie każda decyzja wymaga zewnętrznej pomocy. Jeśli Państwa strona leży u firmy hostingowej, która pisemnie potwierdza stan poprawek i restart, i nie ma żadnych nieprawidłowości, krótka dokumentacja w zupełności wystarczy. To samo dotyczy sytuacji, gdy Państwa własne IT potrafi samo załatać serwer z obsługiwaną wersją PHP i opanowało kontrolę.
Pomoc się opłaca, gdy działają systemy ze starą wersją PHP, stan jest niejasny, dotkniętych jest wiele serwerów lub występują oznaki włamania.
Jak konkretnie pomaga PHP SOS?
- Wyjaśniamy z Państwem w krótkim czasie, które systemy są dotknięte i jaki stan poprawek jest udokumentowany.
- Dostarczamy zarządowi podstawę decyzji na jednej stronie: opcje, ryzyka, zalecana droga.
- Wdrażamy wybraną drogę, czyli poprawkę z restartem, środki tymczasowe lub prawidłowe wyłączenie ze statyczną stroną zastępczą, w ramach naszej natychmiastowej pomocy przy PHP2Shell.
- Sprawdzamy ślady od 17.10.2026 i dokumentujemy wynik.
Podsumowanie
Łatanie jest normą, wyłączenie właściwym hamulcem bezpieczeństwa, a czekanie uzasadnione tylko z dowodem. Kto uczciwie odpowie na pięć pytań i zapisze decyzję na piśmie, działa zgodnie z zaleceniem BSI i może później pokazać, dlaczego.
Częste pytania
Czy muszę wyłączyć stronę z powodu PHP2Shell?
Nie, jeśli PHP działa już w poprawionej wersji i wszystkie procesy zostały zrestartowane. BSI zaleca tymczasowe wyłączenie na wypadek, gdyby natychmiastowa aktualizacja nie była możliwa.
Co kosztuje więcej: wyłączenie czy ryzyko?
Można na to odpowiedzieć tylko w indywidualnym przypadku. Przestój trwający godziny jest zwykle łatwiejszy do zaplanowania niż włamanie, którego skutków i czasu trwania nikt nie zna. Proszę zapisać rozważania na piśmie, niezależnie od tego, jak się skończą.
Czy strona z komunikatem o konserwacji może działać na tym samym serwerze?
Tak, jeśli jest serwowana jako plik statyczny bez PHP. Jeśli strona konserwacyjna jest nadal generowana przez PHP, powierzchnia ataku pozostaje.
Czy czekanie bywa kiedykolwiek właściwym wyborem?
Tak, w jasno określonych przypadkach: gdy w systemie nie działa PHP, gdy nie jest dostępny z internetu lub gdy dostawca pisemnie potwierdził poprawkę i restart. Czekanie bez takich dowodów nie jest opcją, lecz ryzykiem.
Kto powinien podjąć decyzję?
Osoba, która odpowiada za ryzyko biznesowe, zwykle zarząd lub właściciel. IT dostarcza fakty. To, kto decyduje, powinno być wcześniej zapisane w planie awaryjnym.