Krytyczne luki PHP z oceną 9,2/10 - Sprawdź swoje sklepy, strony internetowe!

Nie podoba mi się to że nasz blog zamienia się w ścianę dramatu. Niestety ale muszę opublikować kolejny post o bardzo negatywnym wydźwięku. Tym razem luka dotyczy praktycznie wszystkich najpopularniejszych platform na świecie, w Polsce, opensource, SaaS. 

W ostatnim poście, który ukazał się we wrześniu, informowałem Was o poważnej luce w samym rdzeniu WordPressa (CVE-2026-87902 w WordPressie – krytyczna luka w Core. Kogo dotyczy i jak ją naprawić?). W tym samym miesiącu pisałem również o podatności w Page Builderze (Używasz SP Page Builder na swojej Joomla? Zmów paciorek) dla systemu Joomla. Z kolei w lipcu pisałem o luce bezpieczeństwa, również w WordPressie (Krytyczne podatności WordPress CVE-2026-63030 i CVE-2026-60137 – co musisz wiedzieć i jak się zabezpieczyć).

Tak jak wspominałem poprzednio, czeka nas teraz fala wykrywania kolejnych podatności - moje obawy potwierdzają się w postaci kolejnych naprawdę krytycznych zgłoszeniach. Podczas gdy my dbamy o rozwój i rozbudowę oprogramowania, druga strona – wykorzystując sztuczną inteligencję – szuka dziur, aby włamać się do systemów. Będziemy teraz powoli spłacać dług technologiczny, który objawi się notorycznym wykrywaniem i łataniem błędów. Nie wiem, jak długo to potrwa, ale cały internet, włączając w to platformy, systemy CMS, języki programowania w tym PHP, muszą zostać przebudowany i zabezpieczony na zupełnie nowym poziomie.

Dwie poważne podatności bezpieczeństwa w PHP, ocenione na 9,2 punktu w dziesięciostopniowej skali CVSS, postawiły administratorów serwerów i dostawców usług hostingowych w stan podwyższonej gotowości. Problem może dotyczyć milionów stron internetowych, w tym witryn WordPress, Joomla oraz sklepów WooCommerce, OpenCart i PrestaShop. Co właściwie się wydarzyło, na czym polega zagrożenie i czy właściciele stron internetowych powinni się obawiać?

21 października 2026 roku twórcy PHP opublikowali pilne poprawki bezpieczeństwa usuwające dwie krytyczne podatności oznaczone jako CVE-2026-109618 oraz CVE-2026-109619 . Obie otrzymały ocenę 9,2/10 w skali CVSS 4.0, co oznacza zagrożenie o najwyższym stopniu krytyczności.

Luki, określane wspólną nazwą PHP2Shell , mogą w określonych warunkach pozwolić atakującemu na zdalne wykonanie kodu na serwerze bez konieczności logowania.

Co szczególnie niepokojące, pierwsze próby wykorzystania tych podatności miały być obserwowane jeszcze przed oficjalnym udostępnieniem aktualizacji.

Sama publikacja poprawek również miała nietypowy przebieg. Początkowo planowano ją na 22 października. Jednak 20 października informacje o identyfikatorach obu podatności zaczęły krążyć w internecie. Zespół PHP zdecydował się przyspieszyć publikację o jeden dzień.

Od 21 października dostępne są już poprawione wydania PHP 8.2, 8.3, 8.4 oraz 8.5.

Nie oznacza to, że wszystkie strony internetowe zostały automatycznie zabezpieczone. Aktualizacje muszą jeszcze zostać wdrożone przez administratorów serwerów i dostawców usług hostingowych.

Co istotne, tym razem problem nie dotyczy konkretnej wtyczki WordPressa, rozszerzenia Joomla czy modułu sklepu internetowego. Dotyczy samego interpretera PHP – oprogramowania odpowiedzialnego za wykonywanie kodu PHP na serwerze.

I właśnie dlatego zagrożenie może mieć tak szeroki zasięg.

 

Czym właściwie jest PHP i dlaczego używają go miliony stron?

Zanim przejdziemy do podatności, warto zrozumieć, jaką rolę PHP pełni w działaniu współczesnych stron internetowych.

Wyobraźmy sobie restaurację.

Klient siada przy stoliku, przegląda menu i zamawia obiad. Kelner przekazuje zamówienie do kuchni, kucharz przygotowuje posiłek, a gotowe danie trafia z powrotem do klienta.

Podobnie działa strona internetowa.

Uproszczona analogia działania dynamicznej strony internetowej.

W tym porównaniu:

• Klient to internauta odwiedzający stronę.

• Kelner to serwer WWW, który przyjmuje żądanie.

• Kucharz to interpreter PHP, wykonujący instrukcje aplikacji.

• Przepis to kod WordPressa, Joomla, OpenCart lub innego systemu CMS.

• Spiżarnia to baza danych, z której aplikacja pobiera informacje.

Kiedy otwieramy stronę produktu w sklepie internetowym, serwer musi często pobrać z bazy danych nazwę produktu, jego cenę, zdjęcia, dostępność i inne informacje. Kod aplikacji PHP przetwarza te dane i przygotowuje odpowiedź dla przeglądarki.

Cały proces zajmuje zazwyczaj ułamki sekundy.

A teraz wyobraźmy sobie, że ktoś odkrywa poważny błąd w sposobie działania samej kuchni.

Nie w przepisie na zupę, nie w menu, ale w urządzeniu, z którego korzystają wszyscy kucharze.

Właśnie z podobną sytuacją możemy mieć obecnie do czynienia.

 

CVE-2026-109618 i CVE-2026-109619 – na czym polega problem?

Podatności zidentyfikowane jako CVE-2026-109618 i CVE-2026-109619 mogą potencjalnie prowadzić do zdalnego wykonania kodu, czyli Remote Code Execution (RCE).

Jest to jedna z najpoważniejszych kategorii zagrożeń w bezpieczeństwie aplikacji internetowych.

