Krytyczne luki w PHP. Jak sprawdzić wersję PHP na stronie

Zespół PHP wydał 21 października 2026 roku poprawki dwóch krytycznych luk, które mogą pozwolić uruchomić obcy kod na serwerze bez logowania. Poprawione wersje to 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Według zespołu podatne są wszystkie instalacje PHP obsługujące strony, więc sprawa dotyczy też serwisów na WordPressie i Joomli oraz sklepów opartych na PHP. Obie luki mają ocenę 9,2 w skali CVSS 4.0, a ich szczegóły wyciekły dzień przed wydaniem. Sprawdź, jakiej wersji PHP używa Twoja strona i czy hosting już ją zaktualizował.

Co wiadomo o lukach CVE-2026-109618 i CVE-2026-109619

Stan na 21 października 2026, godz. 15:50. Poprawki są na php.net. Zespół PHP zapowiadał je na 16:00 czasu polskiego, a opisy luk na GitHubie opublikował o 15:34. Razem z wydaniem ukazało się ogłoszenie bezpieczeństwa, które wzywa wszystkich użytkowników PHP do natychmiastowej aktualizacji.

Obie luki prowadzą do zdalnego wykonania kodu, czyli uruchomienia przez atakującego własnych poleceń na serwerze. Pierwsza, CVE-2026-109618, ma w ogłoszeniu nazwę “RCE via OOM corruption”. Gdy PHP zabraknie pamięci, obsługa tego błędu może przerwać pracę przy częściowo zainicjowanych danych żądania. Sprzątanie po żądaniu traktuje je potem jak poprawne. Druga, CVE-2026-109619, nazywa się “RCE via stale global state”. Stan należący do żądania przeżywa tu zwolnienie pamięci, a kolejne żądanie w tym samym procesie może go użyć.

Zagrożone są wszystkie instalacje obsługujące żądania z sieci: PHP-FPM, Apache z modułem mod_php, php-cgi, FrankenPHP i LiteSpeed. Najwyższe ryzyko zespół PHP widzi przy mod_php. Zademonstrowano tam atak, który niezalogowane żądanie uruchamia, zanim wykona się jakikolwiek kod aplikacji.

Szczegóły wyciekły 20 października, przed końcem embarga. Numery luk podał wtedy CERT-EU w ostrzeżeniu 2026-018, a firma watchTowr napisała, że informacje o lukach są prawdziwe.

Czy ktoś już wykorzystał luki? Patchstack, firma zajmująca się bezpieczeństwem WordPressa, pisze o zgłoszeniach prób ataków od partnerów hostingowych. Tuż przed wydaniem poprawek jego własne dane pokazywały jednak tylko sondowanie serwerów, bez twardych dowodów włamań. Amerykańska agencja CISA w alercie z 21 października napisała, że do chwili publikacji nie zaobserwowała wykorzystania luk, a organizacjom, które nie mogą od razu zaktualizować PHP albo nadal używają wersji 8.1 lub starszej, zaleciła odłączenie takich systemów od sieci do czasu aktualizacji. Cloudflare podaje, że już przed oficjalnym wydaniem poprawek widział ruch atakujący swoich klientów, a napastnicy zmieniali ładunek, żeby obejść reguły zapory. Luki siedzą w samym PHP, więc WordPress i inne systemy zarządzania treścią są zagrożone przez wersję PHP na serwerze, niezależnie od własnego kodu.

Pierwsza Misja AI · Kodożercy

AI bez technikaliów – kurs i certyfikat

Pierwsza Misja AI to kurs Kodożerców dla absolutnych początkujących. Fabuła w konwencji science fiction, gamifikacja, ćwiczenia na żywym modelu, certyfikat na koniec.

Zacznij Pierwszą Misję →

Które wersje PHP dostały poprawki

Poprawki wyszły dla czterech gałęzi, które według polityki projektu mają wsparcie bezpieczeństwa: 8.2, 8.3, 8.4 i 8.5. Gałąź to seria wersji o tym samym początku numeru, na przykład 8.3.x. Każda jest wspierana dwa lata w pełni i dwa kolejne lata tylko w zakresie krytycznych luk. Dystrybucje Linuksa i dostawcy wsparcia długoterminowego dostali poprawki wcześniej, więc na serwerze z pakietami systemowymi szukaj aktualizacji u dostawcy systemu.

PHP 8.1 i starsze nie dostają już aktualizacji od projektu i nowych wydań dla nich nie ma. Ze względu na wagę luk zespół PHP przygotował jednak minimalne poprawki w kodzie źródłowym dla PHP 7.4, 8.0 i 8.1, udostępnione w osobnych gałęziach na GitHubie. Są przeznaczone dla osób, które same kompilują PHP i nie mają dostawcy wsparcia długoterminowego. Część dystrybucji i dostawców ma własne poprawki dla starszych wersji. Na zwykłym hostingu rozsądniej jest przejść na wspieraną gałąź.

