Krytyczne poprawki PHP z 21 października: co właściciel sklepu na PrestaShop i WooCommerce robi dziś, a co zleca hostingowi

Ta wiadomość nie dotyczy Twojej platformy, tylko języka, na którym ona działa. 21 października zespół bezpieczeństwa PHP wydał poprawki dwóch krytycznych luk w samym PHP. Na PHP działa PrestaShop, WordPress z WooCommerce, a także Magento. Dobra wiadomość: w większości przypadków poprawkę instaluje hosting, nie Ty. Gorsza: musisz sprawdzić, czy to zrobił, i nie zakładać tego w ciemno. Pokazuję, co sprawdzić dziś, o co zapytać i co zaplanować na spokojniej.

Stan na 23 października 2026 r. Opieram się na komunikacie bezpieczeństwa PHP z 21 października oraz na ostrzeżeniach PrestaShop i WooCommerce z tego samego dnia.

Co się stało 21 października

Dzień wcześniej, 20 października, zespół PHP zapowiedział wydanie poprawek bezpieczeństwa i podał, że obie luki mają ocenę 9,2 w skali CVSS v4.0 (Common Vulnerability Scoring System), czyli w standardowej ocenie powagi podatności. Zespół PHP nazywa obie luki krytycznymi. 21 października ukazały się wersje z poprawką: PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35.

W publicznym rejestrze podatności CVE (Common Vulnerabilities and Exposures) luki mają numery CVE-2026-109618 i CVE-2026-109619. Te numery przydadzą Ci się w rozmowie z hostingiem. Bez technicznego żargonu: obie to błędy w tym, jak PHP zarządza pamięcią przy obsłudze zapytań. Według komunikatu PHP mogą pozwolić na zdalne wykonanie kodu na serwerze bez żadnego logowania. Zagrożone są wszystkie instalacje PHP, które obsługują zapytania ze stron internetowych.

Dla sklepu najważniejsze są dwa zdania z wpisu PrestaShop. Pierwsze: luki nie są w PrestaShop ani w żadnym module, więc „updating PrestaShop or your modules will not fix this”. Drugie: atak może zadziałać, zanim uruchomi się kod sklepu, więc zabezpieczenia w samym sklepie go nie zatrzymają. WooCommerce pisze to samo: aktualizacja WooCommerce ani WordPressa nie jest potrzebna i nie jest planowana, bo problem leży w PHP.

Czy to dotyczy Twojego sklepu

PrestaShop pisze wprost, że sprawa „concerns virtually every PrestaShop shop”, czyli praktycznie każdego sklepu na PrestaShop. WooCommerce dodaje, że luki dotyczą każdego serwera, na którym działa aplikacja w PHP. Pytanie nie brzmi więc „czy”, tylko „czy mój serwer jest już załatany”.

Zacznij od wersji PHP. Nie musisz logować się na serwer:

• PrestaShop: w panelu administracyjnym wejdź w Advanced Parameters > Information (w polskiej wersji panelu nazwy są przetłumaczone). Wersja PHP jest w sekcji z informacjami o serwerze.
• WooCommerce: w panelu WordPressa wejdź w Tools > Site Health > Info > Server (w polskiej wersji WordPressa nazwy są przetłumaczone). WooCommerce przypomina, że tę samą informację pokazuje zwykle panel hostingu.

Porównaj wynik z wersjami z poprawką: 8.5.12, 8.4.27, 8.3.36 albo 8.2.35, zależnie od gałęzi, na której stoisz. Jest tu jedno zastrzeżenie, które PrestaShop podkreśla. Dystrybucje Linuksa często łatają PHP bez zmiany numeru wersji. Niższy numer w panelu nie musi więc znaczyć, że serwer jest dziurawy, a wyższy jest dobrym znakiem, ale nie zwalnia z pytania. Ostateczną odpowiedź daje ten, kto zarządza serwerem.

Pytania do hostingu i do agencji

Jeżeli sklep stoi na hostingu współdzielonym albo zarządzanym, PHP aktualizuje hosting. Komunikat PHP mówi, że dystrybucje Linuksa i dostawcy wsparcia długoterminowego dostali poprawki wcześniej, a PrestaShop ocenia, że większość poważnych firm hostingowych już je wdraża. Twoja rola to dostać potwierdzenie na piśmie.

Wysłałbym dziś jedną wiadomość do hostingu z czterema pytaniami:

1. Czy poprawki CVE-2026-109618 i CVE-2026-109619 są już zainstalowane w wersji PHP, na której działa mój sklep? PrestaShop proponuje dokładnie to pytanie i radzi poprosić o pisemne potwierdzenie.
2. Jeśli nie, to kiedy będą, z datą.
3. Czy po aktualizacji procesy PHP zostały uruchomione ponownie? PrestaShop zwraca uwagę, że zainstalowana, ale niewczytana aktualizacja nie chroni.
4. Czy przed moim sklepem działa zapora aplikacji internetowych (WAF, web application firewall) z regułami na te luki? Oba wpisy wspominają WAF jako dodatkową warstwę na czas aktualizacji, nie zamiast niej.