Wróćmy do naszej restauracji.

Normalnie klient może zamówić wyłącznie potrawy znajdujące się w menu. Może poprosić o pizzę, zupę albo deser. Nie ma jednak prawa wejść do kuchni i wydawać kucharzowi własnych poleceń.

Wyobraźmy sobie teraz, że wskutek błędu w urządzeniu obsługującym zamówienia klient potrafi przesłać specjalnie przygotowaną wiadomość, która nie zostaje potraktowana jak zwykłe zamówienie, lecz jak instrukcja dla kuchni.

Zamiast przygotowania obiadu urządzenie mogłoby wykonać coś zupełnie innego.

W świecie serwerów taką sytuację można porównać do nieautoryzowanego uruchomienia instrukcji przez oprogramowanie.

To właśnie istota zagrożenia RCE.

 

PHP2Shell – dwa błędy, dwa różne mechanizmy

Po publikacji poprawek poznaliśmy już techniczne przyczyny obu podatności. Okazało się, że dotyczą one dwóch niezwykle ważnych elementów pracy PHP: zarządzania pamięcią oraz obsługi kolejnych żądań przesyłanych do serwera.

Wyjaśnijmy je na przykładzie naszej restauracji.

CVE-2026-109618 – kucharz, któremu zabrakło miejsca na blacie

Wyobraźmy sobie, że kucharz otrzymuje bardzo skomplikowane zamówienie. Przygotowuje kolejne składniki, ale w pewnym momencie na blacie kończy mu się miejsce.

Prawidłowo działający kucharz powinien przerwać przygotowanie posiłku, odłożyć niedokończone elementy i bezpiecznie uporządkować stanowisko.

Tymczasem nasz kucharz popełnia błąd. Zostawia niekompletny składnik, ale oznacza go tak, jakby był już gotowy do użycia.

Kiedy zaczyna sprzątać stanowisko, traktuje ten nieprawidłowy element jak pełnoprawną część przygotowywanego dania.

W PHP dochodziło do podobnej sytuacji.

Gdy interpreterowi kończyła się przydzielona pamięć w wyjątkowo niekorzystnym momencie, mógł pozostawić niekompletne struktury danych. Podczas późniejszego porządkowania pamięci traktował je jednak tak, jakby były prawidłowe.

Atakujący mógł próbować wykorzystać ten błąd, aby doprowadzić do wykonania własnego kodu.

Co szczególnie istotne, w przypadku serwera Apache z modułem mod_php wykazano możliwość przeprowadzenia ataku, zanim PHP rozpocznie wykonywanie właściwego kodu strony internetowej.

 

CVE-2026-109619 – kucharz korzystający z notatek poprzedniego klienta

Druga podatność jest nieco inna.

Wyobraźmy sobie, że kucharz kończy przygotowywać zamówienie i wyrzuca notatki, które były mu potrzebne. Następnie rozpoczyna pracę nad daniem dla kolejnego klienta.

Problem polega na tym, że część wskazówek nadal odwołuje się do starych, wyrzuconych notatek.

Kucharz próbuje więc wykorzystać informacje, które nie powinny już istnieć.

W informatyce ten rodzaj błędu nazywa się Use-After-Free , czyli wykorzystaniem pamięci po jej zwolnieniu.

W PHP problem mógł wystąpić, gdy błąd krytyczny pozostawiał nieprawidłowy stan wewnętrzny procesu. Kolejne żądanie obsługiwane przez ten sam proces mogło następnie skorzystać z danych pozostałych po poprzednim żądaniu.

W określonych warunkach również ten błąd mógł doprowadzić do zdalnego wykonania kodu.

 

Dlaczego jest to aż tak poważne?

Ponieważ oba błędy występują na bardzo niskim poziomie działania PHP.

Można powiedzieć, że problem nie znajduje się w przepisie kucharza, ale w jego sposobie organizowania i wykonywania pracy.

Dlatego nawet perfekcyjnie napisany WordPress, Joomla czy OpenCart nie jest w stanie samodzielnie naprawić błędu występującego wewnątrz interpretera PHP.

 

Dlaczego podatność w PHP jest groźniejsza niż błąd w pojedynczej wtyczce?

To zasadnicza różnica, którą warto dobrze zrozumieć.

Załóżmy, że w sklepie internetowym odkryto lukę bezpieczeństwa w module galerii zdjęć.

Problem dotyczy wówczas określonego oprogramowania. Administratorzy sklepów, które nie korzystają z tego modułu, zazwyczaj nie muszą wykonywać żadnych działań związanych z tą konkretną podatnością.

Jeżeli jednak problem dotyczy interpretera PHP, sytuacja jest zupełnie inna.

Z PHP korzysta ogromna liczba systemów zarządzania treścią, platform sprzedażowych, aplikacji biznesowych i autorskich rozwiązań internetowych.

Możemy mieć więc trzy zupełnie różne strony:

• Sklep internetowy pracujący na OpenCart.

• Stronę firmową zbudowaną na Joomla.

• Portal informacyjny działający na WordPressie.

Każda została napisana przez inny zespół programistów. Każda posiada inną architekturę, inne funkcje i inny zestaw rozszerzeń.

Ale wszystkie mogą korzystać z tego samego interpretera PHP.

Wróćmy do porównania z restauracją.

To tak, jakby trzy zupełnie różne restauracje korzystały z tego samego modelu wadliwego pieca. Każda może mieć znakomitych kucharzy, doskonałe przepisy i wzorowo utrzymaną kuchnię.

Jeśli wada występuje w piecu, jakość przepisów nie rozwiąże problemu.

Podobnie aktualny WordPress, Joomla czy OpenCart nie naprawi samodzielnie błędu występującego w interpreterze PHP.

To nie oznacza, że aktualizacje CMS są niepotrzebne. Przeciwnie – nadal stanowią jeden z fundamentów bezpieczeństwa. Po prostu chronią inną warstwę oprogramowania.

 

