Luka w zabezpieczeniach PHP 2026: jak sprawdzić i załatać narażone serwisy internetowe

Właściwa interpretacja komunikatu alarmowego

Stwierdzenie, że luka w zabezpieczeniach PHP może dotyczyć „połowy Internetu“, jest przesadnym chwytem reklamowym, ale nie ma potwierdzonej skali. Nie ma dowodów na to, że połowa wszystkich usług internetowych jest podatna na ataki lub została już przejęta. Rzeczywiste ryzyko jest jednak znaczne, ponieważ PHP jest wykorzystywane jako środowisko uruchomieniowe w wielu stronach internetowych, sklepach internetowych, interfejsach API i panelach administracyjnych.

Nie ma znaczenia, czy strona internetowa korzysta z PHP, ale to, która wersja PHP przetwarza jej żądania internetowe. Aktualizacje zabezpieczeń z 21 października 2026 r. dotyczą zasadniczo niezałatanych instalacji obsługiwanych gałęzi, o ile obsługują one żądania za pośrednictwem serwisu internetowego. Lokalną instalację PHP przeznaczoną do zadań programistycznych należy zatem traktować inaczej niż portal klienta dostępny z zewnątrz.

Die Widoczność w Internecie W dużej mierze decyduje o tym pilność sprawy. Publicznie dostępny sklep internetowy z formularzami i funkcją przesyłania plików oferuje więcej potencjalnych punktów kontaktu niż odizolowana usługa wewnętrzna. Jednak nawet usługa wewnętrzna nie jest automatycznie bezpieczna: dostęp przez VPN, przejęte konta lub inne systemy w sieci mogą sprawić, że stanie się ona dostępna. Sam zasięg nie zastępuje zatem technicznej oceny ryzyka.

Równie ważne są tryb pracy oraz Stojak na opony. PHP może działać na przykład za pośrednictwem PHP-FPM, jako moduł Apache’a, poprzez php-cgi lub jako część produktu. Wiele domen na tym samym serwerze może przy tym korzystać z różnych wersji i ścieżek aktualizacji. Ogólne zapewnienie o bezpieczeństwie wszystkich stron internetowych opartych na PHP byłoby równie błędne, jak założenie, że każda instalacja jest bezpośrednio narażona na atak.

Co z technicznego punktu widzenia umożliwiają luki w zabezpieczeniach PHP

A Zdalne wykonanie kodu (RCE) oznacza, że w określonych warunkach osoba atakująca może wykonać kod na zdalnym systemie. Zgodnie z komunikatem dotyczącym bezpieczeństwa w przypadku tych luk w zabezpieczeniach PHP nie jest wymagane wcześniejsze zalogowanie się. Kod byłby początkowo wykonywany z uprawnieniami procesu internetowego, a nie automatycznie z nieograniczonymi uprawnieniami administratora. Możliwe konsekwencje zależą zatem w dużym stopniu od uprawnień do plików, danych dostępowych oraz izolacji serwera.

Luka CVE-2026-109618 dotyczy ścieżek błędów w Niedobór pamięci. Jeśli PHP przerwie przetwarzanie żądania z powodu braku pamięci, wewnętrzne struktury danych mogą pozostać niekompletne. Jeśli takie struktury zostaną ponownie wykorzystane podczas czyszczenia żądania, może dojść do uszkodzenia pamięci. W oficjalnym opisie jako istotne konteksty techniczne wymieniono w szczególności żądania wieloczęściowe, przesyłanie plików oraz zużycie pamięci podczas analizowania zagnieżdżonych danych wejściowych.

Z kolei luka CVE-2026-109619 dotyczy stanu wewnętrznego powiązanego z żądaniem, którego pamięć została już zwolniona. Jeśli ponownie wykorzystany proces roboczy przetwarza następnie kolejne żądanie, PHP może uzyskać dostęp do tego nieaktualnego stanu, zanim zadziała normalna inicjalizacja. Komunikat dotyczący bezpieczeństwa odnosi się między innymi do postępu przesyłania sesji oraz ścieżek błędów. Opisuje to klasę błędów, a nie instrukcję wykorzystania luki.

