Krótko: Do udowodnionych faktów o PHP2Shell należą oba numery CVE, ocena 9,2 w skali CVSS v4.0, naprawione wersje PHP oraz środki przejściowe z php.net. Udowodniony jest też poziom ostrzeżenia pomarańczowy BSI. Nieudowodnione są ocena CVSS 10, potwierdzone udane ataki na szeroką skalę oraz lista cech rozpoznawczych. Kto rozdziela te trzy poziomy, podejmuje lepsze decyzje.
Dlaczego potrzebne jest sprawdzenie faktów o PHP2Shell
Rzadko która luka bezpieczeństwa ostatnich lat wywołała tak szybko tak wiele nagłówków. Jeszcze zanim zespół PHP opublikował aktualizacje 21 października 2026, krążyły według doniesień wpisy na forach, zrzuty ekranu i rzekome szczegóły. Potem pojawiły się ostrzeżenia urzędów, blogi producentów, zestawienia wystawionych serwerów i lawina porad.
Dla operatorów oznacza to: nie każda liczba i nie każda rada ma tę samą jakość. Część pochodzi ze źródeł pierwotnych, część z rzetelnych relacji, część ze spekulacji. Ten artykuł porządkuje, z czego można korzystać jako z pewnego przy podejmowaniu decyzji. Podstawy samej luki wyjaśnia strona Czym jest PHP2Shell?.
Jaką wagę mają poszczególne źródła
Przy czytaniu każdego komunikatu pomaga prosta hierarchia:
- php.net: Projekt PHP jest źródłem pierwotnym numerów CVE, ocen, dotkniętych trybów pracy, naprawionych wersji i środków przejściowych. Jak projekt traktuje komunikaty bezpieczeństwa w ogóle, opisuje nasz artykuł o procesie bezpieczeństwa PHP.
- Urzędy: BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej) dostarcza ocenę sytuacji w Niemczech i zalecenia działań, uzupełniają go CERT-EU i CERT-Bund (zespół reagowania na incydenty niemieckiej administracji federalnej).
- Dystrybucje i dostawcy: Debian, Ubuntu, Red Hat, dostawcy hostingu i usług platformowych wypowiadają się wiążąco wyłącznie o własnych pakietach i usługach.
- Firmy zajmujące się bezpieczeństwem: Cloudflare, Unit 42, CybelAngel i inni relacjonują na podstawie własnych pomiarów. Wartościowe, ale każdorazowo z własną metodą.
- Media i sieci społecznościowe: Dobre pod względem tempa, słabe w szczegółach. Wypowiedzi stamtąd wymagają potwierdzenia wyżej w hierarchii.
Udowodnione, zgłoszone, nieudowodnione: zestawienie
Poniższa tabela porządkuje najczęstsze twierdzenia. „Udowodnione” oznacza: źródło pierwotne lub urząd. „Zgłoszone” oznacza: z mediów lub od producentów, niepotwierdzone niezależnie.
| Twierdzenie | Ocena | Podstawa |
|---|---|---|
| Dwie luki, CVE-2026-109618 i CVE-2026-109619 | udowodnione | php.net |
| Ocena CVSS v4.0 9,2, krytyczna | udowodnione | php.net |
| Ocena CVSS 10 | nie do utrzymania | według doniesień z wpisu na forum sprzed zgłoszenia |
| Naprawione w 8.5.12, 8.4.27, 8.3.36, 8.2.35 | udowodnione | php.net |
| mod_php z najwyższym ryzykiem, exploit pokazany przed kodem aplikacji | udowodnione | php.net |
| Dotknięte niemal wszystkie wersje aż do PHP 5.4 | zgłoszone | prasa branżowa |
| Pierwsza próba ataku 17.10. | zgłoszone | doniesienia medialne powołujące się na Amazon |
| Ponad 22,6 mln wystawionych instancji | zgłoszone | Unit 42, według TechTarget |
| Udane ataki na szeroką skalę | nieudowodnione | według BSI początkowo nieznane |
| Potwierdzone wskaźniki naruszenia (Indicators of Compromise) | nie istnieją | brak publikacji |
| Środki przejściowe chronią w pełni | fałsz | php.net wyraźnie określa je jako niepełne |
Uderzające jest, jak wcześnie liczby zaczynają żyć własnym życiem. Ocena 10.0 z wpisu na forum pojawiała się jeszcze po kilku dniach w artykułach, choć zespół PHP dawno opublikował 9,2.
Gdzie naprawdę leży niepewność
Największe otwarte pytanie nie jest techniczne, lecz czasowe: co wydarzyło się między pierwszą zgłoszoną próbą ataku a poprawką na poszczególnych serwerach? Nie ma na to ogólnej odpowiedzi. Cloudflare i Patchstack zgłosiły próby ataków, watchTowr odtworzył według własnych informacji CVE-2026-109618. Huntress z kolei w chwili swojego zgłoszenia nie widział ataków w środowiskach partnerów.
Te wypowiedzi nie przeczą sobie. Opisują różne wycinki: duży serwis proxy, firmę zajmującą się bezpieczeństwem wtyczek, zespół badawczy i firmę z własną bazą klientów. Z tego nie powstaje obraz całości.
Podobnie z pytaniem, które wersje są dotknięte. Dla 8.2 do 8.5 sytuacja jest jasna. Dla starszych gałęzi istnieją minimalne backporty źródłowe dla 7.4, 8.0 i 8.1, ale nie ma oficjalnych wydań. To, co jest starsze, jest według prasy branżowej dotknięte prawie bez wyjątku. Dla Państwa planowania nie ma to większego znaczenia: serwer z PHP 8.1 lub starszym bez potwierdzonego backportu należy traktować jako zagrożony.
Brak dowodów ataków nie jest dowodem bezpieczeństwa. Ponieważ nie ma potwierdzonych cech rozpoznawczych, atak na pojedynczy serwer można ocenić tylko przez sprawdzenie zachowania, a nie na podstawie listy.
Co z tego wynika dla Państwa serwerów
Z udowodnionych faktów wynika kilka jasnych kroków. Z nieudowodnionych wynika przede wszystkim ostrożność.
- Sprawdzić stan poprawek: naprawiona wersja lub backport potwierdzony przez dostawcę. Samo wyświetlane oznaczenie wersji nie wystarcza.
- Zrestartować wszystkie procesy PHP: Nowe pliki działają dopiero wtedy, gdy nie ma już starych procesów.
- Zabezpieczyć logi od 20.10.: Prasa branżowa zaleca to, aby późniejsza analiza pozostała możliwa.
- Sprawdzić ślady: Nowe pliki PHP w katalogach przesyłania, nieznane zadania cron, procesy serwera WWW z powłoką. Sprawdzenie przeprowadzi Państwa strona Czy już doszło do naruszenia?.
- Weryfikować porady: Wskazówki z forów i sieci społecznościowych wdrażać tylko wtedy, gdy da się je sprowadzić do php.net lub urzędu. Które zalecenia obecnie szkodzą, zbiera artykuł Niebezpieczne fałszywe porady dotyczące PHP2Shell.
W komunikacji wewnętrznej pomaga ten sam podział. Kto przedstawia zarządowi osobno „udowodnione”, „zgłoszone” i „otwarte”, unika zarówno alarmizmu, jak i fałszywego uspokojenia.
Jak konkretnie pomaga PHP SOS?
- Sytuacja dla Państwa systemów: Przenosimy udowodnione fakty na Państwa serwery i w dokumentacji oddzielamy to, co zmierzone, co zgłoszone i co otwarte.
- Poprawka i dowód: Sprawdzamy stan pakietów i restart każdej usługi PHP oraz zapisujemy to na piśmie.
- Sprawdzenie śladów: Zabezpieczamy logi od 20 października i szukamy nietypowych zachowań, aż incydent zostanie zamknięty i udokumentowany.
- Bieżąca ocena: Nowe komunikaty oceniamy dla Państwa, zanim zamienią się w działania.
Przebieg opisuje natychmiastowa pomoc przy PHP2Shell.
Podsumowanie
PHP2Shell jest poważne i jest to dobrze udokumentowane. Właśnie dlatego warto spojrzeć trzeźwo: źródła pierwotne wystarczą do wszystkich ważnych decyzji. To, co krąży poza nimi, jest często szybsze niż dokładne. Załatać, zrestartować, zabezpieczyć logi i sprawdzić ślady pozostaje odpowiedzią, niezależnie od tego, jaka liczba akurat krąży.
Częste pytania
Czy PHP2Shell ma ocenę CVSS 10?
Nie. Liczba 10 pochodzi według doniesień z wpisu na forum, który krążył przed oficjalnym zgłoszeniem. Zespół PHP ocenia obie luki na 9,2 w skali CVSS v4.0. To mimo to kategoria krytyczna.
Czy istnieje lista cech rozpoznawczych ataków PHP2Shell?
Jak dotąd nie. Nie opublikowano potwierdzonych wskaźników naruszenia (Indicators of Compromise). Kto chce sprawdzić, czy serwer był dotknięty, musi zwracać uwagę na nietypowe zachowania, na przykład procesy serwera WWW uruchamiające powłokę albo nowe pliki PHP w katalogach przesyłania.
Które źródło jest przy PHP2Shell najbardziej wiarygodne?
Dla faktów technicznych komunikaty na php.net, dla oceny sytuacji w Niemczech BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej). Doniesienia medialne i blogi producentów uzupełniają obraz, ale należy oznaczać je jako doniesienia i czytać w zestawieniu ze źródłem pierwotnym.
Czy rzeczywiście dotknięte są wszystkie wersje PHP od PHP 5?
Udowodniona jest sytuacja dla gałęzi od 8.2 do 8.5, dla których istnieją aktualizacje. Według prasy branżowej dotknięte są niemal wszystkie wersje aż do PHP 5.4; CERT-EU uważał według doniesień za możliwe, że dotknięte są wersje od PHP 5. Dla starszych wersji nie ma oficjalnych aktualizacji, dlatego w każdym przypadku należy traktować je jako zagrożone.