Czy każdy serwer PHP jest tak samo zagrożony?

Nie wszystkie serwery uruchamiają PHP w identyczny sposób.

Na jednym serwerze interpreter PHP może działać jako moduł Apache. Na innym jako osobny proces obsługiwany przez PHP-FPM. Jeszcze inne środowisko może wykorzystywać LiteSpeed, FrankenPHP lub dodatkowe warstwy pośredniczące.

Wróćmy na chwilę do naszej restauracji.

W jednej kuchni kucharz pracuje samodzielnie i przyjmuje wszystkie zamówienia bezpośrednio od kelnera. W innej restauracji działa osobny dział przyjmowania zamówień, który przekazuje je odpowiednim kucharzom.

Obie restauracje przygotowują posiłki, ale sposób organizacji pracy jest inny.

Podobnie jest z PHP.

Najwyższe ryzyko potwierdzono w przypadku serwerów Apache korzystających z modułu mod_php .

Badacze wykazali, że w takiej konfiguracji możliwe było wykorzystanie podatności CVE-2026-109618 jeszcze przed uruchomieniem kodu aplikacji. Co więcej, udało się to zademonstrować przy domyślnych ustawieniach środowiska.

Nie oznacza to jednak, że pozostałe konfiguracje są całkowicie bezpieczne.

Oficjalny komunikat PHP wskazuje, że zagrożone mogą być również środowiska wykorzystujące PHP-FPM, php-cgi , LiteSpeed i FrankenPHP.

W ich przypadku warunki skutecznego ataku mogą być inne. Część scenariuszy wymaga określonego zachowania aplikacji lub dodatkowych okoliczności.

Nie warto więc zakładać, że sama obecność PHP-FPM albo serwera LiteSpeed rozwiązuje problem.

Zalecenie twórców PHP jest jednoznaczne: wszystkie środowiska PHP obsługujące żądania internetowe powinny otrzymać odpowiednie aktualizacje bezpieczeństwa.

 

 

 być konsekwencje wykorzystania podatności?

Jeżeli rzeczywiście okaże się, że nowe luki pozwalają na zdalne wykonanie kodu, potencjalne konsekwencje mogą być bardzo poważne.

Atakujący mógłby, w zależności od warunków technicznych i uprawnień procesu PHP, próbować:

• Uzyskać dostęp do danych – na przykład informacji przechowywanych w bazie danych strony lub sklepu.

• Zmodyfikować zawartość serwisu – podmienić treści, przekierowania lub wprowadzić złośliwy kod.

• Umieścić dodatkowe oprogramowanie – umożliwiające dalsze nieautoryzowane działania.

• Zakłócić działanie strony – doprowadzić do niedostępności wybranych funkcji lub całego serwisu.

• Wykorzystać zasoby serwera – o ile pozwoli na to konfiguracja i uprawnienia środowiska.

Nie oznacza to jednak, że każde skuteczne RCE automatycznie daje pełne prawa administratora serwera.

Dobrze skonfigurowane środowisko może ograniczać uprawnienia procesu PHP, izolować poszczególne konta hostingowe oraz utrudniać dostęp do innych zasobów.

Są to ważne zabezpieczenia zmniejszające potencjalne skutki incydentu, choć nie zastępują usunięcia samej podatności.

 

Czy hakerzy już wykorzystują PHP2Shell? Pierwsze próby odnotowano przed publikacją poprawek

Niestety nowe podatności PHP przestały być wyłącznie problemem teoretycznym.

Według informacji opublikowanych przez Datadog Security Labs, firma AWS odnotowała próby wykorzystania PHP2Shell już 17 października 2026 roku.

Oznacza to, że podejrzana aktywność pojawiła się cztery dni przed oficjalnym wydaniem poprawek bezpieczeństwa.

Badacze informują również o szeroko zakrojonym skanowaniu serwerów w poszukiwaniu podatnych środowisk PHP.

Co właściwie oznacza takie skanowanie?

Wyobraźmy sobie włamywacza, który przechodzi ulicą i sprawdza drzwi kolejnych domów. Nie oznacza to jeszcze, że do każdego z nich się włamał.

Sprawdza jednak, które drzwi są otwarte lub posiadają znany, wadliwy zamek.

W świecie cyberbezpieczeństwa automatyczne skanery działają podobnie. Wysyłają do wielu serwerów odpowiednio przygotowane żądania, szukając oznak obecności konkretnej podatności.

Jeżeli znajdą podatne środowisko, może ono stać się celem dalszych prób ataku.

Należy przy tym odróżniać wykryte próby wykorzystania luki od potwierdzonych przypadków skutecznego przejęcia serwera. Nie każde podejrzane żądanie oznacza udany atak.

Sama skala zainteresowania PHP2Shell pokazuje jednak, dlaczego aktualizacje bezpieczeństwa należy wdrażać możliwie szybko.

W przypadku tak rozpowszechnionego oprogramowania jak PHP nawet krótki okres pomiędzy opublikowaniem szczegółów podatności a instalacją poprawki może mieć istotne znaczenie.

 

Czy WordPress, Joomla, OpenCart i PrestaShop są zagrożone?

W praktyce zdecydowana większość popularnych platform internetowych wykorzystuje PHP.

Dotyczy to zarówno systemów CMS, jak i oprogramowania e-commerce.

Warto jednak rozróżnić dwie rzeczy: zgodność platformy z określoną wersją PHP oraz bezpieczeństwo konkretnej instalacji interpretera.

Nowoczesne, aktualizowane wersje popularnych platform mogą działać na PHP 8.4. Dotyczy to odpowiednio przygotowanych środowisk WordPress, WooCommerce, Joomla, OpenCart i PrestaShop.