• Problem ten może dotyczyć żądań internetowych przetwarzanych przez PHP-FPM, Apache z modułem mod_php, php-cgi, FrankenPHP oraz LiteSpeed.
• Błędy występują w środowisku uruchomieniowym PHP, a nie przede wszystkim w WordPressie, Joomli, Shopware, motywach czy poszczególnych wtyczkach.
• Systemy CMS i frameworki mają wpływ na dostępne funkcje, takie jak przesyłanie plików, ale nie zastępują aktualizacji interpretera.

Dlaczego nie każda instalacja jest narażona na takie samo ryzyko

To, czy usługa jest faktycznie zagrożona, zależy od kilku czynników. Największe znaczenie mają niezałatane środowisko uruchomieniowe PHP oraz dostępna usługa internetowa. Kolejne czynniki to tryb pracy, ponownie wykorzystywane procesy, funkcje umożliwiające przesyłanie plików lub złożone formularze, a także uprawnienia konta procesu internetowego. Usługa posiadająca szerokie uprawnienia do zapisu w plikach internetowych lub dostęp do innych usług może mieć poważniejsze konsekwencje niż projekt ściśle odizolowany.

W przypadku Apache’a z mod_php W projekcie PHP szczególnie podkreśla się kwestię ryzyka: udokumentowany atak może zostać zainicjowany jeszcze przed uruchomieniem właściwego kodu aplikacji. Nawet starannie utrzymywany system CMS nie chroni wówczas przed tą luką w czasie działania. Nie oznacza to jednak, że PHP-FPM, php-cgi, FrankenPHP czy LiteSpeed można uznać za bezpieczne; w przypadku braku aktualizacji należy je również sprawdzić w pierwszej kolejności.

Szczególnej uwagi wymagają ponadto produkty zawierające wbudowanym PHP. Mogą to być obrazy kontenerów, urządzenia typu appliance, systemy zarządzania NAS lub produkty sieciowe, których interfejs użytkownika wykorzystuje wewnętrznie PHP. W takich przypadkach polecenie uruchomione na hoście często nie pokazuje faktycznie używanego środowiska uruchomieniowego. Aktualizacja systemu operacyjnego nie usuwa również automatycznie podatnego na ataki komponentu PHP w obrazie lub produkcie producenta.

Zapora sieciowa, zapora aplikacji internetowych (WAF) lub restrykcyjne limity przesyłania danych mogą utrudniać przetwarzanie poszczególnych żądań i ograniczać powierzchnię ataku. Nie zastępują one jednak poprawki, ponieważ nie korygują błędnego zarządzania pamięcią i stanem w interpreterze. Nawet bezbłędny system CMS pozostaje uzależniony od bezpiecznego środowiska uruchomieniowego. Dlatego kluczowe znaczenie ma sprawdzenie i aktualizacja wersji poprawek PHP, który faktycznie przetwarza żądania internetowe.

Porównaj aktualne wersje poprawek i status wsparcia technicznego

W przypadku obu luk w zabezpieczeniach decydujące znaczenie ma przede wszystkim stan aktualizacji w ramach używanej gałęzi PHP. Projekt PHP podaje konkretne, poprawione wersje dla obsługiwanych serii. Wcześniejsze wersje tej samej serii są uznawane za podatne na te luki; pełnym rozwiązaniem problemu jest aktualizacja do wskazanej lub nowszej wersji tej gałęzi.

A Aktualizacja poprawki pozostaje w tej samej gałęzi rozwoju, na przykład z wersji 8.3.35 do 8.3.36. Ma ona na celu dostarczenie poprawki bezpieczeństwa i charakteryzuje się węższym zakresem kompatybilności niż przejście z wersji 8.2 na 8.4. To ostatnie stanowi migrację: w tym przypadku należy oddzielnie sprawdzić zależności, rozszerzenia, kod aplikacji oraz, w razie potrzeby, wdrożenie.

