Pod koniec ubiegłego tygodnia światem – nie tylko jego częścią zajmującą się cyberbezpieczeństwem – wstrząsnęła wiadomość o krytycznych podatnościach w silniku PHP. Setki stron (chwilowo) znikały z internetu, firmy wysyłały maile o tymczasowym ograniczeniu funkcjonalności swoich serwisów, niektóre nagłówki krzyczały o ryzykach zagrażających większości internetu. O co tak naprawdę chodziło?
Zacznijmy od wyjaśnienia dla zwykłego internauty. Czym tak naprawdę jest PHP? To język programowania, którego działanie można porównać do restauracyjnej kuchni. Ciebie interesuje potrawa, którą chcesz zjeść. Ale po to, by powstała, trzeba znaleźć produkty, przetworzyć je, odpowiednio połączyć i wreszcie podać w atrakcyjnej formie na Twoim talerzu.
Przychodząc do restauracji, nie musisz zaglądać do kuchni. Wchodząc na stronę internetową, nie musisz „kuchni” widzieć. PHP działa na serwerze i z niego – nomen omen – serwuje dla Ciebie ostateczną formę strony. Ile „restauracji” w internecie korzysta z takiej „kuchni”? Według najnowszego odczytu W3Techs (29.10.26) PHP jest wykorzystywany przez 69,2% stron, których język programowania po stronie serwera udało się rozpoznać.
Co się stało 21 października?
21 października 2026 zespół PHP opublikował aktualizacje usuwające dwie krytyczne podatności określane jako PHP2Shell. Pozwalały one na zdalne wykonanie kodu bez uwierzytelnienia, czyli bez konieczności zalogowania się, przez co otrzymały ocenę 9,2 (na 10) w CVSS v4.0 (CVSS to system oceniania powagi podatności w zabezpieczeniach). Luka umożliwiająca zdalne wykonanie kodu (RCE) może pozwolić atakującemu uruchamiać własne polecenia na podatnym urządzeniu lub serwerze przez sieć. W praktyce może to doprowadzić do kradzieży albo zmiany danych, instalacji złośliwego oprogramowania lub przejęcia kontroli nad systemem. Zagrożenie dotyczy samego PHP, dlatego może obejmować również aplikacje, których kod nie zawiera podatności.
Co ciekawe, opisane luki są w PHP od bardzo dawna, ale nikt nie miał świadomości ich istnienia! Skąd zatem ich nagłe upublicznienie (po wypuszczeniu łaty bezpieczeństwa)? Wykryły je rozbudowane modele sztucznej inteligencji. Czy to oznacza, że nagle przeszło 2/3 internetu stało się dostępne dla ludzi o złych zamiarach? Nie. Sam fakt istnienia luki to nie wszystko, do jej wykorzystania niezbędny jest exploit, czyli odpowiednio przygotowany złośliwy kod. W momencie publikacji tego materiału nie istniał uniwersalny exploit. Według komunikatu z 28.10 Wordfence nie znał potwierdzonych przypadków przejęcia witryn WordPress (najpopularniejszy silnik CMS w internecie) przez PHP2Shell. Jeśli przestępca chce włamać się do konkretnego systemu, musi przygotować kod pod specyfikę konkretnej wersji PHP, oprogramowania na serwerze i wielu innych zmiennych.
Czy trzeba łatać systemy? Absolutnie tak! Czy to oznacza, że nagle przestępcy przejmą większość internetu? Jeszcze nie.
Czego dotyczą podatności?
Przyjrzyjmy się podatnościom od strony bardziej technicznej. Pierwsza z nich, CVE-2026-109618, dotyczy nieprawidłowej obsługi wyczerpania pamięci (out of memory, OOM). Przerwanie operacji może pozostawić częściowo zainicjalizowane struktury danych, które PHP następnie potraktuje jako prawidłowe podczas kończenia obsługi żądania. CVE-2026-109619 wiąże się natomiast z zachowaniem odwołań do pamięci zwolnionej po zakończeniu żądania. Gdy ten sam proces obsłuży kolejne żądanie, może ponownie użyć tej pamięci przed zresetowaniem swojego stanu. Powstaje wówczas błąd typu use-after-free, czyli użycia zwolnionej pamięci. Skutki nie ograniczają się do wykonania kodu. Wiz potwierdził również możliwość odczytu pamięci procesu PHP, która może zawierać hasła, tokeny uwierzytelniające czy klucze API.
Zakres podatnych wydań sięga PHP 5.4. Badacze potwierdzili możliwość wykonania kodu bez uwierzytelnienia w środowiskach obsługujących m.in. WordPress, Joomla, Magento i phpMyAdmin. Skuteczność poszczególnych wariantów ataku zależy jednak od wersji PHP, konfiguracji i sposobu działania aplikacji. Zespół PHP ocenia ryzyko jako najwyższe dla Apache z modułem mod_php, gdzie potwierdzony atak może nastąpić przed wykonaniem kodu aplikacji. PHP-FPM również nie wyklucza zagrożenia – zweryfikowana w tym środowisku ścieżka RCE wymaga jednak odpowiedniej operacji po stronie aplikacji. Sama aktualizacja CMS-a lub jego wtyczek nie usuwa błędów w PHP.
Jak wspominaliśmy wyżej, skuteczne i powtarzalne wykorzystanie PHP2Shell wymaga jednak dostosowania exploita do konkretnego środowiska. Znaczenie mają m.in. sposób kompilacji PHP, zainstalowane rozszerzenia, konfiguracja serwera oraz układ pamięci procesu. Poprawki opublikowane 21 października 2026 r. są dostępne w wydaniach PHP 8.2.35, 8.3.36, 8.4.27 i 8.5.12. W przypadku pakietów dystrybucyjnych należy sprawdzić komunikat dostawcy, który może udostępnić poprawkę również dla starszego wydania PHP jako backport.
Dwa dni później PHP poinformował o kolejnej podatności, oznaczonej jako CVE-2026-115560. Problem dotyczy mechanizmu śledzenia postępu przesyłania plików i wymaga nietypowego połączenia konfiguracji z zachowaniem aplikacji. Zespół PHP ocenia wystąpienie takiej kombinacji jako mało prawdopodobne w praktyce, dlatego zapowiedział usunięcie luki w kolejnym regularnym wydaniu zamiast publikacji aktualizacji awaryjnej.
Więcej informacji na temat PHP2Shell – w tym szczegóły na temat zarządzania podatnościami – znajdziesz w najnowszym wydaniu naszego Krajobrazu Zagrożeń.
Okiem eksperta
Tym razem problem nie leży w samej aplikacji, ale piętro niżej – w języku programowania. A to szczególnie kłopotliwa sytuacja, bo według różnych szacunków PHP to 60–70% stron internetowych. Podatność, która pozwala atakującemu wykonać dowolny kod na serwerze, ma więc katastrofalny zasięg.
Co ciekawe, błąd tkwił w kodzie PHP przez niemal 15 lat. I niestety, musimy się przyzwyczaić, że wraz z rozwojem możliwości LLM-ów coraz więcej takich trupów będzie wypadać z szafy. Błędy, które przez lata pozostawały nieodkryte albo uznawano je za niemożliwe do wykorzystania, mogą nagle okazać się krytycznymi podatnościami o globalnym zasięgu.
Tym razem PHP2Shell nie jest magicznym wytrychem do każdego serwera z PHP. Skuteczne wykorzystanie tej podatności wymaga spełnienia określonych warunków. Można potraktować tę sytuację jako moment do refleksji i przećwiczenie kryzysowych procedur patchowania. Może to być wyzwanie szczególnie dla administratorów, którzy właśnie odkryją, ile mają serwerów z PHP, o których istnieniu zdążyli już zapomnieć.
Tekst Michał Rosiak
Analiza szczegółowa Natalia Urbanowicz
Opinia eksperta Piotr Zarzycki