To dobra wiadomość dla właścicieli serwisów, ponieważ umożliwia korzystanie z nowoczesnych, wspieranych wersji języka. W przypadku konkretnego sklepu zawsze należy jednak sprawdzić zgodność jego wersji oraz zainstalowanych modułów i motywów.

Nie każda starsza instalacja będzie gotowa na zmianę PHP jednym kliknięciem.

Ale pojawia się jeszcze jedno ważne zastrzeżenie.

PHP 8.4 nie staje się automatycznie odporne na CVE-2026-109618 i CVE-2026-109619 wyłącznie dlatego, że jest nowoczesną wersją języka.

Jeżeli podatności obejmują również tę gałąź, konieczne będzie zainstalowanie konkretnego wydania zawierającego poprawki.

Zespół PHP zapowiedział, że dokładna lista podatnych oraz naprawionych wersji zostanie opublikowana wraz z aktualizacjami.

 

Co ze starszymi instalacjami PHP?

Według ostrzeżenia australijskiego ACSC problem może dotyczyć wersji PHP począwszy od PHP 5. Informacja ta nie stanowi jednak jeszcze ostatecznego technicznego potwierdzenia zakresu podatności.

Jest to szczególnie istotne w przypadku starszych witryn, które od wielu lat działają na nieaktualizowanym oprogramowaniu.

Niektóre serwisy nadal wykorzystują PHP 7.4, a sporadycznie również starsze wydania.

Takie środowiska mogą być bardziej kłopotliwe w utrzymaniu, ponieważ oficjalne wsparcie wielu gałęzi PHP dawno się zakończyło.

Właściciel strony nie zawsze może po prostu przełączyć PHP na najnowszą wersję. Starszy CMS, szablon lub moduł może przestać działać.

I tutaj pojawia się rola dostawców hostingu oraz firm takich jak CloudLinux.

 

Które wersje PHP otrzymały poprawki bezpieczeństwa?

21 października 2026 roku twórcy PHP udostępnili cztery nowe wydania usuwające obie krytyczne podatności.

Gałąź PHP	Pierwsza wersja zawierająca poprawki
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

Jeżeli Twoja strona korzysta przykładowo z PHP 8.3.25, oznacza to, że używa wydania starszego od wersji, w której usunięto obie podatności.

Nie musisz jednak koniecznie przechodzić na PHP 8.4 czy 8.5.

W wielu przypadkach wystarczy aktualizacja w obrębie dotychczasowej gałęzi, na przykład z PHP 8.3 do PHP 8.3.36.

To ważne, ponieważ aktualizacja bezpieczeństwa w obrębie jednej gałęzi PHP zwykle wiąże się z mniejszym ryzykiem problemów ze zgodnością niż migracja między głównymi lub pobocznymi wersjami języka.

 

A co ze starszymi wersjami PHP?

PHP 8.1 i starsze gałęzie nie otrzymują już zwykłych aktualizacji bezpieczeństwa od twórców PHP.

Ze względu na wagę obecnego zagrożenia zespół przygotował jednak minimalne poprawki w kodzie źródłowym dla PHP 7.4, 8.0 oraz 8.1.

Nie są to standardowe nowe wydania tych gałęzi.

Dodatkowo niektórzy dostawcy usług hostingowych i systemów operacyjnych oferują własne pakiety zabezpieczające starsze wersje PHP.

Dlatego starszy numer PHP nie zawsze oznacza brak odpowiedniej łatki, szczególnie w środowiskach korzystających z profesjonalnych pakietów utrzymaniowych.

W takim przypadku najlepiej sprawdzić komunikat dostawcy lub zapytać administratora serwera, czy poprawki CVE-2026-109618 i CVE-2026-109619 zostały już wdrożone.

 

CloudLinux – dlaczego hosting może zabezpieczyć nawet starsze PHP?

CloudLinux to rozwiązanie wykorzystywane przez wielu operatorów hostingowych, między innymi do izolowania zasobów kont oraz udostępniania różnych wersji PHP.

Jedną z istotnych funkcji tego ekosystemu jest możliwość dostarczania poprawek bezpieczeństwa również do starszych gałęzi PHP.

Jak to działa?

Wyobraźmy sobie właściciela samochodu, który jeździ starszym, ale nadal sprawnym modelem. Producent zakończył już produkcję tego samochodu i nie oferuje standardowych aktualizacji.

Pojawia się jednak firma specjalistyczna, która potrafi przygotować poprawiony element i usunąć określoną wadę bez konieczności wymiany całego pojazdu.

W świecie oprogramowania takie podejście nazywamy backportowaniem poprawek bezpieczeństwa .

Producent lub dostawca utrzymania analizuje konkretną podatność, a następnie przygotowuje odpowiednio dostosowaną poprawkę dla starszej wersji oprogramowania.

 

CloudLinux rozpoczął publikowanie poprawek PHP2Shell

Po oficjalnej publikacji aktualizacji PHP, 21 października 2026 roku, CloudLinux rozpoczął udostępnianie odpowiednich pakietów bezpieczeństwa.

Firma potwierdziła przygotowywanie poprawek dla całej obsługiwanej rodziny alt-php , od PHP 5.2 do PHP 8.5, a także dla pakietów ea-php stosowanych w środowiskach cPanel/EasyApache.

Pierwsze poprawione pakiety PHP 7.4 zostały udostępnione jeszcze 21 października. Kolejne aktualizacje są publikowane zgodnie z harmonogramem dostawcy i przechodzą proces wdrażania przez operatorów hostingowych.

Istotną rolę odgrywa również Imunify360, system zabezpieczeń stosowany na wielu serwerach współdzielonych.

21 października udostępniono zestaw reguł WAF 8.83, który pozwala blokować jeden z rozpoznanych sposobów wykorzystania podatności PHP2Shell.

Jest to jednak dodatkowa warstwa ochrony, a nie zamiennik aktualizacji interpretera PHP.

 

Co to oznacza dla właściciela strony?

