Krytyczne luki w PHP – CVE-2026-109618 i CVE-2026-109619
Krytyczne luki w PHP – CVE-2026-109618 i CVE-2026-109619
21 października 2026 roku zespół PHP opublikował pilne aktualizacje bezpieczeństwa, które usuwają dwie krytyczne podatności. Krytyczne luki w PHP, oznaczone jako CVE-2026-109618 oraz CVE-2026-109619, mogą umożliwić zdalne wykonanie kodu na serwerze bez wcześniejszego uwierzytelnienia.
Co istotne, problem dotyczy mechanizmów samego interpretera PHP. Oznacza to, że zagrożenie nie ogranicza się do konkretnego systemu CMS, wtyczki czy aplikacji internetowej. Podatne mogą być serwery obsługujące WordPressa, WooCommerce, PrestaShop oraz inne aplikacje wykorzystujące PHP.
Ze względu na wagę zagrożenia twórcy PHP zalecili natychmiastową aktualizację. Dlatego poprawki udostępniono dla czterech wspieranych gałęzi języka: PHP 8.2, 8.3, 8.4 oraz 8.5.
W przypadku JCHOST poprawki bezpieczeństwa zostały wdrożone na serwerach już 21 października 2026 roku, czyli w dniu ich oficjalnego udostępnienia. Dzięki temu zagrożenia związane z opisanymi podatnościami zostały szybko wyeliminowane w objętych aktualizacją środowiskach.
Warto wiedzieć: Obie podatności otrzymały ocenę 9,2 w skali CVSS 4.0. Są to błędy klasy RCE (Remote Code Execution), które mogą pozwolić atakującemu na uruchomienie własnego kodu w podatnym środowisku PHP.
Krytyczne luki w PHP – na czym polega zagrożenie?
Oba błędy dotyczą nieprawidłowego zarządzania pamięcią i stanem wewnętrznym interpretera PHP. W rezultacie ich wykorzystanie może doprowadzić do wykonania kodu, którego administrator serwera nie zamierzał uruchamiać.
Co ważne, atak nie musi wykorzystywać podatności w WordPressie ani zainstalowanej wtyczce. W określonych warunkach wystarczy bowiem odpowiednio przygotowane żądanie HTTP skierowane do serwera obsługującego PHP.
Chociaż obie podatności mogą prowadzić do podobnych konsekwencji, ich mechanizmy są odmienne. Dlatego warto osobno wyjaśnić sposób działania każdego błędu.
CVE-2026-109618 – uszkodzenie pamięci podczas obsługi błędów OOM
Pierwsza podatność, CVE-2026-109618, wynika z nieprawidłowej obsługi sytuacji, w której interpreterowi PHP kończy się dostępna pamięć.
Taki stan określa się jako OOM (Out of Memory). W normalnych warunkach interpreter powinien bezpiecznie przerwać operację, która przekroczyła dostępne zasoby.
Jednak w podatnych wersjach PHP może dojść do przerwania wykonywanej operacji w nieodpowiednim momencie. W konsekwencji część struktur pamięci pozostaje niekompletna lub nieprawidłowo zainicjalizowana.
Podczas zamykania żądania PHP może potraktować te struktury jako poprawne. Prowadzi to do uszkodzenia pamięci, a w określonych warunkach stwarza możliwość wykonania kodu przez atakującego.
Dlaczego szczególnie zagrożony jest Apache z mod_php?
Oficjalny komunikat PHP wskazuje, że największe ryzyko dotyczy konfiguracji Apache wykorzystujących moduł mod_php.
W takim środowisku wykazano możliwość wywołania podatności za pomocą nieuwierzytelnionego żądania HTTP. Co istotne, może się to wydarzyć jeszcze przed wykonaniem kodu właściwej aplikacji.
Oznacza to, że nawet prawidłowo zabezpieczony CMS nie usuwa problemu znajdującego się na niższym poziomie oprogramowania.
PHP-FPM obsługuje część błędów inicjalizacji w inny sposób, co ogranicza niektóre ścieżki ataku. Nie oznacza to jednak pełnej odporności. Dlatego twórcy PHP zalecają aktualizację również w tym środowisku.
CVE-2026-109619 – nieprawidłowe wykorzystanie stanu poprzedniego żądania
Druga podatność, CVE-2026-109619, jest związana z błędnym zarządzaniem stanem globalnym interpretera PHP.
Proces PHP może obsługiwać kolejne żądania HTTP. Niektóre jego wewnętrzne struktury pozostają aktywne pomiędzy żądaniami, jednak dane przypisane do zakończonego żądania powinny zostać prawidłowo wyczyszczone.
W podatnych wersjach PHP określone operacje mogą pozostawić odwołanie do pamięci, która została już zwolniona.
Gdy ten sam proces obsłuży kolejne żądanie, może ponownie wykorzystać nieaktualne odwołanie. Jest to przykład błędu określanego jako use-after-free.
W rezultacie, w odpowiednich warunkach, może dojść do uszkodzenia pamięci i zdalnego wykonania kodu.
Dlaczego ten błąd jest szczególnie niebezpieczny?
Problem nie musi ograniczać się do jednego żądania HTTP. Znaczenie ma bowiem również stan pozostawiony przez wcześniejsze operacje interpretera.
Takie zachowanie utrudnia ochronę opartą wyłącznie na sprawdzaniu danych wejściowych aplikacji. Błąd występuje bowiem wewnątrz PHP i może być niezależny od logiki konkretnej strony internetowej.
Podobnie jak w przypadku pierwszej podatności, właściwym rozwiązaniem jest zastosowanie poprawek przygotowanych przez twórców języka.
CVE-2026-109618 i CVE-2026-109619 – mechanizmy podatności
Krytyczne luki w PHP – które wersje otrzymały poprawki?
Poprawki dla obu podatności pojawiły się 21 października 2026 roku. Zespół PHP udostępnił cztery aktualizacje bezpieczeństwa dla wspieranych gałęzi języka.
W poniższym zestawieniu przedstawiono wersje zawierające poprawki:
- PHP 8.5: aktualizacja do wersji 8.5.12.
- PHP 8.4: aktualizacja do wersji 8.4.27.
- PHP 8.3: aktualizacja do wersji 8.3.36.
- PHP 8.2: aktualizacja do wersji 8.2.35.
Krytyczne luki w PHP zostały usunięte we wszystkich czterech wymienionych wydaniach. Dlatego administratorzy powinni sprawdzić nie tylko główny numer wersji, ale również zainstalowane wydanie bezpieczeństwa.
Co istotne, wcześniejsze wydania w tych gałęziach wymagają odpowiedniej poprawki. Dotyczy to również instalacji, które otrzymały wrześniowe aktualizacje PHP.
Przykładowo wersja 8.4.26 nie zawiera jeszcze poprawek przygotowanych 21 października. Z kolei PHP 8.4.27 uwzględnia już rozwiązania usuwające obie podatności.
W przypadku pakietów udostępnianych przez dystrybucje Linuksa lub dostawców wsparcia LTS sytuacja może wyglądać inaczej. Poprawki bywają bowiem przenoszone do starszych pakietów bez zmiany głównego numeru wersji PHP.
Dlatego przy ocenie bezpieczeństwa należy sprawdzić również komunikaty dostawcy pakietu. Sam numer wersji nie zawsze wystarcza do ustalenia, czy odpowiedni backport został już zastosowany.
PHP – wersje z poprawkami bezpieczeństwa (październik 2026)
Co ze starszymi wersjami PHP 8.1, 8.0 i 7.4?
PHP 8.1 oraz starsze gałęzie zakończyły oficjalny cykl wsparcia. W rezultacie nie otrzymują już regularnych aktualizacji bezpieczeństwa w ramach standardowych wydań projektu PHP.
Jednak ze względu na powagę październikowych podatności zespół PHP przygotował minimalne poprawki źródłowe również dla gałęzi 7.4, 8.0 i 8.1.
Nie oznacza to przywrócenia ich oficjalnego wsparcia. Takie poprawki mogą być wykorzystane przez administratorów samodzielnie kompilujących PHP lub dostawców oferujących rozszerzone utrzymanie starszych wersji.
Dlatego najbezpieczniejszym kierunkiem pozostaje migracja do wspieranej gałęzi PHP, o ile pozwala na to kompatybilność aplikacji.
PHP 8.2 zbliża się do końca wsparcia
Osobnej uwagi wymaga PHP 8.2, którego wsparcie bezpieczeństwa zakończy się 31 grudnia 2026 roku.
Wprawdzie wersja 8.2.35 usuwa październikowe podatności, ale nie przedłuża cyklu życia tej gałęzi.
Dlatego administratorzy korzystający z PHP 8.2 powinni zaplanować migrację do nowszej wersji. Wybór konkretnej gałęzi musi jednak uwzględniać wymagania aplikacji, wykorzystywanych rozszerzeń oraz kompatybilność dodatkowego oprogramowania.
Więcej informacji o wcześniejszych aktualizacjach oraz różnicach między gałęziami języka opisaliśmy w artykule Aktualizacja PHP – poprawki bezpieczeństwa z września 2026 roku.
Krytyczne podatności PHP a bezpieczeństwo WordPressa i sklepów internetowych
Podatności CVE-2026-109618 i CVE-2026-109619 nie zostały wykryte bezpośrednio w systemach CMS. Występują bowiem w interpreterze PHP, na którym działają te aplikacje.
To ważne rozróżnienie. Aktualizacja samego WordPressa, WooCommerce lub PrestaShop nie usuwa podatności znajdującej się w PHP.
Co istotne, krytyczne luki w PHP mogą wpływać na różne aplikacje korzystające z tego samego środowiska uruchomieniowego. Dlatego nawet aktualny system CMS nie stanowi wystarczającej ochrony przed tym zagrożeniem.
WordPress i WooCommerce
21 października WordPress.org opublikował własny komunikat dotyczący krytycznych podatności PHP.
Twórcy WordPressa podkreślili, że zagrożenie obejmuje środowisko serwerowe, a nie konkretną wersję systemu CMS. Z tego powodu nie przewidziano osobnej aktualizacji WordPressa usuwającej te błędy.
Właściciel witryny powinien zatem przede wszystkim upewnić się, że hosting korzysta z poprawionego PHP.
Dotyczy to również sklepów WooCommerce, które wykorzystują ten sam interpreter do obsługi procesów zakupowych, zamówień i integracji.
Jednocześnie nie należy rezygnować z aktualizowania samego WordPressa i jego dodatków. Są one bowiem niezależnym elementem bezpieczeństwa całej witryny.
PrestaShop i inne aplikacje PHP
Podobna sytuacja dotyczy sklepów PrestaShop oraz aplikacji tworzonych indywidualnie.
Nawet aktualny i prawidłowo skonfigurowany sklep może korzystać z podatnego interpretera PHP. Dlatego bezpieczeństwo aplikacji zależy również od aktualności środowiska hostingowego.
Nie oznacza to jednak, że wszystkie konfiguracje są równie łatwe do wykorzystania przez atakującego. Rzeczywiste ryzyko zależy między innymi od sposobu uruchamiania PHP oraz konfiguracji serwera.
Niezależnie od tych różnic oficjalne zalecenie pozostaje jednoznaczne: podatne środowiska powinny otrzymać poprawki bezpieczeństwa.
WordPress, WooCommerce i PrestaShop – bezpieczeństwo PHP
JCHOST wdrożył poprawki PHP już 21 października 2026 roku
W przypadku tak poważnych podatności duże znaczenie ma nie tylko dostępność aktualizacji, lecz również czas jej wdrożenia.
Poprawki PHP zostały oficjalnie udostępnione 21 października 2026 roku. Tego samego dnia pojawiły się komunikaty ostrzegające administratorów przed możliwością zdalnego wykonania kodu.
Serwery JCHOST zostały załatane już 21 października 2026 roku, w dniu wydania poprawek bezpieczeństwa.
Dzięki temu krytyczne luki w PHP zostały usunięte na serwerach objętych wdrożeniem poprawek jeszcze w dniu ich udostępnienia. Tak szybka reakcja ma szczególne znaczenie w przypadku podatności umożliwiających atak bez uwierzytelnienia.
W rezultacie ograniczono okres potencjalnego narażenia środowisk na wykorzystanie znanych błędów. Warto jednak pamiętać, że bezpieczeństwo strony internetowej obejmuje wiele niezależnych elementów.
Aktualne PHP jest jednym z nich, podobnie jak bieżące poprawki systemu CMS, wtyczek i pozostałego oprogramowania serwerowego.
Październikowy incydent pokazuje więc, dlaczego przy wyborze hostingu warto zwracać uwagę nie tylko na parametry wydajnościowe. Równie istotna jest sprawność reagowania na nowe zagrożenia.
Czy firewall WAF i dodatkowe zabezpieczenia mogą zastąpić aktualizację PHP?
Po ujawnieniu podatności administratorzy mogą próbować ograniczyć ryzyko za pomocą dodatkowych mechanizmów ochrony.
Należą do nich między innymi reguły WAF, ograniczenia wielkości żądań HTTP oraz zmiany konfiguracji wybranych funkcji PHP.
Takie działania mogą wprawdzie utrudnić wykorzystanie określonych ścieżek ataku, jednak nie usuwają błędów występujących wewnątrz interpretera.
Zespół PHP wyraźnie zaznaczył, że rozwiązania tymczasowe nie zapewniają pełnej ochrony przed październikowymi podatnościami.
Dlatego WAF należy traktować jako dodatkową warstwę zabezpieczeń, a nie zamiennik aktualizacji.
Dodatkowy komunikat PHP z 23 października
Dwa dni po głównym wydaniu bezpieczeństwa twórcy PHP opublikowali dodatkową informację dotyczącą funkcji śledzenia postępu przesyłania plików w sesjach.
Opisano rzadki scenariusz, w którym aplikacja zmienia sposób serializacji sesji podczas działania. Przy określonej konfiguracji może to prowadzić do dodatkowego zagrożenia RCE.
Problem ma otrzymać osobny identyfikator CVE-2026-115560 i zostać poprawiony w kolejnym regularnym wydaniu PHP.
Do tego czasu zespół PHP zaleca rozważenie ustawienia session.upload_progress.enabled=0. Rekomendacja dotyczy przede wszystkim środowisk, których konfiguracja odpowiada warunkom opisanym w komunikacie.
W szczególności problem wymaga nietypowego połączenia ustawień serializacji sesji oraz zmiany wybranego mechanizmu podczas wykonywania aplikacji.
Jeżeli aplikacja nie zmienia sposobu serializacji sesji w trakcie działania, opisany scenariusz nie powinien wystąpić.
W przypadku zmiany parametru na poziomie serwera należy jednak uwzględnić wpływ na funkcje aplikacji korzystające ze śledzenia postępu przesyłania plików.
Co ważne, informacja z 23 października dotyczy dodatkowego, szczególnego scenariusza. Nie zmienia ona faktu, że poprawki dwóch głównych podatności zostały udostępnione 21 października.
Jak sprawdzić, czy strona korzysta z poprawionej wersji PHP?
Weryfikacja wersji PHP zależy od wykorzystywanego systemu CMS oraz sposobu zarządzania hostingiem.
Na szczęście w wielu przypadkach nie wymaga dostępu do konsoli serwera. Informację można bowiem znaleźć bezpośrednio w panelu WordPressa lub w panelu administracyjnym hostingu.
Sprawdzenie wersji PHP w WordPressie
WordPress pozwala sprawdzić informacje o środowisku bez instalowania dodatkowych wtyczek.
Po zalogowaniu do panelu administracyjnego należy przejść do sekcji:
Narzędzia → Stan witryny → Informacje → Serwer
W tej części znajduje się informacja o wersji PHP wykorzystywanej przez witrynę.
Następnie warto porównać odczytany numer z wersjami zawierającymi poprawki bezpieczeństwa. Należy jednak pamiętać o możliwości stosowania poprawek typu backport przez dostawcę środowiska.
Dlatego sam numer wersji nie zawsze pozwala jednoznacznie ocenić poziom zabezpieczenia serwera.
Jak sprawdzić wersję PHP w WordPressie?
Sprawdzenie PHP w panelu hostingowym
Informacje o wersji interpretera można również znaleźć w panelu administracyjnym hostingu, jeśli usługodawca udostępnia odpowiednią funkcję.
W przypadku serwerów VPS i dedykowanych administrator powinien dodatkowo sprawdzić zainstalowane pakiety oraz komunikaty bezpieczeństwa wykorzystywanej dystrybucji.
Co istotne, samo polecenie php -v może pokazywać wersję interpretera CLI. Nie zawsze jest ona taka sama jak wersja PHP obsługująca żądania strony internetowej.
Dlatego w środowiskach z kilkoma instalacjami PHP należy zweryfikować również aktywną konfigurację serwera WWW.
Czy trzeba samodzielnie zmieniać wersję PHP?
Nie zawsze. W przypadku hostingu zarządzanego dostawca może bowiem wdrożyć poprawki bezpieczeństwa po stronie infrastruktury.
Dzięki temu właściciel strony nie musi koniecznie samodzielnie przeprowadzać aktualizacji.
Należy jednak odróżnić aktualizację bezpieczeństwa w obrębie jednej gałęzi PHP od migracji między głównymi wersjami.
Przykładowo przejście z PHP 8.4.26 na 8.4.27 jest aktualizacją utrzymaniową. Natomiast migracja z PHP 8.2 na 8.5 może wymagać zmian w kodzie aplikacji oraz sprawdzenia zgodności wtyczek i rozszerzeń.
Dlatego w przypadku większych zmian warto najpierw wykonać kopię zapasową i przetestować aplikację poza środowiskiem produkcyjnym.
Proces ten opisaliśmy szczegółowo w poradniku Staging WordPress – co to jest i jak bezpiecznie testować zmiany?.
Krytyczne luki w PHP a bezpieczeństwo hostingu
Październikowe podatności pokazują, że bezpieczeństwo aplikacji internetowej nie kończy się na aktualizowaniu systemu CMS.
Interpreter PHP jest bowiem jednym z podstawowych elementów środowiska uruchomieniowego. Odpowiada za przetwarzanie kodu aplikacji i obsługę operacji wykonywanych podczas żądań HTTP.
W rezultacie nawet aktualna aplikacja może działać w podatnym środowisku, jeżeli zagrożenie występuje na poziomie interpretera.
W przypadku podatności umożliwiających nieuwierzytelnione RCE szczególnie istotny jest czas reakcji. Publiczne ujawnienie szczegółów błędu może bowiem zwiększyć zainteresowanie atakujących próbami jego wykorzystania.
Administratorzy powinni więc traktować krytyczne aktualizacje środowiska serwerowego jako zadania wymagające szybkiego działania.
Jednocześnie trzeba pamiętać, że samo wdrożenie poprawki nie zastępuje monitorowania bezpieczeństwa. Aktualizacje powinny zatem stanowić element szerszego procesu utrzymania infrastruktury.
Dobrze zorganizowany proces obejmuje analizę komunikatu bezpieczeństwa, ocenę zagrożenia i wdrożenie aktualizacji. Następnie administrator powinien zweryfikować działanie usług oraz monitorować środowisko.
Takie podejście pozwala ograniczyć ryzyko związane zarówno z samą podatnością, jak i ewentualnymi problemami po aktualizacji.
Proces reagowania na krytyczne podatności PHP
Podsumowanie – krytyczne luki w PHP i znaczenie szybkich aktualizacji
Krytyczne luki w PHP, oznaczone jako CVE-2026-109618 i CVE-2026-109619, należą do najpoważniejszych zagrożeń ujawnionych w październiku 2026 roku. Obie podatności mogą umożliwić zdalne wykonanie kodu bez uwierzytelnienia. Dlatego wymagają szybkiej reakcji administratorów oraz dostawców hostingu.
Poprawki udostępniono 21 października w wersjach PHP 8.2.35, 8.3.36, 8.4.27 i 8.5.12. W przypadku starszych gałęzi należy natomiast sprawdzić dostępność odpowiednich poprawek dostawcy lub zaplanować migrację.
W JCHOST aktualizacje bezpieczeństwa zostały wdrożone na serwerach już 21 października 2026 roku. Dzięki temu zagrożenia związane z tymi podatnościami zostały szybko usunięte z objętych aktualizacją środowisk.
Warto więc regularnie kontrolować stan PHP, systemu CMS oraz wykorzystywanych dodatków. Nawet najlepiej zabezpieczona aplikacja wymaga bowiem aktualnego i prawidłowo utrzymywanego środowiska serwerowego.
Odbieramy telefony, odpisujemy na maile, nie ukrywamy kosztów, a dodatkowo oferujemy najszybsze pakiety hostingowe na rynku. Uważasz, że to zwroty marketingowe? Sprawdź sam/a!
Jeśli nie będziesz zadowolony/a, zwrócimy Ci pieniądze.
Twoje strony i sklepy przeniesiemy za darmo!
Jeżeli masz jakiekolwiek pytania, skontaktuj się z nami! Kliknij tutaj.
Chcesz dowiedzieć się o nas trochę więcej? Przejdź na stronę JCHost.pl.