PHP 8.2 nadal można wykorzystywać do doraźnego usuwania błędów, o ile używana jest co najmniej wersja 8.2.35. Wsparcie dla tej gałęzi wygaśnie jednak 31 grudnia 2026 r. Dlatego nie należy pozostawać przy tej aktualizacji: należy zaplanować przejście na gałąź objętą dłuższym wsparciem po sprawdzeniu zgodności aplikacji w odpowiednim środowisku.

W przypadku PHP 8.1 i starszych wersji należy zachować szczególną ostrożność. Projekt PHP nie udostępnia w tym zakresie regularnych, aktualnych wydań; minimalne backporty kodu źródłowego nie są równoznaczne z powszechnie dostępnym, aktualizowanym pakietem. Backport zabezpieczeń udokumentowany przez dostawcę systemu operacyjnego może być odpowiednim rozwiązaniem, wymaga jednak potwierdzenia w biuletynie bezpieczeństwa lub dzienniku zmian pakietu. W przypadku jego braku konieczna jest migracja, a nie jedynie kosmetyczna zmiana wersji.

Sprawdź rzeczywisty czas działania strony internetowej

Sprawdzanie wersji zaczyna się od przeglądu stanu, ale nie może kończyć się na powłoce. Na serwerze zarządzanym samodzielnie poniższe polecenia wyświetlają wersję wywołanego tam polecenia PHP oraz pliki konfiguracyjne znalezione podczas tego wywołania. Nie powodują one zmian ani w pakietach, ani w konfiguracji, dlatego nadają się jako pierwszy, mało ryzykowny etap sprawdzania.

php -v
php --ini

Wynik opisuje wyłącznie tę, która została wywołana za pomocą tego polecenia powłoki Środowisko uruchomieniowe CLI. Natomiast strona internetowa może być obsługiwana za pomocą PHP-FPM, serwera Apache z modułem mod_php, php-cgi lub kontenera. To środowisko uruchomieniowe może korzystać z innej wersji PHP i innych plików konfiguracyjnych niż polecenie php -v na serwerze. Dla oceny bezpieczeństwa decydujące znaczenie ma proces, który przetwarza rzeczywiste żądania HTTP.

W ramach hostingu zarządzanego należy zatem sprawdzić w panelu klienta wersję PHP wybraną dla danego projektu lub domeny oraz, w razie potrzeby, zasięgnąć informacji o stanie aktualizacji udostępnianej usługi. W przypadku wielu domen należy sprawdzić każdą przypisanie z osobna: domena główna może już korzystać z zaktualizowanej gałęzi, podczas gdy sklep internetowy, instancja testowa lub subdomena nadal korzystają ze starszej wersji interpretera.

Na serwerach z PHP-FPM konfiguracja usługi, zawartość pakietów i dokumentacja wdrożeniowa stanowią spójną całość. W środowiskach kontenerowych należy dodatkowo sprawdzić faktycznie wdrożony obraz, a nie tylko lokalny manifest kompilacji. Decydujące znaczenie ma to, która wersja w uruchomionym podzie lub kontenerze obsługuje żądania sieciowe; zaktualizowany obraz bazowy nie chroni starszej instancji, która już działa.

Planowanie ścieżek aktualizacji w zależności od trybu pracy

Właściwy sposób aktualizacji zależy od tego, kto dostarcza interpreter i gdzie jest on uruchamiany. Dopiero po ustaleniu tego zakresu odpowiedzialności można wiarygodnie zdecydować, czy konieczna jest zmiana panelu, aktualizacja pakietu, nowy obraz systemu czy aktualizacja od producenta. Poniższa klasyfikacja rozróżnia te przypadki, nie traktując jednakowo poszczególnych trybów pracy pod względem ryzyka.