Zmianę gałęzi 8.2 też trzeba zaplanować, bo jej wsparcie kończy się za nieco ponad dwa miesiące. WordPress w wymaganiach zaleca PHP 8.3 lub nowsze. Na zdjęciu na górze strony jest ElePHPant, maskotka języka PHP (fot. Atomic Taco, Wikimedia Commons, licencja CC BY-SA 2.0, kadr przycięty).

Jak sprawdzić wersję PHP w WordPressie

Wersję PHP pokazuje sam WordPress, na ekranie Stan witryny. Nie potrzebujesz do tego dostępu do serwera.

1. Zaloguj się do kokpitu WordPressa jako administrator.
2. Wejdź w Narzędzia → Stan witryny.
3. Otwórz zakładkę Informacja.
4. Rozwiń sekcję Serwer i znajdź pozycję Wersja PHP.

Dokumentacja WordPressa zaznacza, że ten ekran tylko informuje i niczego na nim nie zmienisz. Ustawienia serwera, w tym wersję PHP, zmienia się w panelu hostingu albo u dostawcy. W angielskiej wersji WordPressa ścieżka brzmi Tools → Site Health → Info.

Jak sprawdzić i zmienić wersję PHP na hostingu

Na hostingu współdzielonym wybierasz w panelu gałąź PHP, a nowe wydanie w jej obrębie, na przykład 8.3.x z poprawką, musi wgrać na serwer dostawca. Zapytaj więc swojego hostingodawcę, czy zainstalował już poprawione wersje. Na własnym serwerze VPS albo dedykowanym aktualizujesz PHP sam, zwykle przez menedżera pakietów systemu.

Ścieżki w panelach trzech polskich dostawców według ich stron pomocy (odczyt 21.10.2026):

• cyber_Folks (DirectAdmin): dział “Serwer WWW i domeny” → “Wersja PHP dla domen” → wybór wersji → “Ustaw”. Wersję dla wiersza poleceń zmienia się osobno.
• nazwa.pl (CloudHosting Panel): zakładka WWW I FTP → PHP i Node.js → sekcja Ustawienia PHP. Lista obejmuje wersje od 8.2, starsze są płatną usługą dodatkową. Zmiana dotyczy całego serwera.
• home.pl: Panel klienta → Usługi WWW → wybrana usługa → sekcja Serwer WWW → Ustawienia → Preferencje serwera → Interpreter PHP. Ustawienie obejmuje cały serwer. Dostawca zaleca wersję 8.2 i wyższe.

home.pl nadal pozwala wybrać PHP od 5.6, a nazwa.pl udostępnia wersje 5.3–8.1 za dopłatą. Obecność wersji na liście w panelu nie oznacza więc, że jest wspierana. Na serwerze z dostępem do terminala polecenie php -v pokaże wersję dla wiersza poleceń. Strona może jednak działać na innej, co cyber_Folks podkreśla w swojej instrukcji.

Co zrobić po wydaniu poprawek PHP

Poprawki są dostępne, więc teraz chodzi o to, żeby jak najszybciej trafiły na Twój serwer:

1. Sprawdź wersję PHP w WordPressie albo w panelu hostingu. Poprawione są wydania 8.5.12, 8.4.27, 8.3.36 i 8.2.35.
2. Zrób kopię zapasową plików i bazy danych. nazwa.pl ostrzega, że powrót do poprzedniej wersji PHP nie gwarantuje powrotu do prawidłowego działania stron.
3. Ustal, kto aktualizuje PHP: hostingodawca, agencja czy Ty. Jeśli stronę prowadzi firma zewnętrzna, zapytaj ją, kiedy wgra poprawione wydanie.
4. Zaplanuj zmianę gałęzi na stronach z PHP 8.1 i starszym. Najpierw zaktualizuj WordPressa, motyw i wtyczki. home.pl udostępnia w panelu raport zgodności z wybraną wersją interpretera PHP.

Numer wersji ze Stanu witryny porównaj z tabelą wyżej. Jeśli kopie WordPressa robisz wtyczką UpdraftPlus, przy okazji sprawdź też klucz zdalnego zarządzania, opisany przy wycieku kluczy UpdraftCentral. Aktualizacje samego WordPressa omawialiśmy przy rządowej rekomendacji aktualizacji WordPressa.

Co zrobić, jeśli nie możesz od razu zaktualizować PHP

Zespół PHP podaje w ogłoszeniu środki tymczasowe, ale zastrzega, że pełnym rozwiązaniem jest tylko aktualizacja. Te kroki zmniejszają ryzyko na wybranych ścieżkach ataku, a instalacja nadal nie jest bezpieczna. Wprowadza je administrator serwera, nie właściciel strony w kokpicie WordPressa.

• CVE-2026-109618: niski limit post_max_size (8 MB bez przesyłania plików, 32 MB z przesyłaniem) i limit pamięci na poziomie kontenera albo cgroup. Ogłoszenie wymienia też memory_limit=-1, czyli zniesienie limitu pamięci PHP. Zespół zaznacza jednak, że błąd przydziału pamięci na niższym poziomie nadal może trafić w podatny kod, a sam limit kontenera opisuje jako granicę dostępności serwera.
• CVE-2026-109619: session.upload_progress.enabled=0 w php.ini albo w konfiguracji puli FPM i restart wszystkich procesów PHP, a na PHP 8.5 dodatkowo fatal_error_backtraces=0. Zespół pisze, że to blokuje potwierdzone ścieżki ataku, ale nie inne warianty.

