Krytyczna luka w PHP (21.10.2026) — jak sprawdzić, czy Twoja strona jest zagrożona

21 października 2026 roku projekt PHP wydał poprawki do dwóch krytycznych luk — CVE-2026-109618 i CVE-2026-109619. Obie pozwalają, w określonych konfiguracjach serwera, uruchomić obcy kod na maszynie obsługującej stronę, bez logowania się do niej. Oba błędy dostały ocenę 9,2 w dziesięciostopniowej skali CVSS 4.0. Ten tekst odpowiada na jedno pytanie, które właściciel strony powinien sobie dzisiaj zadać: jaką wersję PHP ma moja strona i czy jest w niej ta poprawka.

Krótka odpowiedź

• Wersje z poprawką: PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35. Wszystko poniżej jest podatne.
• Liczy się trzeci numer. „PHP 8.3” nie jest odpowiedzią — 8.3.21 jest podatne, 8.3.36 nie.
• Gdzie sprawdzić w minutę: panel WordPressa → Narzędzia → Stan witryny → Informacje → Serwer.
• To luka w PHP na serwerze, nie w WordPressie. Aktualizacja wtyczek i motywu jej nie naprawi.
• Na hostingu współdzielonym poprawkę wgrywa hostingodawca. Twoje zadanie: sprawdzić wersję i zapytać.

Czym jest zdalne wykonanie kodu

Strona internetowa działa tak, że serwer dostaje z przeglądarki żądanie, uruchamia program, który składa stronę, i odsyła gotowy wynik. Ten program to PHP.

Zdalne wykonanie kodu oznacza, że ktoś z zewnątrz potrafi tak przygotować żądanie, żeby serwer wykonał jego polecenia zamiast tylko złożyć stronę. Praktycznie: podmiana treści, dopisanie przekierowań, podłożenie skryptu wykradającego dane z formularzy albo z koszyka, dostęp do bazy danych. W advisory projektu PHP napisano, że kod wykonuje się z uprawnieniami procesu obsługującego stronę.

Słowo „nieuwierzytelnione” w opisie luki znaczy, że atakujący nie musi mieć żadnego konta, hasła ani linku — wystarczy, że strona odpowiada na żądania z internetu.

To luka w PHP, nie w WordPressie

To rozróżnienie decyduje o tym, co w ogóle ma sens zrobić.

Podatność siedzi w środowisku PHP na serwerze — w programie, który uruchamia Twoją stronę. Nie w WordPressie, nie w motywie, nie we wtyczce. Z tego wynikają dwie rzeczy, obie ważne.

Aktualizacja WordPressa, motywu i wtyczek nie naprawi podatnej wersji PHP. Możesz mieć najświeższy WordPress i wszystkie wtyczki w najnowszych wersjach, a serwer nadal będzie używał PHP z luką. To dwie osobne warstwy i aktualizuje je ktoś inny. Różnicę między tymi warstwami opisałem szerzej w tekście o aktualizacji strony internetowej.

I odwrotnie: to, że masz stronę na WordPressie, nie znaczy automatycznie, że jesteś zagrożony. O ryzyku decyduje wersja PHP na serwerze i sposób, w jaki serwer uruchamia PHP. Dotyczy to zresztą każdej strony opartej na PHP — WordPressa, WooCommerce, PrestaShopy, Joomli, phpMyAdmina — a nie tylko WordPressa.

Które wersje mają poprawkę

Według advisory projektu PHP podatne są wszystkie wydania poniżej tych numerów:

Gałąź PHP	Pierwsza wersja z poprawką
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

Zwróć uwagę na trzeci numer. To jedyna rzecz, która tu rozstrzyga. „PHP 8.3” nie jest odpowiedzią na pytanie, czy masz poprawkę — 8.3.21 jest podatne, a 8.3.36 nie. Panele hostingowe pokazują zwykle tylko dwa pierwsze numery, i to jest główny powód, dla którego ta sprawa bywa mylnie uznawana za załatwioną.