W przypadku hostingu współdzielonego dostawca powinien zapewnić bezpieczny stan poprawek dla wybranej serii PHP; operator sprawdza następnie działanie aplikacji. W przypadku PHP-FPM lub mod_php administrator zazwyczaj aktualizuje pakiety, a następnie w kontrolowany sposób ponownie uruchamia odpowiednią usługę. Samo ponowne uruchomienie bez zainstalowanej poprawki nie zastępuje aktualizacji.

Dystrybucje Linuksa często udostępniają poprawki bezpieczeństwa w postaci Backport. W takim przypadku widoczny numer wersji pakietu może różnić się od wersji opublikowanych na stronie php.net, mimo że poprawka została uwzględniona. Dlatego nie należy porównywać wyłącznie ciągów znaków, takich jak „8.4.26“, ale należy zapoznać się z komunikatem dotyczącym bezpieczeństwa oraz dziennikiem zmian udostępnionym przez dystrybutora. Projekt PHP zwraca uwagę, że dystrybucje i dostawcy wersji LTS mogą otrzymywać poprawki.

Kontenery wymagają osobnego procesu: należy zbudować poprawiony obraz lub pobrać go od dostawcy, wdrożyć go i zastąpić nim stare instancje. Natomiast w przypadku interfejsów NAS, urządzeń sieciowych lub gotowych aplikacji internetowych poprawki leżą po stronie producenta produktu. Poprawka systemu operacyjnego hosta niekoniecznie dociera do wbudowanego interpretera; dlatego też niezbędne pozostają inwentaryzacja i wytyczne producenta.

Działania natychmiastowe bez fałszywego poczucia bezpieczeństwa

W dniu aktualizacji najpierw przygotuj sobie rzetelny spis zasobów: domeny, interfejsy API, interfejsy administracyjne, kontenery i produkty, w których może być wbudowany PHP. Dla każdej usługi zanotuj tryb działania serwisu, odpowiednią ścieżkę aktualizacji oraz faktycznie używane środowisko uruchomieniowe PHP. Następnie priorytet otrzymuje każda usługa dostępna publicznie lub o znaczeniu krytycznym dla działalności, a nie tylko serwer z najbardziej rzucającym się w oczy numerem wersji.

Następnie zainstaluj aktualizację zabezpieczeń udostępnioną przez dostawcę usług hostingowych, dystrybutora systemu Linux, twórcę obrazu lub producenta oprogramowania. W przypadku obsługiwanych gałęzi PHP aktualizacja do poprawionej wersji łaty stanowi pełne rozwiązanie problemu; nie zastępują jej ani zapora WAF, ani reguły przesyłania plików, ani ponowne uruchomienie serwera WWW. Należy zaplanować tę operację w taki sposób, aby aktualizacja pakietów, obrazów lub oprogramowania producenta została przejrzyście udokumentowana i można było ją prześledzić w razie problemów.

Po aktualizacji należy wszyscy dawni pracownicy należy je zakończyć i zastąpić procesami, które w sposób potwierdzony załadowały poprawioną wersję środowiska uruchomieniowego. Z funkcji ponownego ładowania należy korzystać tylko wtedy, gdy konkretny system zarządzania usługami gwarantuje tę całkowitą wymianę; w przeciwnym razie konieczne jest kontrolowane ponowne uruchomienie. Następnie sprawdź czasy uruchomienia procesów, status usług lub wewnętrznie ustalony czas działania środowiska internetowego, zamiast po prostu zakładać, że wymiana się powiodła. W przypadku kontenerów wdrażasz poprawiony obraz i usuwasz wszystkie stare instancje.

Następnie sprawdź kluczowe ścieżki aplikacji, takie jak logowanie, formularze, przesyłanie plików, proces realizacji transakcji oraz interfejsy API. Testy wykazują, czy aplikacja i rozszerzenia działają z aktualnym zestawem poprawek; same w sobie nie potwierdzają jednak ani całkowitej wymiany węzłów roboczych, ani braku wcześniejszych naruszeń bezpieczeństwa. Kwestie te należy oceniać oddzielnie w ramach audytów operacyjnych i bezpieczeństwa.

