Najważniejsze wnioski w pigułce
Co i kiedy
- Zespół bezpieczeństwa PHP zapowiedział wydanie poprawek na środę, 21 października 2026 roku, o 14:00 UTC, czyli o 16:00 czasu polskiego.
- Aktualizacja usuwa dwie krytyczne podatności, obie z oceną 9,2 w skali CVSS v4.0.
- Zespół PHP zastrzega, że może opublikować poprawki wcześniej, jeśli szczegóły luk wyciekną albo pojawią się dowody aktywnego wykorzystywania.
Czego jeszcze nie wiemy
- Lista podatnych wersji, opis luk i numery wersji z poprawkami zostaną opublikowane dopiero razem z wydaniem.
- Na tę chwilę nie da się więc stwierdzić, czy dana instalacja jest narażona. Rozsądniej założyć, że tak, i przygotować się na aktualizację.
Co zrobić teraz
- Sprawdź, na jakiej wersji PHP działa każda Twoja strona, sklep i aplikacja.
- Zaplanuj okno serwisowe na 21 października po południu i ustal, kto odpowiada za aktualizację.
- Przygotuj kopię zapasową oraz środowisko testowe, aby wdrożyć poprawkę w ciągu godzin, a nie tygodni.
Co dokładnie ogłosił zespół PHP
Zespół bezpieczeństwa PHP rzadko uprzedza o wydaniu poprawek z wyprzedzeniem. Zazwyczaj nowe wersje po prostu pojawiają się na stronie projektu z adnotacją, że zawierają poprawki bezpieczeństwa. Tym razem jest inaczej: 20 października 2026 roku opublikowano komunikat, że już następnego dnia, 21 października o 14:00 UTC, pojawi się wydanie usuwające dwie krytyczne podatności. Taki tryb komunikacji ma jeden cel - dać administratorom czas na przygotowanie się, zanim szczegóły luk staną się publiczne.
Komunikat jest celowo oszczędny. Nie zawiera opisu podatności, listy wersji, których dotyczą, ani numerów wersji z poprawkami. Wszystkie te informacje zostaną ujawnione dopiero w chwili wydania. To standardowa praktyka przy poważnych lukach, bo zbyt wczesne ujawnienie szczegółów ułatwiłoby atakującym przygotowanie exploitów, zanim ktokolwiek zdąży się zabezpieczyć.
Ważne jest też zastrzeżenie, że wydanie może pojawić się wcześniej niż zapowiedziano. Stanie się tak, jeśli szczegóły którejś z luk przedostaną się do opinii publicznej albo jeśli pojawią się dowody, że są już wykorzystywane w realnych atakach. W praktyce oznacza to, że godzina 16:00 czasu polskiego to termin najpóźniejszy, a nie gwarantowany.
Co oznacza ocena 9,2 w skali CVSS
CVSS (Common Vulnerability Scoring System) to standardowa skala od 0 do 10, w której ocenia się powagę podatności. Wartości od 9,0 wzwyż oznaczają kategorię krytyczną, czyli najwyższą w całej skali. Wersja 4.0 tego systemu dokładniej niż poprzednie uwzględnia m.in. warunki ataku i jego skutki dla poufności, integralności oraz dostępności systemu. Dwie luki z wynikiem 9,2 to sygnał, że nie chodzi o drobne usterki, które można spokojnie nadrobić przy kolejnym przeglądzie technicznym.
Z perspektywy biznesu najważniejsze jest to, że PHP napędza ogromną część internetu. Działają na nim m.in. WordPress, WooCommerce, PrestaShop, Magento i aplikacje oparte na Laravelu czy Symfony. Jeśli prowadzisz stronę firmową, blog albo sklep internetowy, istnieje duża szansa, że gdzieś pod spodem pracuje właśnie interpreter PHP. Podatność w samym języku oznacza potencjalne zagrożenie dla każdej aplikacji uruchomionej na niezałatanej wersji, niezależnie od tego, jak dobrze zabezpieczona jest sama wtyczka czy motyw.
Do momentu publikacji szczegółów nie wiadomo, jakiego rodzaju są to luki ani jakie warunki muszą być spełnione, aby je wykorzystać. Dlatego nie warto spekulować, tylko przygotować procedurę, która pozwoli wdrożyć poprawkę od razu po jej udostępnieniu. Doświadczenie pokazuje, że czas między publikacją poprawki a pierwszymi zautomatyzowanymi atakami bywa bardzo krótki.
Które wersje PHP są dziś wspierane
Kontekstu dostarcza archiwum komunikatów PHP z ostatnich tygodni. 24 września 2026 roku zespół PHP wydał równolegle cztery wydania bezpieczeństwa: PHP 8.2.34, 8.3.35, 8.4.26 oraz 8.5.11. Dzień wcześniej trwały też testy PHP 8.6.0, które 8 października doszło do etapu RC3, a kolejne wydanie kandydujące, RC4, zaplanowano na 22 października. Wersje testowe gałęzi 8.6 nie są przeznaczone do użytku produkcyjnego.
Z tej listy wynika ważny praktyczny wniosek. Jeśli Twoja strona działa na wersji starszej niż 8.2, nie pojawiła się ona w ostatniej, wrześniowej serii poprawek bezpieczeństwa. Szczegóły dotyczące wersji objętych październikowym wydaniem poznamy dopiero 21 października. Mimo to już teraz warto sprawdzić, czy aplikacje nie działają na gałęzi, która przestała otrzymywać łatki. W takim przypadku samo czekanie na poprawkę niczego nie rozwiąże, bo poprawka może dla tej wersji w ogóle się nie ukazać.
Migracja na nowszą gałąź PHP to zwykle większe przedsięwzięcie niż podbicie numeru wersji w obrębie tej samej gałęzi. Starsze wtyczki, moduły sklepów i niestandardowy kod mogą wymagać dostosowania. Jeśli korzystasz z platformy takiej jak PrestaShop, warto śledzić także zmiany po stronie samego silnika sklepu, o których pisaliśmy przy okazji bety PrestaShop 9.2 z jednoetapowym checkoutem . Kompatybilność wersji PHP z oprogramowaniem sklepu to jeden z pierwszych punktów do sprawdzenia przed każdą większą aktualizacją.
Plan działania na 21 października
Pierwszy krok to inwentaryzacja. Dla każdej domeny i aplikacji ustal, na jakiej wersji PHP działa, kto nią zarządza i czy aktualizację wykonuje hosting, czy Twój zespół. Na hostingu współdzielonym poprawki często instaluje dostawca, ale to Ty w panelu wybierasz gałąź PHP. Jeśli wybrana jest wersja, która nie jest już wspierana, łatka do Ciebie nie trafi.
Drugi krok to przygotowanie zaplecza. Zrób pełną kopię zapasową plików i bazy danych, a jeśli masz środowisko testowe, upewnij się, że odpowiada konfiguracji produkcyjnej. Dzięki temu po publikacji poprawki możesz w kilkanaście minut sprawdzić, czy kluczowe ścieżki działają, zwłaszcza koszyk, formularze kontaktowe, logowanie i integracje z płatnościami. Ustal też z góry, kto 21 października po 16:00 czuwa nad wdrożeniem i kto podejmuje decyzję o wycofaniu zmian, gdyby coś poszło nie tak.
Trzeci krok to dokumentacja i kontrola po wdrożeniu. Zapisz, kiedy i na jakich serwerach wykonano aktualizację oraz do jakiej wersji. Taki rejestr przydaje się przy analizie ewentualnych zmian w ruchu, co dobrze pokazuje praktyka opisana w tekście o tym, jak duże zespoły prowadzą SEO changelog . Po aktualizacji warto też sprawdzić wydajność strony, na przykład za pomocą PageSpeed Insights , bo zmiana wersji interpretera może wpłynąć na czas odpowiedzi serwera.
Bezpieczeństwo serwera a widoczność w Google
Aktualizacja PHP wydaje się zadaniem czysto technicznym, ale jej zaniedbanie potrafi uderzyć bezpośrednio w marketing. Przejęte strony bywają wykorzystywane do wstrzykiwania spamowych podstron, ukrytych linków czy przekierowań na podejrzane domeny. Skutkiem mogą być ostrzeżenia w przeglądarkach, ręczne działania ze strony Google i gwałtowny spadek ruchu organicznego, którego odbudowa trwa często znacznie dłużej niż samo usunięcie infekcji.
Dlatego aktualność oprogramowania serwera traktujemy jako stały element higieny technicznej, obok szybkości ładowania, poprawnej indeksacji i bezpiecznego połączenia. Jeśli chcesz uporządkować te obszary kompleksowo, punkt wyjścia znajdziesz w naszym przewodniku po technical SEO w formie checklisty . Po wdrożeniu poprawek warto też przez kilka dni obserwować Google Search Console pod kątem nieoczekiwanych błędów indeksowania, nowych adresów URL czy komunikatów o problemach z bezpieczeństwem.
Podsumowanie
21 października 2026 roku, najpóźniej o 16:00 czasu polskiego, PHP opublikuje poprawki dwóch krytycznych luk ocenionych na 9,2 w skali CVSS v4.0. Szczegóły i listę podatnych wersji poznamy dopiero w dniu wydania, ale przygotowania warto zacząć od razu: sprawdzić wersje PHP, przygotować kopie zapasowe i wyznaczyć osoby odpowiedzialne za wdrożenie. Szybka reakcja to najtańszy sposób, by ochronić zarówno dane, jak i wypracowaną widoczność w wyszukiwarce.
Źródło: PHP.net - News Archive 2026, „Upcoming Critical PHP Security Release” (otwiera się w nowej karcie)