Z tego wynika też rzecz nieoczywista: przełączenie w panelu z PHP 8.3 na 8.4 niczego nie rozwiązuje, jeśli hostingodawca nie przebudował swoich pakietów. Dostaniesz wtedy nowszą gałąź bez poprawki.

Starsze wersje PHP

Gałęzie 8.1 i starsze nie dostają już wydań od projektu PHP — skończył się ich okres wsparcia. Projekt opublikował dla PHP 7.4, 8.0 i 8.1 jedynie minimalne poprawki w formie gałęzi źródłowych, bez oficjalnego wydania; skorzystanie z nich jest po stronie dostawcy systemu lub hostingu.

CERT Polska w komunikacie z 21 października napisał, że „podatne są wszystkie wersje PHP od 5.0 w górę”. Projekt PHP w swoich advisory nie dokumentuje tak szerokiego zakresu i nie potwierdzam go tutaj jako faktu. Dla właściciela strony to różnica bez znaczenia praktycznego: jeśli Twoja strona stoi na PHP 7.x albo 8.0/8.1, zejście z tej wersji jest konieczne niezależnie od tej luki, bo te gałęzie nie dostają poprawek bezpieczeństwa.

Dla planowania: PHP 8.2 ma poprawki bezpieczeństwa do 31 grudnia 2026 roku — potem kończy się i dla tej gałęzi.

Komu grozi najbardziej

Ryzyko nie jest jednakowe dla wszystkich i warto to wiedzieć, zanim wpadniesz w panikę albo odwrotnie — uznasz sprawę za cudzą. Advisory projektu PHP rozdziela je po sposobie, w jaki serwer uruchamia PHP:

• Apache z mod_php — najgorzej. Pełne zdalne wykonanie kodu zostało tu potwierdzone przez HTTP przy domyślnych ustawieniach. Advisory opisuje atak, który działa zanim uruchomi się jakikolwiek kod Twojej strony.
• PHP-FPM — podatny wedle analizy kodu, ale advisory stwierdza, że pełnego działającego exploita dla tej konfiguracji nie zademonstrowano.
• FrankenPHP — prawdopodobnie podatny, na podstawie analizy kodu.
• LiteSpeed (LSAPI) — advisory nazywa go kandydatem warunkowym, niezwalidowanym.

Większość polskiego hostingu współdzielonego działa na LiteSpeed. Nie wyciągaj z tego wniosku, że jesteś bezpieczny. Advisory pisze wprost, że brak zademonstrowanego exploita dla danej konfiguracji nie czyni jej odporną. To informacja o tym, czego jeszcze nie pokazano publicznie, nie o tym, czego nie da się zrobić.

Czy trwają ataki

Nie ma potwierdzenia, że tak. Projekt PHP opisuje zademonstrowany exploit, czyli kod dowodowy, a nie ataki w internecie. CISA na dzień wydania poprawek nie zaobserwowała wykorzystania, a żadne z dwóch CVE nie znalazło się w katalogu znanych wykorzystywanych podatności. Relacje firm zajmujących się bezpieczeństwem są sprzeczne — jedne mówią o pierwszych próbach, inne o braku obserwacji. Publicznie dostępny kod demonstracyjny istnieje.

To znaczy: pośpiech jest uzasadniony, bo od publicznego kodu do skanowania całego internetu bywa kilka godzin. Ale nikt rzetelny nie powie Ci dzisiaj, że Twoja strona jest atakowana.

Jak sprawdzić, jakiej wersji PHP używa Twoja strona

Stan witryny w WordPressie

W panelu WordPressa: Narzędzia → Stan witryny → zakładka Informacje → sekcja Serwer. W polu „Wersja PHP” zobaczysz pełny numer, z trzecim członem. To wersja, której używa rzeczywiście ta witryna — nie serwer w ogóle — i dlatego jest to odczyt najbardziej wiarygodny z dostępnych bez pomocy hostingu.

Jeżeli WordPress pokazuje ostrzeżenie o zalecanej aktualizacji PHP, to osobna sprawa dotycząca wersji gałęzi, a nie tej poprawki. Patrz na numer, nie na ostrzeżenie.