Jeśli w krótkim czasie nie da się zastosować poprawki, poszczególne ustawienia mogą ograniczyć znane ścieżki ataku, ale nie zapewnią pełnego bezpieczeństwa. Wyłączenie wskaźnika postępu przesyłania musi zacząć działać przed przetworzeniem żądania. Należy najpierw sprawdzić, czy aplikacje lub interfejsy użytkownika wymagają tego wskaźnika postępu, a następnie ponownie uruchomić każdy odpowiedni proces roboczy PHP. Następnie należy upewnić się, że żaden stary proces nie działa dalej z poprzednim ustawieniem.

session.upload_progress.enabled = 0

Konserwatywne ograniczenia dotyczące danych POST oraz inne opcje wymienione w komunikacie dotyczącym bezpieczeństwa również mogą jedynie częściowo zmniejszyć powierzchnię ataku. Dane odczytywane z opóźnieniem .user.ini-pliki lub jeden ini_set() W ramach aplikacji te działania nie są wystarczające. Traktuj je jako tymczasowe ograniczenie ryzyka i nadal traktuj aktualizację zabezpieczeń jako cel.

Należy to odróżnić od zwykłego zarządzania zapisanymi sesjami. Artykuł na temat Zbieranie śmieci w sesjach PHP wyjaśnia, w jaki sposób podczas normalnej pracy współdziałają mechanizmy czyszczenia, dostęp do plików i procesy robocze. Ta optymalizacja działania nie usuwa jednak omówionych tutaj luk w zabezpieczeniach i nie zastępuje ani poprawionej wersji poprawki PHP, ani późniejszej wymiany uruchomionych procesów.

Po zainstalowaniu aktualizacji należy sprawdzić działanie i ewentualne nieprawidłowości

Pomyślnie zakończona aktualizacja pakietu świadczy na razie jedynie o tym, że zainstalowano pliki lub pakiety. Nie potwierdza ona ani tego, że proces internetowy załadował nowe środowisko uruchomieniowe, ani tego, że aplikacja działa z nim bezbłędnie. Dlatego po ponownym uruchomieniu należy sprawdzić środowisko uruchomieniowe odpowiadające danej usłudze i udokumentować czas, wersję, ponownie uruchomioną usługę oraz wynik kontroli działania.

Testowanie funkcjonalne powinno obejmować rzeczywiste kluczowe procesy: ważne strony publiczne, logowanie i wylogowanie, wysyłanie formularzy, przesyłanie plików, realizację transakcji lub rezerwację, a także punkty końcowe API i zadania wykonywane w tle. Testuj wyłącznie operacje, do których masz uprawnienia, a w przypadku sklepów produkcyjnych korzystaj w miarę możliwości z danych testowych przeznaczonych do tego celu. Równolegle sprawdzaj logi serwera WWW, PHP i aplikacji pod kątem nowych błędów, powtarzających się awarii lub nieoczekiwanych kodów statusu.

Konieczne jest rozpoczęcie od nowa, aby stworzyć trwałe procesy i Pracownik załadowanie zaktualizowanego kodu nie powoduje jednak samo w sobie usunięcia luki. Bez zainstalowanej aktualizacji luka pozostaje. W przypadku dużego obciążenia okno serwisowe należy wybrać tak, aby żądania mogły być przetwarzane w sposób uporządkowany, a skutki ponownego uruchomienia procesu roboczego pozostawały widoczne.

To, w jakim stopniu kontrolowane ponowne uruchomienie wpływa na przepustowość, zależy od liczby i obciążenia procesów PHP. Przy planowaniu warto uwzględnić kolejki, uruchomione zadania i krytyczne transakcje, zamiast kończyć procesy w sposób nieskoordynowany. Przewodnik Zrozumieć procesy robocze PHP wyjaśnia rolę tych procesów w przypadku równoległych zapytań dynamicznych.