Jeżeli korzystasz z hostingu współdzielonego opartego na CloudLinux, istnieje duża szansa, że operator samodzielnie wdroży odpowiednie pakiety bezpieczeństwa.

Nie oznacza to jednak, że każdy serwer CloudLinux został już automatycznie zaktualizowany.

Dostawca musi pobrać poprawione pakiety, zainstalować je i w razie potrzeby ponownie uruchomić odpowiednie usługi PHP.

Dlatego najlepiej sprawdzić komunikaty swojego operatora hostingu.

Warto również pamiętać, że instalacja poprawki w starszej gałęzi PHP nie oznacza jej automatycznej modernizacji do PHP 8.4 czy 8.5.

Dzięki temu starsze aplikacje mogą nadal działać bez konieczności natychmiastowej przebudowy, a jednocześnie otrzymać ochronę przed konkretnymi, naprawionymi podatnościami.

Nie jest to jednak argument za bezterminowym korzystaniem z niewspieranych wersji PHP. W dłuższej perspektywie migracja do aktualnej gałęzi pozostaje najlepszym rozwiązaniem.

 

Hosting współdzielony, VPS czy serwer dedykowany – kto odpowiada za aktualizację?

Odpowiedzialność za bezpieczeństwo środowiska PHP zależy w dużej mierze od rodzaju usługi hostingowej.

W przypadku typowego hostingu współdzielonego aktualizacją pakietów serwerowych zajmuje się operator hostingu. Klient zazwyczaj wybiera dostępną wersję PHP w panelu zarządzania, natomiast jej techniczne utrzymanie spoczywa na dostawcy usługi.

Przy serwerze VPS sytuacja wygląda inaczej. Jeżeli użytkownik posiada samodzielnie zarządzany serwer, to zwykle on odpowiada za instalację i aktualizowanie odpowiednich pakietów.

Podobnie jest z serwerami dedykowanymi, choć w przypadku usług administracji zarządzanej obowiązki mogą być przekazane dostawcy.

Można to porównać do mieszkania.

W budynku wielorodzinnym za konserwację wspólnej instalacji centralnego ogrzewania odpowiada zazwyczaj zarządca. Mieszkaniec nie musi samodzielnie wymieniać elementów kotłowni.

Natomiast właściciel domu z własnym piecem powinien sam zadbać o jego konserwację albo zatrudnić odpowiedniego specjalistę.

Podobny podział odpowiedzialności występuje w hostingu.

Dlatego przed wykonywaniem zmian warto sprawdzić, czy operator serwera już przygotowuje odpowiednią aktualizację.

 

Informacja dla klientów Design Cart – czy jest powód do niepokoju?

W tym miejscu chcielibyśmy uspokoić naszych klientów.

W Design Cart od lat zwracamy szczególną uwagę na aktualność środowiska technologicznego, na którym uruchamiane są projektowane przez nas strony internetowe i sklepy.

Strony internetowe oraz sklepy internetowe realizowane przez Design Cart od 2024 roku były wdrażane w środowiskach PHP 8.3.

Nie opieraliśmy nowych realizacji na przestarzałych gałęziach PHP 5 czy PHP 7, które od dawna nie są już oficjalnie wspierane przez twórców języka.

Wykorzystywanie PHP 8.3 oznaczało wybór nowoczesnej, rozwijanej gałęzi języka, zapewniającej dobrą podstawę do dalszych aktualizacji środowiska.

Warto jednak zaznaczyć, że sam fakt korzystania z PHP 8.3 nie oznacza automatycznej ochrony przed nowo odkrytymi podatnościami.

W tej sytuacji kluczowe znaczenie będą miały aktualizacje udostępnione przez twórców PHP oraz operatorów serwerów.

Zgodnie z otrzymywanymi komunikatami hostingowymi dostawcy infrastruktury przygotowują się do wdrożenia poprawek niezwłocznie po ich publikacji.

Dla klientów korzystających z hostingu współdzielonego oznacza to, że w wielu przypadkach aktualizacja zostanie wykonana bez konieczności samodzielnego ingerowania w pliki strony.

Nie ma zatem powodu do pochopnego wyłączania poprawnie działających witryn ani przypadkowego zmieniania konfiguracji serwera.

Warto natomiast monitorować komunikaty operatora hostingowego i upewnić się, że środowisko PHP zostanie odpowiednio zaktualizowane.

 

Aktualizacja z 22 października – co wiemy o PHP 8.3?

Dla naszych klientów mamy dobrą wiadomość.

21 października twórcy PHP udostępnili wersję PHP 8.3.36 , która usuwa obie opisane podatności.

Oznacza to, że strony i sklepy realizowane przez Design Cart od 2024 roku, które wdrażaliśmy na PHP 8.3, nie wymagają z tego powodu automatycznej migracji do PHP 8.4.

Wystarczy, że środowisko PHP 8.3 zostanie zaktualizowane do wersji zawierającej poprawki bezpieczeństwa.

W przypadku serwisów korzystających z hostingu współdzielonego takie aktualizacje mogą być przeprowadzane przez operatora serwera, bez ingerencji właściciela strony.

Chcemy jednak wyraźnie zaznaczyć, że sam fakt korzystania z PHP 8.3 nie stanowi gwarancji bezpieczeństwa. Znaczenie ma konkretne wydanie interpretera oraz obecność najnowszych poprawek.

Dlatego rekomendujemy sprawdzenie komunikatów dostawcy hostingu i potwierdzenie wdrożenia aktualizacji PHP2Shell.

Nowoczesna architektura naszych realizacji ułatwia utrzymanie aktualnego środowiska, ale – jak pokazuje obecna sytuacja – również nowoczesne oprogramowanie wymaga regularnych aktualizacji bezpieczeństwa.

 

Czy warto od razu zmienić PHP na 8.4?

To pytanie z pewnością pojawi się u wielu właścicieli stron internetowych.