Kto wyłączał usługi przed poprawkami i co zaleca CERT Polska

Część instytucji nie czekała na wydanie i z ostrożności wyłączyła usługi oparte na PHP:

• Holandia: według rządowego serwisu Veiliginternetten niedostępne były m.in. DigiD, MijnOverheid, część stron prowincji i strona parlamentu Tweede Kamer. Swoją stronę wyłączyło też krajowe centrum cyberbezpieczeństwa NCSC.
• Finlandia: państwowe centrum IT Valtori wyłączało publiczne serwisy administracji, podało Yle.
• Niemcy: Uniwersytet we Fryburgu zdjął centralne strony uczelni.
• Wikimedia wyłączyła m.in. Phabricator, Toolforge, Cloud VPS i translatewiki.net. Wikipedii nie ma na tej liście.

W Polsce portEl.pl wyłączył dodawanie zdjęć do czasu instalacji poprawki, a czytanie serwisu działało bez zmian. home.pl zapowiedział, że na swoim hostingu wgra poprawki sam i klient “nie musi nic robić”. Na serwerze VPS albo dedykowanym PHP trzeba zaktualizować samodzielnie.

CERT Polska w komunikacie 195/2026 zalecał przed wydaniem “zinwentaryzowanie wszystkich usług korzystających z PHP oraz przygotowanie do natychmiastowego wdrożenia poprawki zaraz po jej udostępnieniu”. Do tego czasu radził “tymczasowe wyłączenie usług wykorzystujących PHP dostępnych z Internetu, o ile nie zakłóci to działalności organizacji”. Teraz, gdy poprawki są dostępne, ważniejsza od wyłączania jest szybka aktualizacja.

FAQ

Czy luki w PHP dotyczą WordPressa?

Luki są w PHP, czyli w środowisku, na którym działa WordPress, a nie w kodzie WordPressa. Dlatego aktualizacja samego WordPressa ich nie załata. Potrzebne jest poprawione wydanie PHP na serwerze: 8.5.12, 8.4.27, 8.3.36 albo 8.2.35. Na serwerach z pakietami z dystrybucji Linuksa sprawdź komunikat dostawcy systemu, bo poprawka może przyjść w pakiecie o innym numerze.

Czy strona na PHP 8.1 dostanie poprawkę?

Nie w formie zwykłego wydania. Gałąź 8.1 nie jest wspierana od 1 stycznia 2026 roku i zespół PHP nie wydał dla niej nowej wersji. Przygotował tylko minimalne poprawki w kodzie źródłowym dla 7.4, 8.0 i 8.1, z których skorzystają osoby kompilujące PHP same. Część dystrybucji i hostingodawców łata starsze wersje we własnym zakresie, więc zapytaj dostawcę. Bezpieczna droga to przejście na wspieraną gałąź, najlepiej 8.3 lub nowszą, po sprawdzeniu zgodności motywu i wtyczek.

{ strony www }

Strona firmowa, która zbiera zapytania od klientów

Projektujemy strony dla firm na WordPressie: szybkie, wygodne na telefonie i przygotowane pod Google. Pomożemy też napisać treści, które jasno tłumaczą, co sprzedajesz.

Zobacz, jak projektujemy strony → Software house, który prowadzi ten blog

Podsumowanie

Zespół PHP wydał 21 października 2026 roku wersje 8.5.12, 8.4.27, 8.3.36 i 8.2.35. Łatają one dwie krytyczne luki, CVE-2026-109618 i CVE-2026-109619, z oceną 9,2 w skali CVSS 4.0. Luki mogą pozwolić uruchomić obcy kod na serwerze bez logowania. Ryzyko dotyczy wszystkich instalacji obsługujących strony, a najwyższe jest przy Apache z modułem mod_php. PHP 8.1, 8.0 i 7.4 nie dostały nowych wydań, tylko minimalne poprawki w kodzie źródłowym. Część instytucji, od holenderskich serwisów rządowych po Wikimedię, wyłączyła usługi do czasu poprawek. Wersję PHP sprawdzisz w WordPressie w Narzędzia → Stan witryny → Informacja → Serwer albo w panelu hostingu. Zrób kopię zapasową i ustal, kto u Ciebie zainstaluje poprawione wydanie. Środki tymczasowe z ogłoszenia zmniejszają ryzyko, ale nie zastępują aktualizacji.

Mateusz Wojdalski

Specjalista SEO i content marketingu w Devstock. Zajmuję się strategią treści, automatyzacją procesów marketingowych i wdrożeniami AI w codziennej pracy. Badam nowe narzędzia, adaptuję je do realnych zadań i piszę o tym, co faktycznie działa.