Panel hostingu

Nazwy opcji różnią się u każdego dostawcy. Najczęściej szukaj: „Wersja PHP”, „Ustawienia PHP”, „PHP Selector”, „Wybór wersji PHP” — w sekcji dotyczącej domeny albo konta WWW. Na części hostingów wersję ustawia się osobno dla każdej domeny, więc sprawdź tę właściwą, a nie ustawienie globalne.

Panel bardzo często pokaże tylko „8.3” albo „8.3.x”. To nie wystarczy, żeby stwierdzić, czy poprawka jest wgrana. Wtedy jedyną pewną drogą jest pytanie do hostingodawcy — niżej masz gotowe.

Gdy masz kilka stron

Każda domena może mieć inną wersję. Sprawdź wszystkie, nie jedną reprezentatywną. Stare, zapomniane instalacje na podkatalogach i subdomenach — testowe kopie, nieużywane sklepy, strony sprzed przebudowy — to w praktyce najczęstszy problem, bo nikt nie pamięta, że one dalej odpowiadają na żądania z internetu.

Co zrobić, gdy wersja jest podatna

Na hostingu współdzielonym

Nie masz dostępu do konfiguracji serwera i to jest w porządku — nie Ty za nią odpowiadasz. Twoje zadanie sprowadza się do trzech rzeczy:

1. Sprawdź wersję jedną z metod powyżej i zapisz, co zobaczyłeś.
2. Zapytaj hostingodawcę — pytania niżej. Jeśli ma zgłoszenia przez panel, zrób to tam, będziesz mieć ślad z datą.
3. Jeżeli panel pozwala przełączyć na wersję z poprawką, zrób to, ale najpierw wykonaj kopię zapasową plików i bazy. Zmiana wersji PHP może wyłączyć starą wtyczkę albo motyw, który nie jest z nią zgodny.

Czego nie robić: nie zmieniaj ustawień serwera na własną rękę, jeśli wymagają uprawnień administratora. W internecie pojawią się dziś porady, żeby wpisać ograniczenia do pliku .user.ini. W przypadku tych dwóch luk to nie zadziała — advisory projektu PHP wprost pisze, że ustawienia osłonowe nie działają przez ini_set() ani .user.ini i muszą być nałożone w php.ini albo w puli FPM, a potem wymagają restartu procesów. Czyli dokładnie tam, gdzie na hostingu współdzielonym nie masz dostępu.

Na własnym serwerze lub VPS

Zaktualizuj PHP do wersji z tabeli powyżej z repozytorium swojej dystrybucji lub dostawcy — dystrybucje Linuksa i dostawcy wsparcia długoterminowego otrzymali poprawki z wyprzedzeniem, więc numer wersji w pakiecie dystrybucji może wyglądać inaczej niż numer wydania PHP. Po aktualizacji zrestartuj wszystkie procesy obsługujące PHP. Dopóki stary proces żyje, obsługuje żądania starym kodem.

O doraźnych ograniczeniach

Projekt PHP opublikował zestaw ustawień zmniejszających ekspozycję i opisał je jednym zdaniem: nie ma pełnych ograniczeń doraźnych, jedynym bezpiecznym wyborem jest aktualizacja.

Nie wymieniam ich tutaj w formie instrukcji z dwóch powodów. Pierwszy: na hostingu współdzielonym nie da się ich poprawnie nałożyć, co opisałem wyżej. Drugi: podanie ich jako „co możesz zrobić w międzyczasie” tworzy wrażenie, że sprawa jest załatwiona, a nie jest. Jeśli administrujesz własnym serwerem i nie możesz zaktualizować od razu, sięgnij po oryginalne advisory — linki na końcu — i potraktuj te ustawienia jako kupienie czasu, nie naprawę.

Pytania do hostingodawcy

Skopiuj i wyślij. Pierwsze trzy są najważniejsze.