PHP 8.4 jest nowoczesną, oficjalnie wspieraną gałęzią PHP. Wiele aktualnych platform CMS i systemów e-commerce może z niej korzystać.

Nie oznacza to jednak, że natychmiastowe przełączenie wersji PHP rozwiązuje obecny problem.

Wróćmy jeszcze raz do analogii samochodowej.

Wyobraźmy sobie, że producent informuje o wadzie pewnego podzespołu. Problem może występować zarówno w samochodach sprzed kilku lat, jak i w modelach wyprodukowanych w ostatnim roku.

Kupienie nowszego rocznika tego samego samochodu niekoniecznie rozwiązuje problem, jeżeli wadliwy element nadal jest w nim zamontowany.

Dopiero zamontowanie poprawionej części usuwa konkretną wadę.

Podobnie będzie z PHP.

Jeżeli podatności dotyczą PHP 8.3 i 8.4, konieczne będzie zainstalowanie odpowiednio poprawionych wydań tych gałęzi.

Dodatkowo należy pamiętać o zgodności aplikacji.

Strona może działać poprawnie na PHP 8.3, ale po przełączeniu na PHP 8.4 jeden ze starszych modułów może generować błędy. Czasem problemem będzie rozszerzenie PHP, czasem nieaktualny szablon, a czasem funkcja wykorzystywana przez autorski kod.

Dlatego migrację do nowszej gałęzi PHP najlepiej przeprowadzać po sprawdzeniu zgodności aplikacji i wykonaniu kopii bezpieczeństwa.

Natomiast instalację aktualizacji bezpieczeństwa w już używanej gałęzi należy traktować priorytetowo.

 

Jak sprawdzić, z jakiej wersji PHP korzysta Twoja strona?

Sprawdzenie wersji PHP jest prostsze, niż mogłoby się wydawać. Nie musisz być programistą ani znać się na administracji serwerami. Wystarczy dostęp do plików swojej strony internetowej przez FTP lub menedżer plików dostępny w panelu hostingowym.

Najprostszym i jednocześnie bardzo dokładnym sposobem jest utworzenie niewielkiego pliku PHP, który wyświetli informacje o środowisku serwerowym.

Jak to zrobić krok po kroku?

1. Otwórz zwykły edytor tekstu, np. Notatnik.

2. Wklej do niego poniższy kod:

   <?php
   phpinfo();

     

3. Zapisz plik pod nazwą phpinfo.php .

4. Połącz się z serwerem przez FTP lub otwórz menedżer plików w panelu hostingowym.

5. Prześlij plik phpinfo.php do głównego katalogu swojej strony internetowej, zazwyczaj public_html , httpdocs lub katalogu przypisanego do domeny.

6. Otwórz przeglądarkę i wpisz adres:

   https://twojadomena.pl/phpinfo.php

Jeżeli wszystko zostało wykonane poprawnie, zobaczysz stronę zawierającą szczegółowe informacje o konfiguracji PHP.

Na samej górze znajdziesz numer wersji PHP , przykładowo PHP Version 8.3.27 lub PHP Version 8.4.x .

To właśnie wersja interpretera PHP, z której korzysta Twoja strona internetowa.

Metoda ta ma dodatkową zaletę: pokazuje rzeczywiste środowisko PHP obsługujące daną domenę, a nie wersję przypisaną do terminala SSH, która czasami może być inna.

⚠️ Bardzo ważne: po sprawdzeniu wersji PHP natychmiast usuń plik phpinfo.php z serwera!

Funkcja phpinfo() wyświetla nie tylko numer wersji PHP, ale również wiele szczegółów konfiguracji serwera, takich jak aktywne rozszerzenia, ścieżki systemowe czy ustawienia środowiska. Niektóre z tych informacji mogą być przydatne osobom próbującym zaatakować witrynę. Dlatego plik powinien istnieć wyłącznie przez czas niezbędny do przeprowadzenia kontroli. Najbezpieczniej używać go w katalogu z ograniczonym dostępem.

Warto również pamiętać, że sam numer wersji PHP nie zawsze pozwala stwierdzić, czy serwer jest zabezpieczony przed konkretną podatnością . Operatorzy hostingowi korzystający np. z CloudLinux mogą instalować poprawki bezpieczeństwa również w starszych gałęziach PHP, bez zmiany widocznego numeru głównej wersji języka. Takie rozwiązanie nazywane jest backportowaniem poprawek .

Jeżeli chcesz mieć pewność, że Twój hosting wdrożył zabezpieczenia przeciwko CVE-2026-109618 i CVE-2026-109619, najlepiej sprawdzić oficjalny komunikat operatora lub skontaktować się z jego pomocą techniczną.

 

Jak rozpoznać, czy moja wersja PHP zawiera poprawkę PHP2Shell?

Jeżeli po uruchomieniu pliku phpinfo.php zobaczysz na przykład PHP 8.3.36, oznacza to, że korzystasz z pierwszego oficjalnego wydania gałęzi PHP 8.3 zawierającego poprawki CVE-2026-109618 i CVE-2026-109619.

Jeśli zobaczysz PHP 8.3.25, korzystasz ze starszego numeru wydania.

Czy to automatycznie oznacza, że serwer nadal jest podatny?

Niekoniecznie.

Niektórzy dostawcy hostingu instalują poprawki bezpieczeństwa bez zmiany numeru głównego wydania interpretera. Możesz więc widzieć starszy numer PHP, mimo że operator zainstalował odpowiednie zabezpieczenia w swoim pakiecie.

Dlatego phpinfo() pozwala ustalić, z jakiej wersji PHP korzysta strona, ale nie zawsze wystarcza do potwierdzenia obecności wszystkich poprawek.

Jeżeli masz wątpliwości, zapytaj operatora hostingu wprost:

„Czy na moim serwerze zostały już wdrożone poprawki bezpieczeństwa dla CVE-2026-109618 i CVE-2026-109619?”

To znacznie bardziej precyzyjne pytanie niż samo pytanie o numer wersji PHP.

 

