Krótko: Luka bezpieczeństwa PHP2Shell składa się z dwóch krytycznych błędów w PHP, podstawie większości stron i sklepów internetowych. Atakujący mogą przez nie bez hasła wykonywać złośliwy kod na serwerach WWW. BSI ostrzega poziomem pomarańczowym i radzi: natychmiast zaktualizować, w przeciwnym razie czasowo odłączyć dotknięte serwery od sieci. Dla zarządu oznacza to dziś: wyjaśnić odpowiedzialność, zażądać aktualizacji i dowodu, zdecydować o wyłączeniu i wszystko udokumentować.
Sytuacja w trzech zdaniach
21 października 2026 projekt PHP opublikował aktualizacje dla dwóch krytycznych luk bezpieczeństwa, znanych pod nazwą PHP2Shell. Dotknięte jest samo PHP, a nie konkretny produkt, a więc potencjalnie każda strona, każdy sklep i każdy portal działający na PHP. BSI ogłosiło poziom ostrzeżenia 3 / pomarańczowy, firmy zajmujące się bezpieczeństwem informują o próbach ataków, a potwierdzone udane ataki na szeroką skalę nie były według BSI początkowo znane.
Urzędy takie jak BKA (niemiecki Federalny Urząd Kryminalny) i kilka miast prewencyjnie wyłączyły według doniesień medialnych swoje strony. Było to zachowanie ostrożności, a nie oznaka ataku.
Co luka bezpieczeństwa PHP oznacza dla zarządu i firmy
Pytanie nie brzmi, czy używacie Państwo PHP. Prawie każda firma robi to gdzieś: strona, sklep, portal kandydatów, strefa klienta, intranet, system zgłoszeń, mikrostrona agencji. Pytanie brzmi, czy te systemy są aktualne i kto za nie odpowiada.
Jeśli atak się powiedzie, atakujący może w najgorszym razie przejąć serwer. Możliwe skutki to wyciek danych, zmanipulowane treści, przekierowania na strony oszustów, awaria sklepu lub wykorzystanie serwera do dalszych ataków. Jeśli mogą być dotknięte dane osobowe, dochodzą obowiązki zgłoszeniowe; termin według art. 33 RODO wynosi z reguły 72 godziny. Szczegóły podano pod hasłem obowiązek zgłoszenia z RODO. Nie jest to porada prawna.
Jakie koszty typowo powstają w poważnym przypadku, porządkuje artykuł Pozycje kosztowe włamania.
Gdzie PHP w firmach bywa pomijane
Główną stronę większość ma na oku. Pomijane są raczej systemy na obrzeżach: portal kandydatów zewnętrznego dostawcy, landing page ze starej kampanii, strefa partnerska dla sprzedawców, system zgłoszeń działu wsparcia, chmura plików na własnym serwerze lub interfejs webowy magazynu sieciowego. Także systemy testowe agencji są często publicznie dostępne i działają na tym samym serwerze co prawdziwa strona.
Dla zarządu lekcja jest prosta: pytanie do IT nie brzmi „Czy nasza strona jest załatana?”, lecz „Czy wszystkie nasze systemy z PHP są załatane, także te usługodawców?”. Różnica między tymi dwoma pytaniami jest często dokładnie tym miejscem, w którym atak się udaje.
Czym ta sytuacja nie jest
Równie ważna jest ocena w dół. PHP2Shell nie jest powodem do aktywizmu, który zakłóca działalność bardziej, niż to konieczne. Kto udokumentowanie załatał, zrestartował wszystkie procesy PHP i nie znajduje przy sprawdzeniu nieprawidłowości, może wrócić do normalnej pracy. Czasowe wyłączenie jest opcją w niewyjaśnionych przypadkach, a nie obowiązkiem dla wszystkich.
Pięć pytań do Państwa IT lub usługodawcy
Te pytania można zadać już dziś. Odpowiedzi powinny nadejść na piśmie.
- Które z naszych systemów działają na PHP? Lista z adresem, celem i operatorem.
- Czy każdy system jest załatany? Naprawiona wersja 8.5.12, 8.4.27, 8.3.36 lub 8.2.35 albo backport potwierdzony przez dostawcę.
- Czy zrestartowano wszystkie procesy PHP? Bez restartu aktualizacja nie działa.
- Co z systemami na PHP 8.1 lub starszym? Dla nich nie ma oficjalnych aktualizacji. Jaki jest plan?
- Czy sprawdzono, czy przed aktualizacją coś się wydarzyło? Logi od 20 października zabezpieczone, ślady poszukiwane?
Jeśli Państwa strona znajduje się u dostawcy hostingu, pomoże formalne zapytanie. Wzór oferuje poradnik Żądanie potwierdzenia aktualizacji PHP od dostawcy hostingu.
Decyzje, które powinny zapaść dziś
| Decyzja | Opcje | Podstawa |
|---|---|---|
| Kto prowadzi? | jedna osoba odpowiedzialna wewnętrznie, partner zewnętrzny | odpowiedzialność musi być jednoznaczna |
| Systemy niezałatane | załatać natychmiast, środki przejściowe, czasowo wyłączyć | zalecenie BSI, sytuacja danych, znaczenie dla obrotu |
| Sprawdzenie śladów | wewnętrznie, zewnętrznie, tylko przy nieprawidłowościach | zapotrzebowanie na ochronę danych na serwerze |
| Komunikacja | poinformować wewnętrznie, przygotować klientów, czekać | sytuacja po sprawdzeniu |
| Systemy stare | zaplanować migrację, odizolować, wyłączyć | PHP 8.1 i starsze bez oficjalnych aktualizacji |
Proszę zapisać, kto, kiedy i co zdecydował oraz na jakiej podstawie informacyjnej. Wystarcza krótka, opatrzona datą notatka. Jest ona później wobec ubezpieczycieli, klientów lub organów nadzoru często więcej warta niż każde późniejsze wyjaśnienie.
Dlaczego ta dokumentacja jest ważna dla kierownictwa, wyjaśnia strona Odpowiedzialność zarządu za luki w bezpieczeństwie IT. Jest to informacja ogólna, a nie porada prawna.
W co nie należy wierzyć
Trzy twierdzenia członkowie zarządów słyszą obecnie często i wszystkie trzy są fałszywe:
- „Zaktualizowaliśmy WordPressa, więc jesteśmy bezpieczni.” Luka tkwi w PHP, a nie w CMS. Aktualizacja CMS jej nie zamyka.
- „Jesteśmy za mali, nikt nas nie zaatakuje.” Ataki przebiegają zautomatyzowanie. Szuka się podatnych serwerów, a nie znanych nazw.
- „Aktualizacja jest zainstalowana, więc temat załatwiony.” Poprawka nie usuwa złośliwego oprogramowania wprowadzonego wcześniej i nie dowodzi, że nic się nie wydarzyło.
Jak konkretnie pomaga PHP SOS?
- Obraz sytuacji dla kierownictwa: Sporządzamy krótkie zestawienie Państwa systemów PHP ze statusem i zaleceniem dla każdego systemu.
- Wdrożenie: Łatamy, restartujemy lub wdrażamy środki przejściowe tam, gdzie aktualizacja nie jest jeszcze możliwa.
- Sprawdzenie: Zabezpieczamy logi i sprawdzamy ślady ataku.
- Dowód: Otrzymują Państwo dokumentację, której mogą Państwo użyć wewnętrznie i wobec osób trzecich.
Przebieg opisuje natychmiastowa pomoc przy PHP2Shell.
Podsumowanie
PHP2Shell to luka techniczna z zadaniem dla zarządzania. Technikę załatwiają fachowcy. Zarząd dba o to, aby ktoś był odpowiedzialny, aby pięć pytań otrzymało odpowiedź i aby decyzje zapadały świadomie i były udokumentowane. Mieści się to w jednym przedpołudniu, jeśli zacznie się dziś.
Częste pytania
Czy zarząd musi sam zajmować się PHP2Shell?
Realizacją techniczną nie, ale sterowaniem tak. Zarząd powinien zadbać o to, aby odpowiedzialności były jasne, zalecenie BSI (niemieckiego Federalnego Urzędu ds. Bezpieczeństwa w Technice Informatycznej) było wdrażane, a decyzje, takie jak czasowe wyłączenie, były podejmowane świadomie i dokumentowane.
Jak wyjaśnić tę lukę jednym zdaniem?
W PHP, oprogramowaniu, na którym działa większość stron i sklepów, są dwa krytyczne błędy, przez które obcy mogą bez hasła uruchamiać programy na serwerze; aktualizacja jest dostępna i trzeba ją zainstalować.
Ile kosztuje nicnierobienie?
Nie da się tego określić ogólnie. Możliwe skutki udanego ataku to przestoje, wyciek danych, obowiązki zgłoszeniowe, nakłady na oczyszczenie i analizę kryminalistyczną oraz utrata zaufania klientów. Aktualizacja ze sprawdzeniem jest zwykle znacznie mniej kosztowna.
Czy wystarczy, że zajmie się tym dostawca hostingu?
W hostingu współdzielonym aktualizację zwykle instaluje dostawca hostingu. Proszę kazać sobie to potwierdzić na piśmie, łącznie z restartem procesów PHP. Czy przed aktualizacją coś się wydarzyło, potwierdzenie nie rozstrzyga; do tego potrzebne jest sprawdzenie strony.