1. Jaką dokładnie wersję PHP, z pełnym numerem, obsługuje teraz domena mojadomena.pl?
2. Czy ta wersja zawiera poprawki do CVE-2026-109618 i CVE-2026-109619 z 21 października 2026?
3. Czy po wgraniu poprawki zrestartowano procesy PHP obsługujące moje konto? Bez restartu stare procesy nadal działają na podatnym kodzie.
4. Jeśli jeszcze nie — kiedy planowana jest aktualizacja i czy mam ustawić wersję w panelu sam?
5. Czy na moim koncie są domeny lub subdomeny na starszych gałęziach PHP (7.x, 8.0, 8.1), i jeśli tak, co się z nimi stanie?
6. W jakiej konfiguracji uruchamiane jest PHP — mod_php, PHP-FPM, LiteSpeed? To pozwala ocenić, jak pilna była sprawa w moim przypadku.

Dobra odpowiedź brzmi: pełny numer wersji, data przebudowy, potwierdzenie restartu. Odpowiedź „korzystamy z najnowszego PHP” nie jest odpowiedzią na żadne z tych pytań.

Jak sprawdzić, że po aktualizacji wszystko działa

Zmiana wersji PHP to najczęstsza przyczyna tego, że strona nagle przestaje działać — nie z powodu luki, a z powodu wtyczki, która nie przewidziała nowszego PHP. Po przełączeniu wersji przejdź:

• stronę główną i dwie podstrony — czy się wyświetlają, czy nie ma białego ekranu,
• formularz kontaktowy — wyślij testową wiadomość i sprawdź, czy przyszła,
• w sklepie: całą ścieżkę zakupu — produkt, koszyk, dane dostawy, wybór płatności, do etapu przed potwierdzeniem,
• panel administracyjny — czy logowanie i edycja treści działają, czy nie ma komunikatów o błędach wtyczek,
• wersję PHP jeszcze raz — w Stanie witryny, żeby potwierdzić, że przełączenie zadziałało.

Jeśli coś się wysypie, zwykle wystarczy wrócić w panelu do poprzedniej wersji, ustalić winną wtyczkę i zaktualizować ją albo zastąpić. Dlatego kopia przed zmianą, a nie po.

Kto za co odpowiada

Warto to nazwać, bo w praktyce tu giną takie sprawy:

• wersję PHP na serwerze aktualizuje hostingodawca albo administrator serwera,
• wybór wersji dla konkretnej domeny należy zwykle do właściciela konta — czyli do Ciebie,
• zgodność motywu i wtyczek z nowszym PHP jest po stronie osoby opiekującej się stroną,
• sprawdzenie, czy wszystko po zmianie działa jest po tej samej stronie.

Jeśli nikt tych rzeczy u Ciebie nie pilnuje na bieżąco, to nie kwestia tej jednej luki — opisałem to w tekście o tym, kto właściwie jest administratorem strony.

Checklista dla właściciela strony

• Sprawdziłem pełny numer wersji PHP (trzy liczby) w Stanie witryny albo w panelu hostingu.
• Zrobiłem to dla każdej swojej domeny i subdomeny, także dla starych kopii testowych.
• Porównałem z tabelą: 8.5.12 · 8.4.27 · 8.3.36 · 8.2.35.
• Jeśli wersja jest starsza — wysłałem pytania do hostingodawcy i mam ślad z datą.
• Mam kopię zapasową plików i bazy przed jakąkolwiek zmianą wersji.
• Po przełączeniu sprawdziłem: strona główna, dwie podstrony, formularz, ścieżka zakupu, panel.
• Potwierdziłem u hostingodawcy, że procesy PHP zostały zrestartowane.
• Mam zapisane, na jakiej wersji stoję i kiedy to sprawdzałem.

Jeśli nie wiesz, jaką wersję PHP ma Twoja strona, albo wolisz, żeby ktoś to sprawdził i zrobił porządek razem z aktualizacjami — zajmuję się opieką nad stronami WordPress. Mogę sprawdzić stan techniczny Twojej strony i powiedzieć, co wymaga uwagi. Nie sprawdzałem jej wcześniej i nie wiem, co na niej jest.

Pytania i odpowiedzi

Jak sprawdzić wersję PHP, nie mając dostępu do panelu hostingu?