Jak zabezpieczyć stronę przed PHP2Shell?

Ponieważ oficjalne poprawki zostały już opublikowane, nie musimy czekać na ujawnienie szczegółów podatności. Najważniejsze jest teraz upewnienie się, że odpowiednie aktualizacje zostały rzeczywiście zainstalowane.

1. Sprawdź wersję PHP. Ustal, czy strona korzysta z PHP 8.2, 8.3, 8.4, 8.5 czy starszej gałęzi.

2. Sprawdź komunikaty swojego hostingu. Wielu operatorów wdraża poprawki automatycznie. Warto jednak upewnić się, że proces aktualizacji został zakończony.

3. Zainstaluj odpowiednie poprawki. Jeżeli samodzielnie administrujesz serwerem, zaktualizuj PHP do naprawionego wydania lub skorzystaj z poprawionych pakietów dostawcy systemu.

4. Sprawdź działanie strony po aktualizacji. Przetestuj formularze kontaktowe, logowanie użytkowników, proces składania zamówień i inne ważne funkcje serwisu.

5. Zweryfikuj logi serwera. Zwróć uwagę na nietypowe żądania, błędy wyczerpania pamięci oraz nieoczekiwane procesy uruchamiane przez usługę WWW .

6. Nie zakładaj, że sam firewall rozwiązuje problem. Reguły WAF mogą blokować rozpoznane próby ataku, ale nie naprawiają błędu w interpreterze PHP.

 

Co zrobić, jeżeli aktualizacja PHP nie jest jeszcze możliwa?

Twórcy PHP opublikowali również zalecenia dotyczące tymczasowego ograniczania ryzyka.

Wśród nich znalazły się zmiany konfiguracji memory_limit , ograniczenia rozmiaru przetwarzanych żądań oraz wyłączenie session.upload_progress.enabled .

W przypadku PHP 8.5 wskazano także możliwość wyłączenia fatal_error_backtraces .

Są to jednak działania przeznaczone przede wszystkim dla administratorów serwerów.

Nie zalecamy właścicielom stron samodzielnego zmieniania tych parametrów bez znajomości konfiguracji środowiska. Przykładowo ustawienie memory_limit = -1 znosi programowy limit pamięci PHP, co bez dodatkowych ograniczeń na poziomie systemu może prowadzić do problemów z dostępnością usługi.

Co więcej, żadne z tych obejść nie zapewnia pełnej ochrony przed PHP2Shell .

Jeżeli aktualizacja jest niemożliwa, administrator powinien rozważyć również czasowe ograniczenie publicznego dostępu do narażonej aplikacji.

Najskuteczniejszym rozwiązaniem pozostaje instalacja poprawionego interpretera PHP.

 

21 października 2026 – co wydarzy się o godzinie 16:00?

Zespół PHP zaplanował publikację poprawek na 21 października 2026 roku, na godzinę 14:00 UTC, czyli 16:00 czasu polskiego.

Wraz z wydaniem aktualizacji mają zostać ujawnione szczegóły techniczne obu podatności, lista wersji PHP, których dotyczy problem, oraz numery wydań zawierających poprawki.

news-web.php.net

Jest to istotny moment również dla administratorów serwerów.

Dopóki szczegóły podatności nie są publicznie znane, możliwości przygotowania skutecznych ataków mogą być ograniczone.

Po opublikowaniu poprawek osoby zajmujące się bezpieczeństwem mogą przeanalizować zmiany w kodzie źródłowym i ustalić, jakie błędy zostały naprawione.

Niestety tę samą wiedzę mogą wykorzystać cyberprzestępcy.

Powstaje wówczas swoisty wyścig pomiędzy administratorami instalującymi poprawki a atakującymi próbującymi wykorzystać nadal podatne środowiska.

To jeden z powodów, dla których twórcy PHP zdecydowali się wcześniej ostrzec społeczność.

Nie chodziło o wywołanie paniki, lecz o umożliwienie administratorom przygotowania procedur aktualizacji jeszcze przed publikacją szczegółów technicznych.

 

Najczęstsze pytania dotyczące nowych podatności PHP

Czy moja strona WordPress może zostać zaatakowana?

Potencjalnie tak, jeżeli korzysta z podatnego środowiska PHP i spełnione zostaną warunki wykorzystania konkretnej luki. Sam fakt korzystania z WordPressa nie oznacza jednak, że strona na pewno jest podatna.

 

Czy aktualizacja WordPressa, Joomla albo PrestaShop rozwiąże problem?

Nie, jeżeli źródłem zagrożenia jest interpreter PHP. Aktualizacja CMS i jego rozszerzeń nadal pozostaje konieczna dla usuwania podatności występujących w tych aplikacjach, ale nie zastępuje aktualizacji PHP.

 

Czy PHP 8.3 i PHP 8.4 są bezpieczne?

Tak, pod warunkiem korzystania z odpowiednich wydań zawierających poprawki bezpieczeństwa. W przypadku PHP 8.3 pierwszą oficjalną wersją usuwającą obie podatności jest 8.3.36, natomiast dla PHP 8.4 – wersja 8.4.27. Bezpieczeństwo starszych numerów wydań zależy od tego, czy dostawca środowiska wdrożył odpowiednie backporty.

 

Czy muszę samodzielnie aktualizować PHP?

Na hostingu współdzielonym aktualizacje pakietów serwerowych zazwyczaj wdraża dostawca. W przypadku samodzielnie zarządzanego VPS lub serwera dedykowanego odpowiedzialność spoczywa zwykle na administratorze.

 

Czy posiadanie certyfikatu SSL chroni przed tym atakiem?

Nie. Certyfikat SSL/TLS odpowiada przede wszystkim za zabezpieczenie komunikacji między przeglądarką a serwerem. Nie naprawia błędów występujących w interpreterze PHP.

 

Czy starsze PHP z poprawkami CloudLinux może być bezpieczne?

