
Krytyczne luki w starych wersjach PHP: dlaczego brak aktualizacji PHP do wersji 8.3 lub nowszej to otwarte drzwi dla hakera?
21 października 2026 r. projekt PHP opublikował poprawki dla dwóch krytycznych podatności w samym interpreterze języka — CVE-2026-109618 i CVE-2026-109619, nazwanych wspólnie „PHP2Shell”. W ciągu kilku godzin internet obiegła fala ostrzeżeń. W Polsce Ministerstwo Cyfryzacji poinformowało, że Centralny Ośrodek Informatyki prewencyjnie wyłączył część stron Biuletynu Informacji Publicznej. Podobne decyzje podjęły instytucje publiczne m.in. w Niemczech, Francji, Belgii, Holandii, Finlandii i Wielkiej Brytanii. Wyłączenia miały charakter zapobiegawczy — chodziło o to, by zdążyć z aktualizacją, zanim zrobią to atakujący.
Główny przekaz jest prosty: każda wersja PHP bez tej poprawki pozwala napastnikowi przejąć kontrolę nad stroną bez znajomości loginu i hasła. Najgorzej jest w przypadku starych gałęzi — 7.x, 8.0 i 8.1 — oraz niezałatanych instalacji 8.2, bo te albo nie dostaną już oficjalnej poprawki, albo wkrótce stracą wsparcie. W tym artykule wyjaśniamy, na czym polega zagrożenie, co oznacza dla firmy i jak krok po kroku zabezpieczyć serwer.
Anatomia zagrożenia – czym są luki RCE i dlaczego wywołały panikę w sieci?
RCE (Remote Code Execution), czyli zdalne wykonanie kodu, oznacza, że atakujący może przez internet uruchomić na Twoim serwerze dowolne polecenie — tak, jakby siedział przy jego klawiaturze. Może odczytać pliki, podmienić stronę, zainstalować własne oprogramowanie albo przejść dalej, do bazy danych.
Luki PHP2Shell mają ocenę 9,2 w skali CVSS v4.0, czyli poziom krytyczny (source: cloud.google.com, Responding to core PHP vulnerabilities). W uproszczeniu:
- CVE-2026-109618 — PHP źle sprząta po sytuacji, w której zabraknie mu pamięci, i zostawia uszkodzone dane, które da się wykorzystać.
- CVE-2026-109619 — proces PHP może skorzystać z danych pozostałych po poprzednim żądaniu, choć ich pamięć została już zwolniona.
Brak potrzeby uwierzytelnienia sprawia, że te luki są wyjątkowo groźne. Atakujący nie potrzebuje konta w WordPressie, PrestaShop ani w panelu administratora. Wystarczy odpowiednio przygotowane żądanie wysłane do strony. Błąd tkwi w interpreterze, a nie w CMS-ie, dlatego aktualizacja wtyczek czy motywu przed nim nie chroni. Zagrożone są wszystkie popularne sposoby uruchamiania PHP: PHP-FPM, moduł Apache, php-cgi, FrankenPHP i LiteSpeed (source: securitylabs.datadoghq.com, PHP2Shell).
Problem z łataniem starych wersji. Poprawki trafiły do wydań PHP 8.2.35, 8.3.36, 8.4.27 i 8.5.12. Gałęzie 8.1 i starsze zakończyły już cykl wsparcia (End-of-Life), więc nie dostały oficjalnych wydań z poprawką. CERT Polska wskazuje, że dla takich wersji łatek trzeba szukać u dostawcy dystrybucji lub oprogramowania — a to rozwiązanie tymczasowe, nie docelowe.
Ataki są zautomatyzowane. Nikt nie sprawdza stron ręcznie. Boty i skanery przeczesują internet w poszukiwaniu podatnych serwerów, a według Datadog pierwsze próby wykorzystania luk pojawiły się jeszcze przed ich oficjalnym ujawnieniem. Mała firmowa strona jest dla bota tak samo atrakcyjnym celem jak duży portal.
Jakie ryzyko niesie nieaktualne PHP dla sklepu e-commerce i strony firmy?
Przejęty serwer to nie tylko problem techniczny. To realne koszty dla biznesu:
- Kradzież bazy danych i danych osobowych. Dane klientów, hasła i historia zamówień mogą trafić w ręce przestępców. Wyciek danych osobowych to obowiązek zgłoszenia naruszenia do UODO i ryzyko wysokich kar wynikających z RODO.
- Iniekcja złośliwego kodu (malware i webshelle). Atakujący dokleja do strony skrypty, które przekierowują klientów na fałszywe strony, wyłudzają dane albo podszywają się pod bramkę płatności. Webshell zostawia mu stały dostęp nawet po zmianie haseł.
- Wykorzystanie serwera do ataków. Przejęty serwer może po cichu kopać kryptowaluty, wysyłać spam lub działać w botnecie. Kończy się to przeciążeniem, blokadą konta przez dostawcę albo wpisaniem adresu IP na czarne listy (RBL), przez co Twoje e-maile przestają docierać do klientów.
- Straty wizerunkowe i spadek pozycji w Google. Zainfekowana strona może zostać oznaczona jako niebezpieczna w przeglądarkach i w Google Search Console. Odbudowa zaufania klientów trwa znacznie dłużej niż sama aktualizacja.
Jak sprawdzić, z jakiej wersji PHP korzysta Twoja strona?
Sprawdzenie wersji zajmuje kilka minut. Wybierz sposób, który najbardziej Ci odpowiada.
Panel hostingu. W DirectAdmin wejdź w „Administracja domenami”, wybierz domenę i sprawdź, która wersja PHP jest przypisana do plików .php. W cPanelu szukaj w sekcji „Oprogramowanie” opcji „Wybór wersji PHP” (lub „MultiPHP Manager”). W innych panelach informacja jest zwykle w ustawieniach domeny lub serwera WWW.
WordPress. Zaloguj się do kokpitu i przejdź do: Narzędzia → Stan witryny → Informacje → Serwer. Wersję PHP znajdziesz w tej sekcji.
PrestaShop. W panelu administracyjnym otwórz Parametry zaawansowane → Informacja. W sekcji informacji o serwerze zobaczysz wersję PHP.
Plik info.php (dla administratorów). Utwórz w katalogu strony plik info.php z jedną linią:
<?php phpinfo();
Otwórz go w przeglądarce (twojadomena.pl/info.php) i odczytaj wersję z nagłówka. Natychmiast po sprawdzeniu usuń plik — pokazuje on szczegóły konfiguracji serwera, które ułatwiają atak.
Pamiętaj, że sama gałąź (np. „8.3”) nie wystarczy — liczy się pełny numer wydania. Jeśli Twój serwer korzysta z pakietów dystrybucji Linuksa, poprawka może mieć inny numer wersji, dlatego sprawdź komunikat bezpieczeństwa dystrybucji.
Status wsparcia wersji PHP
| Wersja PHP | Status wsparcia | Poprawki bezpieczeństwa do | Ryzyko |
|---|---|---|---|
| 5.x, 7.x | koniec wsparcia (EOL) | już nie | krytyczne |
| 8.0 | koniec wsparcia (EOL) | już nie | krytyczne |
| 8.1 | koniec wsparcia (EOL) | już nie (od 31.12.2025) | krytyczne |
| 8.2 | tylko poprawki bezpieczeństwa | 31.12.2026 | wysokie bez 8.2.35, wkrótce koniec wsparcia |
| 8.3 | tylko poprawki bezpieczeństwa | 31.12.2027 | niskie od 8.3.36 |
| 8.4 | pełne wsparcie | 31.12.2028 | niskie od 8.4.27 |
| 8.5 | pełne wsparcie | 31.12.2029 | niskie od 8.5.12 |
Daty według harmonogramu wsparcia projektu PHP (php.net/supported-versions).
Dlaczego docelowym standardem powinno być PHP 8.3 (lub nowsze)?
Pełne wsparcie i oficjalne łatki bezpieczeństwa. PHP 8.2 otrzymało poprawkę PHP2Shell, ale jego wsparcie bezpieczeństwa kończy się już 31 grudnia 2026 r. Przejście na 8.2 oznacza więc kolejną migrację za nieco ponad dwa miesiące. PHP 8.3 jest wspierane do końca 2027 r., a 8.4 i 8.5 — jeszcze dłużej. Każda nowo odkryta podatność zostanie w nich załatana.
Skok wydajnościowy. Kolejne wersje PHP 8 przynoszą optymalizacje silnika, które zwykle przekładają się na szybsze ładowanie stron, większą liczbę obsługiwanych żądań na sekundę i mniejsze zużycie procesora oraz pamięci. Dla sklepu internetowego to krótszy czas odpowiedzi i lepsze doświadczenie klienta.
Nowoczesne mechanizmy języka. Nowsze PHP lepiej zgłasza błędy i zapewnia zgodność z aktualnymi wersjami wtyczek, motywów oraz frameworków, takich jak Laravel czy Symfony. Twórcy oprogramowania coraz częściej rezygnują ze wsparcia starych gałęzi, więc pozostanie na nich blokuje także aktualizacje samej aplikacji.
Plan działania – co zrobić, jeśli nadal używasz starej wersji PHP?
- Wykonaj pełną kopię zapasową. Zabezpiecz bazę danych i wszystkie pliki strony, zanim cokolwiek zmienisz. Upewnij się, że kopię da się odtworzyć.
- Zrób szybki audyt kompatybilności. Sprawdź, czy motyw, wtyczki i autorskie moduły obsługują PHP 8.3 lub nowsze. Informację znajdziesz zwykle na stronie wtyczki lub w dokumentacji producenta.
- Przetestuj na środowisku stagingowym. Przełącz wersję PHP na kopii roboczej strony i przeklikaj najważniejsze funkcje: logowanie, koszyk, formularze, płatności.
- Zaktualizuj oprogramowanie. Podnieś wersję CMS-a, wtyczek i szablonów do najnowszych wydań — starsze często nie działają na nowym PHP.
- Zmień wersję w panelu hostingu. Przełącz interpreter PHP na wersję 8.3 lub nowszą i sprawdź logi błędów po zmianie.
Jeśli administrujesz własnym serwerem, po aktualizacji pakietów zrestartuj wszystkie procesy PHP-FPM lub serwera WWW — bez tego w pamięci nadal działa stara, podatna wersja. Jak zaplanować taką zmianę bez przestoju, opisujemy w artykule o oknach serwisowych. Dodatkową warstwę ochrony może stanowić Web Application Firewall, ale nie zastąpi on aktualizacji. Przy okazji warto sprawdzić także Node.js — 21 października jego twórcy wydali poprawki dla dziesięciu podatności w wersjach 22.23.4, 24.22.1 i 26.12.1.
Podsumowanie i rekomendacja eksperta
Odkładanie aktualizacji PHP to dziś świadome akceptowanie ryzyka, że strona zostanie przejęta przez automatycznego bota — bez włamywania się na konto administratora i bez znajomości haseł. Rekomendujemy jedną zasadę: docelowo PHP 8.3 lub nowsze, zawsze w najnowszym wydaniu danej gałęzi. Więcej sposobów na zabezpieczenie strony znajdziesz w artykule jak skutecznie chronić stronę opartą na WordPress.
Jesteś klientem hostingu Sprint Data Center i Twoja strona działa na starszej wersji PHP? Skontaktuj się z naszym supportem — sprawdzimy, z jakiej wersji korzystasz, ocenimy, czy strona jest gotowa na PHP 8.3, i zaproponujemy bezpieczną ścieżkę migracji. Jeśli potrzebujesz pełnej kontroli nad wersją PHP, rozważ serwer VPS, na którym samodzielnie zainstalujesz i zaktualizujesz aktualne PHP. Masz serwer dedykowany i chcesz oddać aktualizacje w ręce specjalistów? Sprawdź nasze pakiety administracyjne, obejmujące m.in. aktualizacje systemu i monitoring usług.
FAQ – najczęściej zadawane pytania o aktualizację PHP do wersji 8.3
Czy moja strona jest zagrożona, jeśli korzystam z PHP 8.3?
Tak, jeśli to wydanie sprzed poprawki. Luki PHP2Shell dotyczą wszystkich wersji od 5.4 do 8.5.11. W gałęzi 8.3 bezpieczne jest wydanie 8.3.36 lub nowsze albo pakiet dystrybucji z poprawką. Sprawdź pełny numer wersji, a nie tylko gałąź.
Czy aktualizacja WordPressa i wtyczek chroni przed lukami PHP2Shell?
Nie. Luki tkwią w samym interpreterze PHP, a nie w WordPressie, motywach czy wtyczkach. Aktualizacja CMS-a jest potrzebna, ale przed tym zagrożeniem chroni wyłącznie aktualizacja PHP do poprawionej wersji.
Dlaczego nie wystarczy przejść na PHP 8.2?
PHP 8.2 otrzymało poprawkę w wydaniu 8.2.35, ale wsparcie bezpieczeństwa dla tej gałęzi kończy się 31 grudnia 2026 r. Wybierając 8.2, już na początku 2027 r. stajesz przed kolejną migracją. PHP 8.3 jest wspierane do końca 2027 r.
Czy po zmianie wersji PHP moja strona przestanie działać?
Może się tak zdarzyć, jeśli motyw, wtyczki lub własny kod nie są zgodne z nową wersją. Dlatego przed zmianą zrób kopię zapasową, zaktualizuj oprogramowanie i przetestuj stronę na kopii roboczej. W razie problemów możesz wrócić do poprzedniej wersji w panelu.
Jak sprawdzić wersję PHP bez dostępu do panelu hostingu?
W WordPressie przejdź do Narzędzia → Stan witryny → Informacje → Serwer, a w PrestaShop do Parametry zaawansowane → Informacja. Administrator może też utworzyć plik z funkcją phpinfo(), pamiętając, by usunąć go od razu po sprawdzeniu.
Artykuł powstał z wykorzystaniem narzędzi sztucznej inteligencji (AI) pod nadzorem zespołu Sprint Data Center. Grafika ilustracyjna została wygenerowana przez AI.