W panelu WordPressa: Narzędzia → Stan witryny → Informacje → Serwer. Pole „Wersja PHP” pokazuje pełny numer dla tej konkretnej witryny. To wystarczy, żeby porównać go z tabelą.

Jaka wersja PHP jest dobra dla WordPressa?

Z punktu widzenia tej luki: dowolna z gałęzi 8.2, 8.3, 8.4 lub 8.5, pod warunkiem że numer jest równy albo wyższy od tego z tabeli. Z punktu widzenia dłuższej perspektywy warto być na 8.3 lub wyżej, bo PHP 8.2 przestanie dostawać poprawki bezpieczeństwa 31 grudnia 2026 roku.

Czy aktualizacja WordPressa i wtyczek mnie zabezpieczy?

Nie w tym przypadku. Luka jest w PHP na serwerze, a nie w WordPressie. Aktualizować i tak warto, ale tej konkretnej sprawy to nie rozwiązuje.

Mam stronę na WordPressie — czy to znaczy, że jestem zagrożony?

Nie automatycznie. Zależy to od wersji PHP na Twoim serwerze i od tego, jak serwer uruchamia PHP. Dlatego pierwszym krokiem jest sprawdzenie numeru wersji, a nie zakładanie jednego czy drugiego.

Czy mogę po prostu przełączyć PHP na najnowszą gałąź w panelu?

Nie zaszkodzi, ale samo przejście z 8.3 na 8.4 nie gwarantuje, że masz poprawkę — jeśli hostingodawca nie przebudował pakietów, dostaniesz nowszą gałąź bez niej. Liczy się trzeci numer. Przed przełączeniem zrób kopię zapasową, bo starsze wtyczki mogą nie być zgodne z nowszym PHP.

Skąd mam wiedzieć, czy ktoś już wykorzystał tę lukę na mojej stronie?

Pewności nie da się uzyskać z samego wyglądu strony. Sygnały warte uwagi: przekierowania na obce adresy, nieznane konta administratorów, pliki o dziwnych nazwach w katalogach WordPressa, ostrzeżenie Google w wynikach wyszukiwania, skoki ruchu wychodzącego. Opisałem to w tekście o tym, co zrobić przy zhakowanej stronie. Jeśli widzisz takie ślady, sprawa zaczyna się od usunięcia infekcji, nie od aktualizacji PHP — zabezpieczanie zainfekowanej instalacji zakłada, że atakujący nie ma już dostępu, a to zwykle nieprawda.

Czy trwają ataki na tę lukę?

Na dzień publikacji poprawek nie ogłoszono potwierdzonego wykorzystania. CISA nie zaobserwowała ataków, a żadne z dwóch CVE nie znalazło się w katalogu znanych wykorzystywanych podatności. Relacje firm bezpieczeństwa są rozbieżne. Publiczny kod demonstracyjny istnieje, więc odkładanie sprawy nie ma uzasadnienia.

Mam PHP 7.4 — co teraz?

Projekt PHP nie wydał dla tej gałęzi oficjalnej poprawionej wersji, tylko minimalną poprawkę w postaci gałęzi źródłowej; jej wykorzystanie zależy od Twojego dostawcy. Niezależnie od tej luki PHP 7.4 jest po końcu wsparcia i nie dostaje poprawek bezpieczeństwa — przejście na wspieraną gałąź jest konieczne, a nie opcjonalne.

Źródła

Wszystkie dostępne 21 października 2026.

• Projekt PHP — komunikat bezpieczeństwa i wydania 8.5.12, 8.4.27, 8.3.36, 8.2.35: php.net
• Advisory php-src dla CVE-2026-109618 („RCE via OOM corruption”): GHSA-w8hw-w9fx-j79w
• Advisory php-src dla CVE-2026-109619 („RCE via stale global state”): GHSA-6wmf-4rv5-p3rp
• Projekt PHP — wspierane wersje i daty końca wsparcia: php.net/supported-versions.php
• CERT Polska — komunikat 195/2026 z 21.10.2026: moje.cert.pl