Jeśli Twoja strona albo aplikacja działa na PHP, sprawdź dziś dwie rzeczy: wersję PHP i to, czy hosting wgrał poprawki z 21 października. Luki opisywane jako PHP2Shell pozwalają w najgorszym przypadku uruchomić cudzy kod na serwerze bez logowania. Zespół PHP zapowiedział ich poprawki 20 października 2026, a dzień później wyszły poprawione wersje. Poniżej: co zrobić teraz, kogo to dotyczy i co, jeśli aplikacja działa na PHP 8.1 lub starszym.
Co zrobić teraz
- Sprawdź wersję PHP, na której działa strona. Pokazuje ją panel hostingu, a jeśli jej tam nie ma, zapytaj firmę hostingową albo programistę, który utrzymuje system.
- Upewnij się, że serwer ma poprawkę. Poprawione wydania to PHP 8.2.35, 8.3.36, 8.4.27 i 8.5.12 lub nowsze. Najpewniej jest poprosić hosting o potwierdzenie, bo pakiety niektórych dystrybucji Linuksa mają poprawkę pod starszym numerem wersji.
- Na PHP 8.1 lub starszym zapytaj hosting, czy przygotował poprawkę dla tej wersji, i zaplanuj przejście na wspieraną wersję PHP.
- Jeśli poprawki nie da się wgrać od razu, ogranicz dostęp do aplikacji z internetu i skontaktuj się z hostingiem. Szczegóły niżej.
Co się stało
Zespół PHP opisał dwie luki: CVE-2026-109618 i CVE-2026-109619, obie z oceną 9.2 w skali CVSS 4.0. Dotyczą instalacji PHP, które obsługują ruch ze stron internetowych: PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. W najgorszym przypadku pozwalają osobie z zewnątrz, bez logowania, uruchomić własny kod na serwerze.
Szczegóły luk trafiły do sieci jeszcze 20 października, przed publikacją poprawek. Poprawione wersje wymienia komunikat zespołu PHP, który mówi też wprost, że jedynym bezpiecznym rozwiązaniem jest aktualizacja – zmiany w konfiguracji serwera tylko utrudniają atak.
Skuteczność ataku zależy od konfiguracji serwera i aplikacji, więc nie każdy serwer da się zaatakować równie łatwo. To jednak nie powód, żeby czekać.
Kogo to dotyczy
- PHP 8.2, 8.3, 8.4 lub 8.5 – wystarczy aktualizacja PHP na serwerze, którą na hostingu robi firma hostingowa. Sam numer gałęzi, np. „8.3”, nie mówi jeszcze, czy poprawka jest zainstalowana. Liczy się konkretne wydanie albo potwierdzenie od hostingu.
- PHP 8.1 lub starsze – te wersje nie są już wspierane i nie dostają oficjalnych wydań z poprawkami. Dla PHP 7.4, 8.0 i 8.1 zespół PHP udostępnił tylko poprawki w kodzie źródłowym, więc to, czy trafią na Twój serwer, zależy od dostawcy. Zapytaj o to hosting, a niezależnie od odpowiedzi zaplanuj przejście na wspieraną wersję, bo przy następnej luce te wersje znów zostaną bez oficjalnej poprawki.
Jest też druga data: PHP 8.2 dostaje poprawki bezpieczeństwa tylko do 31 grudnia 2026. Aplikacja na PHP 8.2 za dwa miesiące będzie w tej samej sytuacji co aplikacje na 8.1. Dlatego przy aktualizacji celuję w PHP 8.3 lub nowsze – wersja 8.3 dostaje poprawki do końca 2027 roku, 8.4 do końca 2028.
Gdy aktualizacji nie da się zrobić od razu
Zmiany w konfiguracji PHP, które opisał zespół PHP, utrudniają atak, ale nie zastępują poprawki. Jeśli serwera nie da się zaktualizować od razu, Qualys zaleca ograniczyć dostęp do aplikacji z internetu albo ją odizolować – na przykład zamknąć panel administracyjny czy system wewnętrzny za listą dozwolonych adresów IP albo VPN-em. Firmę hostingową powiadom od razu, a nie dopiero przy migracji kodu.
Najpierw zabezpieczenie, potem migracja
Zabezpieczenie serwera i przeniesienie aplikacji na nowe PHP to dwie różne sprawy. Pierwsze trzeba zrobić od razu, drugie wymaga planu, a jeśli kod jest bardzo stary, czasem także modernizacji aplikacji legacy. Na większości hostingów wersję PHP dla domeny zmienia się jednym kliknięciem w panelu, ale stara aplikacja zwykle nie uruchomi się na nowej wersji. Kolejne wydania PHP usuwają przestarzałe funkcje i zaostrzają typy, a każda wersja Laravela obsługuje określony zakres PHP:
- Laravel 10 – PHP 8.1-8.3, poprawki bezpieczeństwa zakończone w lutym 2025,
- Laravel 11 – PHP 8.2-8.4, poprawki bezpieczeństwa zakończone w marcu 2026,
- Laravel 12 – PHP 8.2-8.5, poprawki bezpieczeństwa do 24 lutego 2027,
- Laravel 13 – PHP 8.3-8.5, poprawki bezpieczeństwa do 17 marca 2028.
Laravel 9 i starsze oficjalnie nie obsługują PHP 8.3. W praktyce aplikacja na Laravelu 7, którą niedawno aktualizowałem, nie uruchomiła się nawet na PHP 8.2. Do tego dochodzą biblioteki z Composera: część ma nowsze wersje, a część porzucono i trzeba je wymienić.
Jak wygląda aktualizacja
Tę aplikację przeniosłem z Laravela 7 na Laravela 13, z testami na PHP 8.3 i 8.5. Kroki są za każdym razem te same:
- Inwentaryzacja. Z pliku composer.lock wiem, jakie biblioteki są w aplikacji i w jakich wersjach. Próbna instalacja zależności na nowym PHP pokazuje, co blokuje aktualizację, zanim zmienię choćby linię kodu.
- Testy przed zmianą. Sprawdzam kluczowe ścieżki: logowanie, zamówienia, płatności, panel administracyjny. Jeśli aplikacja nie ma testów, zaczynam od nich.
- Aktualizacja krok po kroku. Laravel przechodzi przez kolejne wersje zgodnie z oficjalnymi przewodnikami, biblioteki dostają nowe wersje albo zamienniki, a kod – poprawki pod nowe PHP.
- Testy i przegląd po zmianie. Te same ścieżki co na początku, plus przegląd zmian, które nie wywołują błędów, ale zmieniają zachowanie aplikacji.
- Wdrożenie i wersja PHP na serwerze. Nowy kod trafia na produkcję z kopią zapasową, a wersję PHP dla domeny podnoszę w panelu hostingu albo ustalam to z firmą hostingową.
Bezpłatne sprawdzenie
Napisz mi przez formularz adres strony i wersję PHP z panelu hostingu. Jeśli znasz wersję Laravela, dopisz ją – pokazuje ją polecenie php artisan –version. Bez tych danych diagnoza jest wstępna, bo z samego adresu strony nie zawsze da się ustalić wersję PHP.
Jeśli do dokładniejszej diagnozy przyda się plik composer.lock z katalogu aplikacji, poproszę o niego w odpowiedzi. To lista bibliotek z wersjami i adresami, z których je pobrano, zwykle bez haseł i danych z bazy. Jeśli firma korzysta z prywatnych repozytoriów i w tych adresach są loginy albo tokeny, nie wysyłaj pliku – wystarczą same wersje.
W ciągu 1–2 dni odeślę krótką diagnozę: na czym działa aplikacja, co blokuje przejście na PHP 8.3+ i ile kosztuje aktualizacja.