Jeśli po zainstalowaniu poprawki pojawią się nieprawidłowości, należy odróżnić błędy kompatybilności aplikacji od niepełnego wdrożenia. Należy porównać konfigurację, aktywowane rozszerzenia oraz środowisko uruchomieniowe aplikacji internetowej ze stanem sprzed konserwacji. Cofnięcie aktualizacji nie może powodować, że usługa dostępna publicznie pozostanie trwale w stanie podatnym na ataki; w takim przypadku należy szybko ustalić kompatybilną ścieżkę aktualizacji z zainstalowaną poprawką.

Priorytet dla starych i ukrytych instalacji PHP

Szczególną uwagę należy poświęcić systemom, w których PHP nie jest widoczne jako świadomie zainstalowane środowisko uruchomieniowe: obrazom Docker, urządzeniom wirtualnym, serwerom NAS i interfejsom sieciowym, a także gotowym produktom oprogramowania. Aktualizacja hosta nie powoduje automatycznej aktualizacji obrazu kontenera ani wewnętrznego środowiska uruchomieniowego dostarczonego wraz z produktem producenta. Dlatego należy zwrócić się bezpośrednio do producenta z prośbą o ocenę sytuacji oraz o aktualizację zabezpieczeń dla konkretnego produktu.

W przypadku starszych gałęzi należy wyraźnie rozróżnić trzy przypadki. Regularnie obsługiwana wersja PHP otrzymuje aktualizacje zabezpieczeń publikowane przez projekt PHP. Backport dystrybucji lub dostawcy może zawierać poprawkę pomimo odmiennego widocznego numeru wersji, musi jednak być potwierdzony komunikatem dotyczącym bezpieczeństwa lub dziennikiem zmian tego dostawcy. Natomiast samodzielnie utrzymywany kod źródłowy wymaga natomiast ponoszenia własnej odpowiedzialności za kompilację, testowanie i eksploatację; nie stanowi on równoważnego zamiennika standardowego kanału aktualizacji.

PHP 8.1 i starsze gałęzie nie otrzymują już regularnych wydań z głównego repozytorium. Chociaż dla PHP 8.2 dostępna jest poprawiona wersja z poprawkami, wsparcie dla tej gałęzi wygaśnie pod koniec 2026 roku. Skorzystaj z dostępnej poprawki w nagłych przypadkach, ale w przypadku starych lub wycofywanych wersji zaplanuj dodatkowo przetestowaną Migracja na gałąź, która będzie dłużej obsługiwana.

1. W pierwszej kolejności należy zaktualizować usługi dostępne publicznie, w których środowisko uruchomieniowe PHP nie zostało jeszcze zaktualizowane, zwłaszcza jeśli umożliwiają one przesyłanie plików lub zawierają funkcje administracyjne.
2. Należy niezwłocznie zająć się kwestią serwera Apache z modułem mod_php oraz sklepami internetowymi o znaczeniu krytycznym dla działalności, interfejsami API lub portalami klienckimi; oficjalny komunikat dotyczący bezpieczeństwa podkreśla, że moduł mod_php stanowi szczególnie poważne zagrożenie.
3. Rejestrowanie kontenerów, urządzeń i produktów innych producentów na podstawie obrazów, spisu zasobów i statusu producenta; brak widocznych pakietów PHP nie oznacza, że wszystko jest w porządku.
4. Należy odizolować usługi, które nie są obsługiwane lub których nie da się szybko załatać, oraz ograniczyć do nich dostęp, planując jednocześnie w sposób wiążący ich zastąpienie, aktualizację lub migrację.

Segmentacja sieci, obowiązkowe korzystanie z VPN lub restrykcyjne zasady dostępu mogą dać trochę czasu w przypadku interfejsów administracyjnych, których nie da się natychmiast załatać. Są one jednak jedynie Środki przejściowe, ponieważ wewnętrzne konta użytkowników, zainfekowane urządzenia i nieprawidłowo skonfigurowane udostępnienia mogą nadal stanowić punkty wejścia dla ataków. Jeśli dla danego produktu nie jest dostępna poprawka lub gałąź PHP nie jest już objęta wsparciem, rozsądnym rozwiązaniem jest wymiana lub migracja.