Krótko: Tydzień po pierwszej zaobserwowanej próbie ataku PHP2Shell jest aktualnie przede wszystkim kwestią wdrożenia: poprawki dla PHP od 8.2 do 8.5 są dostępne od 21 października, duże dystrybucje nadrobiły, a BSI ostrzega poziomem pomarańczowym. Zaobserwowano próby ataków, potwierdzonych udanych ataków na szeroką skalę BSI początkowo nie zgłosiło. Otwarte pozostają stare wersje, serwery bez restartu i pytanie, co działo się przed poprawką.
Sytuacja w trzech zdaniach
PHP2Shell to dwie krytyczne luki w samym interpreterze PHP, CVE-2026-109618 i CVE-2026-109619, każda oceniona na 9,2 w skali CVSS v4.0. Umożliwiają one zdalne wykonanie kodu bez logowania, czyli przypadek, którego specjaliści od bezpieczeństwa obawiają się najbardziej. Dotknięte są PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed; największe ryzyko widzi zespół PHP przy mod_php.
To zestawienie porządkuje stan na 25 października 2026 według uczestników. Przebieg dzień po dniu znajdą Państwo w chronologii PHP2Shell, tu chodzi o obraz całości.
Co jest udowodnione po tygodniu
Pewne są informacje projektu PHP: wydania 8.5.12, 8.4.27, 8.3.36 i 8.2.35 z 21 października zamykają obie luki. Dla PHP 7.4, 8.0 i 8.1 istnieją tylko minimalne backporty źródłowe, bez oficjalnych wydań. php.net podkreśla, że nie ma pełnych środków przejściowych, a aktualizacja jest jedyną bezpieczną drogą.
23 października doszła wskazówka dotycząca CVE-2026-115560. Dotyczy ona tylko nietypowej konfiguracji sesji; jako rozwiązanie php.net podaje session.upload_progress.enabled=0 do następnego regularnego wydania z poprawkami błędów.
Także duże dystrybucje zajęły stanowisko. Sprawdziliśmy oficjalne komunikaty:
| Dostawca | Stan według oficjalnego komunikatu |
|---|---|
| Ubuntu | USN-8948-1 dla 22.04, 24.04, 26.04 i 26.10; USN-8948-2 dla 14.04 do 20.04 przez Ubuntu Pro |
| Debian | Poprawione pakiety dla bookworm (php8.2, DLA-4848-1) i trixie (php8.4, DSA-6574-1) |
| Red Hat | Biuletyn RHSB-2026-013 dla RHEL 7 do 10; niektóre aktualizacje dostępne, kolejne w przygotowaniu |
Red Hat klasyfikuje CVE-2026-109618 własną oceną jako „Important” i uzasadnia to wyższą złożonością ataku. To inna metoda oceny niż ta stosowana przez projekt PHP i nie jest powodem, by odkładać aktualizację.
Jak urzędy oceniają sytuację
BSI ogłosiło poziom ostrzeżenia 3 / pomarańczowy. Zaleca natychmiastową aktualizację, a jeśli nie jest to możliwe od razu, czasowe odłączenie dotkniętych serwerów WWW od sieci. BSI spodziewało się szybkiego, szeroko zakrojonego wykorzystania. Co oznacza ta klasyfikacja, wyjaśnia strona Co BSI zaleca w sprawie PHP2Shell.
Według doniesień CERT-EU uważa za możliwe, że dotknięte są wersje od PHP 5, i radzi izolować publicznie dostępne aplikacje, jeśli nie da się ich załatać w krótkim czasie. CERT-Bund (zespół reagowania na incydenty niemieckiej administracji federalnej) oraz firma zajmująca się bezpieczeństwem Huntress również ostrzegali.
Zalecenie, by w razie potrzeby wyłączać, zostało widocznie wdrożone. Według doniesień medialnych miasto Moguncja prewencyjnie odłączyło swój centralny portal internetowy od sieci; urzędy pozostały osiągalne telefonicznie i mailowo. W Hesji były według hessenschau czasowo offline strony rządu krajowego, BKA (niemieckiego Federalnego Urzędu Kryminalnego) oraz miast Kassel i Wiesbaden. Kancelaria premiera nie zgłosiła ataku, strony były wieczorem znów dostępne. Kolejne gminy, uczelnie i kliniki postąpiły według doniesień podobnie.
Co wiadomo o atakach
Tu szczególnie ważne jest rozdzielenie obserwacji od potwierdzenia.
- Zaobserwowane: Według doniesień medialnych 17 października doszło do pierwszej próby ataku, którą zaobserwował Amazon. Cloudflare i Patchstack informowali o próbach ataków; Cloudflare widział ponadto zmienione wzorce ataków.
- Odtworzone: watchTowr odtworzył według doniesień CVE-2026-109618 według własnych informacji.
- Niepotwierdzone: BSI początkowo nie zgłosiło potwierdzonych udanych wykorzystań na szeroką skalę. Huntress w chwili swojego zgłoszenia nie widział ataków w środowiskach partnerów.
- Nieznane: Nie ma opublikowanych, potwierdzonych wskaźników naruszenia (Indicators of Compromise). Kto chce sprawdzić, czy serwer został dotknięty, musi zwracać uwagę na wzorce zachowania.
O skali krążą dwie liczby. Badacze z Unit 42 w Palo Alto Networks doszli do ponad 22,6 miliona potencjalnie podatnych instancji osiągalnych z sieci. CybelAngel podaje około 2,24 miliona osiągalnych hostów PHP, z czego według własnej analizy 59 procent na wersjach bez nadchodzącej oficjalnej poprawki. Obie liczby mierzą różne rzeczy i nie są bezpośrednio porównywalne. Ocenę przedstawia artykuł Jak właściwie ocenić liczby.
Co pozostaje otwarte
Trzy pytania określają najbliższe tygodnie:
- Stare wersje: Duża część osiągalnych instalacji PHP działa według wspomnianych analiz na gałęziach bez oficjalnej poprawki. Czy komercyjne oferty długoterminowego wsparcia obejmują PHP2Shell, trzeba każdorazowo kazać potwierdzić dostawcy na piśmie.
- Niepełne aktualizacje: Nowe pakiety działają dopiero po zrestartowaniu wszystkich procesów PHP. Red Hat wyraźnie wskazuje, że samo przeładowanie nie wystarcza.
- Czas przed poprawką: Między 17 a 21 października serwery były podatne, podczas gdy trwały już próby ataków. Poprawka nie dowodzi, że w tym czasie nic się nie wydarzyło.
Proszę przechowywać logi serwera WWW i PHP od 20 października, jak zaleca prasa branżowa. Bez logów najważniejszego otwartego pytania dla Państwa serwera nie da się później rozstrzygnąć.
Co operatorzy powinni teraz sprawdzić
Do własnej oceny sytuacji wystarczą cztery punkty kontrolne dla każdego serwera: Czy PHP jest w naprawionym stanie lub z potwierdzonym backportem? Czy wszystkie procesy działają od czasu aktualizacji? Czy session.upload_progress.enabled jest wyłączone po stronie serwera, dopóki nie ukaże się advisory do CVE-2026-115560? Czy od 17 października są jakieś nieprawidłowości?
Przy ostatnim punkcie pomaga strona Czy już doszło do naruszenia?. Proces serwera WWW uruchamiający powłokę, nowe pliki PHP w katalogach przesyłania, nieznane zadania cron lub klucze SSH to sygnały ostrzegawcze, które uzasadniają dokładniejsze badanie.
Jak konkretnie pomaga PHP SOS?
- Oceniamy stan poprawek każdego serwera na podstawie stanu pakietów, changelogu i czasów startu procesów.
- Tam, gdzie poprawka nie jest dostępna, wdrażamy środki przejściowe z php.net i wyjaśniamy drogę do wspieranej wersji.
- Zabezpieczamy logi od 20 października i szukamy śladów z czasu przed poprawką.
- Dzięki natychmiastowej pomocy przy PHP2Shell łączymy te kroki dla firm, które potrzebują szybkiej jasności.
Częste pytania
Czy PHP2Shell jest już aktywnie wykorzystywane?
Cloudflare i Patchstack informowali o próbach ataków. Potwierdzonych udanych ataków na szeroką skalę BSI początkowo nie zgłosiło. Huntress w chwili swojego zgłoszenia nie widział ataków w środowiskach partnerów.
Czy po poprawkach zagrożenie minęło?
Nie. Poprawki chronią tylko serwery, które je zainstalowały i zrestartowały wszystkie procesy PHP. Systemy z PHP 8.1 i starszym pozostają bez potwierdzonego backportu podatne, a poprawka nie usuwa wcześniej wprowadzonego złośliwego oprogramowania.
Dlaczego strony urzędów były offline?
Według doniesień medialnych między innymi miasto Moguncja i kilka instytucji w Hesji prewencyjnie wyłączyło swoje strony. Odpowiada to zaleceniu BSI (niemieckiego Federalnego Urzędu ds. Bezpieczeństwa w Technice Informatycznej) dla serwerów, których nie da się od razu zaktualizować. Wyłączenie nie oznacza, że doszło do ataku.
Czy istnieją cechy rozpoznawcze ataku PHP2Shell?
Opublikowanych, potwierdzonych wskaźników naruszenia (Indicators of Compromise) dotąd nie ma. Wykrywanie opiera się na analizie zachowania, na przykład procesów PHP uruchamiających powłokę lub nowych plików PHP w katalogach przesyłania.