Może być zabezpieczone przed określonymi, załatanymi podatnościami, nawet jeśli sama gałąź PHP nie otrzymuje już oficjalnego wsparcia od twórców języka. Nie oznacza to jednak automatycznie takiego samego poziomu wsparcia jak w przypadku aktualnych wydań.

 

Czy powinienem wyłączyć stronę internetową?

Nie ma jednego zalecenia odpowiedniego dla wszystkich serwisów. Decyzja zależy od podatności, możliwości jej wykorzystania, konfiguracji serwera i znaczenia przechowywanych danych. Dla szczególnie narażonych systemów, których nie można szybko zaktualizować, CERT-EU zaleca rozważenie izolacji od publicznej sieci.

 

Czy istnieją już potwierdzone ataki wykorzystujące te podatności?

Tak. Według analizy Datadog Security Labs pierwsze próby wykorzystania podatności odnotowano jeszcze przed oficjalną publikacją poprawek, a 21 października badacze informowali również o szerokim skanowaniu serwerów. Nie każda taka próba oznacza skuteczne włamanie, ale potwierdza realne zainteresowanie podatnościami ze strony atakujących.

 

Dlaczego PHP2Shell wykryto dopiero teraz? Historia sięga 2024 roku

Jednym z najbardziej interesujących elementów całej historii jest fakt, że pierwsze sygnały dotyczące problemu z zarządzaniem pamięcią PHP pojawiły się już w 2024 roku.

Właśnie wtedy przeprowadzono zewnętrzny audyt bezpieczeństwa interpretera PHP, zorganizowany przy wsparciu Sovereign Tech Agency.

Podczas prac nad usuwaniem wykrytych problemów jeden z programistów natrafił na niepokojący mechanizm związany z obsługą błędów wyczerpania pamięci.

Początkowo nie udało się jednak wskazać konkretnej metody, która pozwalałaby wykorzystać go do zdalnego wykonania kodu.

Co więcej, usunięcie problemu okazało się wyjątkowo trudne.

Zmiany w tak fundamentalnej części interpretera mogły wpływać na zgodność istniejących aplikacji, wydajność PHP oraz działanie dodatkowych rozszerzeń.

Dopiero w sierpniu 2026 roku niezależne badania zespołów bezpieczeństwa pozwoliły wykazać rzeczywistą skalę zagrożenia.

W oficjalnym komunikacie PHP Foundation potwierdzono, że 11 sierpnia firma Calif zgłosiła możliwość zdalnego wykonania kodu związaną ze znanym wcześniej problemem zarządzania pamięcią.

Tego samego dnia podobną przyczynę podatności niezależnie zgłosił zespół OpenAI. Kolejne scenariusze ataku analizowali także badacze Wiz.

Od tego momentu naprawa błędu stała się jednym z najważniejszych zadań zespołu odpowiedzialnego za bezpieczeństwo PHP.

 

Co zmieniło się w bezpieczeństwie PHP?

Twórcy języka przyznali, że wielomiesięczne opóźnienie w rozwiązaniu problemu wynikało częściowo z ograniczonych zasobów zespołu i trudności w podejmowaniu decyzji dotyczących tak głębokich zmian w interpreterze.

Zapowiedzieli również dalsze usprawnienia procesu zgłaszania, analizowania i naprawiania podatności.

Historia PHP2Shell pokazuje, że bezpieczeństwo popularnego oprogramowania nie polega wyłącznie na szybkim usuwaniu prostych błędów.

Czasami największym wyzwaniem jest zmiana fragmentu kodu, z którego korzystają miliony stron i aplikacji, bez wywołania problemów w całym ekosystemie.

To również przypomnienie, jak ważne są niezależne audyty bezpieczeństwa, współpraca badaczy i regularne aktualizacje oprogramowania.

 

Podsumowanie – aktualizacje CMS to nie wszystko

Wielu właścicieli stron internetowych kojarzy bezpieczeństwo przede wszystkim z regularnymi aktualizacjami WordPressa, Joomla, OpenCart czy PrestaShop.

Jest to oczywiście bardzo ważny element utrzymania strony, ale nie jedyny.

Każdy serwis korzysta z całego środowiska technologicznego, na które składają się serwer WWW, interpreter PHP, baza danych, system operacyjny i szereg dodatkowych usług.

Możemy mieć doskonale utrzymaną stronę internetową, aktualny CMS, bezpieczne hasła i sprawdzone rozszerzenia, a mimo to pozostawać narażeni na podatność występującą w jednej z niższych warstw oprogramowania.

Dwie krytyczne luki CVE-2026-109618 i CVE-2026-109619 są dobrym przypomnieniem tej zależności.

Bezpieczeństwo strony internetowej jest bowiem tak silne, jak bezpieczeństwo jej poszczególnych elementów.

Dla klientów Design Cart najważniejsza informacja jest taka, że strony i sklepy wdrażane przez nas od 2024 roku były uruchamiane na nowoczesnym PHP 8.3. Dzięki temu ich środowisko można zabezpieczyć aktualizacją do PHP 8.3.36 bez konieczności przechodzenia na zupełnie nową gałąź języka.

Należy jednak pamiętać, że korzystanie z nowoczesnego PHP nie zwalnia z obowiązku instalowania kolejnych aktualizacji.

Przypadek PHP2Shell pokazuje, że nawet popularne, rozwijane i profesjonalnie utrzymywane oprogramowanie może zawierać poważne błędy bezpieczeństwa.

Dlatego po wydarzeniach z 21 października 2026 roku najważniejsze jest już nie oczekiwanie na poprawki, lecz upewnienie się, że zostały one rzeczywiście wdrożone na serwerze.

Bezpieczeństwo strony internetowej nie zależy wyłącznie od tego, jak została zaprogramowana. Równie ważne jest środowisko, w którym działa, oraz ludzie odpowiedzialni za jego aktualizowanie.