Jeżeli serwer prowadzi agencja albo zewnętrzny administrator (własny serwer, chmura, kontenery), pytania są te same, tylko adresat inny. Gdy nikt nie czuje się za serwer odpowiedzialny, to jest najważniejsze odkrycie tego dnia. Zapisz je i ustal, kto przejmuje utrzymanie, zanim przyjdzie następna taka wiadomość.

Obejście, jeśli aktualizacja się opóźnia

Komunikat PHP podaje środki na czas, zanim aktualizacja będzie możliwa. Dla CVE-2026-109619 jest to m.in. ustawienie session.upload_progress.enabled=0 w konfiguracji serwera i ponowne uruchomienie wszystkich procesów PHP. Dla drugiej luki PHP opisuje ograniczenia rozmiaru zapytań i ustawienia pamięci. Zespół PHP zastrzega jednak wprost, że te środki zmniejszają narażenie na konkretne ścieżki ataku, ale nie czynią instalacji bezpieczną. W ogłoszeniach wydań stoi: „There are no complete mitigations, updating is the only safe choice”.

Dlatego nie traktowałbym tego jako instrukcji do samodzielnego wykonania. PrestaShop pisze, że te ustawienia są przeznaczone dla zespołów technicznych i hostingu, a przed wdrożeniem trzeba je przetestować na kopii sklepu, bo zbyt niskie limity mogą zepsuć np. import katalogu albo dodawanie zdjęć produktów. Jako właściciel sklepu zadaj jedno pytanie: „Jeśli aktualizacja PHP potrwa dłużej niż dziś, czy wdrożycie obejścia z komunikatu PHP i czy zapora WAF filtruje ruch do mojego sklepu?”. Wybór, które obejście, zostaw tym, którzy znają konfigurację serwera.

Stare PHP (przed 8.2): plan migracji

Tu zaczyna się część, która zajmie więcej niż jeden dzień. WooCommerce pisze: „Versions of PHP prior to 8.2 no longer receive security updates from the PHP project”. Komunikat PHP mówi to samo o wersji 8.1 i starszych. Dla PHP 7.4, 8.0 i 8.1 zespół PHP wyjątkowo przygotował minimalne poprawki w kodzie źródłowym, a część dystrybucji Linuksa łata starsze wersje sama. To pomoc dla tych, którzy kompilują PHP sami albo nie mają dostawcy wsparcia długoterminowego, a nie stały plan.

Jeżeli w panelu widzisz 7.4, 8.0 albo 8.1, kolejność jest taka:

• Dziś: zapytaj hosting, czy Twoja wersja PHP dostała poprawkę od dystrybucji albo dostawcy wsparcia. Bez tej odpowiedzi nie wiesz, czy sklep jest chroniony.
• W najbliższych tygodniach: zaplanuj przejście na wspieraną wersję. WooCommerce zaleca PHP 8.3 lub nowsze. PrestaShop przypomina, że sklepy na PrestaShop 1.7 i 8.x zwykle działają na PHP 7.x albo 8.1, i proponuje zaplanować przejście na PrestaShop 9.

PrestaShop dodaje rozsądną uwagę: aktualizacja platformy to osobny, dłuższy temat i nie jest awaryjną poprawką na te luki. Nie przenoś sklepu na nową wersję w pośpiechu, tylko po to, żeby zareagować na ten komunikat. Najpierw załatane PHP, potem migracja z testem motywu i modułów. O tym, jak sprawdzić wersję PHP i dlaczego celem nie jest najniższa wersja, która jeszcze działa, pisałem we wrześniu w tekście o wymaganiach PHP w WooCommerce.

Ten przypadek różni się od luki w Magento z września: tam błąd siedział w samej platformie, a poprawkę wydało Adobe. Tu platforma niczego nie łata, bo problem jest piętro niżej.

Co zrobić dziś, a co w najbliższym kwartale

Dziś:

1. Sprawdź wersję PHP w panelu sklepu i zapisz ją razem z datą.
2. Wyślij hostingowi albo agencji pytanie o CVE-2026-109618 i CVE-2026-109619 i poproś o pisemne potwierdzenie z datą wdrożenia.
3. Zapytaj, czy procesy PHP zostały uruchomione ponownie i czy przed sklepem działa zapora WAF.
4. Jeśli aktualizacja się opóźnia, zapytaj o obejścia z komunikatu PHP. Nie wprowadzaj ich sam na serwerze sklepu.

W najbliższym kwartale:

1. Jeśli stoisz na PHP starszym niż 8.2, zaplanuj migrację na wspieraną wersję i przetestuj ją na kopii sklepu.
2. Ustal, kto odpowiada za aktualizacje PHP i jak szybko masz dostać informację o kolejnej takiej poprawce.
3. Wpisz sprawdzanie wersji PHP do stałej listy przeglądów sklepu, obok aktualizacji platformy i modułów. Jeśli prowadzisz okres zamrożenia zmian przed sezonem, pamiętaj, że poprawki bezpieczeństwa są w nim wyjątkiem, a nie czymś, co czeka do stycznia.

Jeśli chcesz przejść ten przegląd razem i ustalić, co w Twoim sklepie da się zmienić bez ryzyka przed sezonem, umów rozmowę.