Przeczytaj to najpierw. PHP wydało poprawki 21 października dla dwóch krytycznych luk. Jeśli Twój sklep działa na niezałatanym PHP, atakujący może być w stanie wykonać kod na serwerze bez logowania. Żadna z tych luk nie występuje w PrestaShop. Dzisiaj potrzebujesz trzech odpowiedzi: jaka wersja PHP jest uruchomiona, czy Twój hosting zastosował poprawkę (uzyskaj ją na piśmie) oraz czy PHP został od tego czasu zrestartowany.
Większość wiadomości o bezpieczeństwie dotyczy wtyczki lub motywu, a rozwiązaniem jest przycisk „Aktualizuj”. W tym przypadku jest inaczej. Problem tkwi w silniku sklepu, a rozwiązanie na serwerze, poza zasięgiem zaplecza. Dlatego łatwo to przeoczyć i dlatego trzeba poświęcić popołudnie, aby rozwiązać problem spokojnie i systematycznie.
Jak to się rozwinęło
Zespół PHP ostrzegł 20 października o zbliżających się aktualizacjach bezpieczeństwa. Zostały one odkryte 21 października i otrzymały numery CVE-2026-109618 i CVE-2026-109619. Obie luki uzyskały ocenę 9.2 w skali CVSS v4.0 i są dość krytyczne, dlatego też zyskały przydomek „php2shell”. Komisja Europejska (DG CNECT), ENISA, CERT-UE, Europol EC3 oraz sieć CSIRT wydały wspólne ostrzeżenie.
Komisja Europejska (DG CNECT), ENISA, CERT-EU, Europol EC3 i sieć CSIRT wydały następnie wspólne oświadczenie wzywające organizacje do przeniesienia się.
Poprawione wersje: PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35.
Co jest właściwie zepsute
Obie wady mogą skutkować zdalnym wykonaniem kodu bez uwierzytelnienia. Innymi słowy: obca osoba w internecie może zmusić Twój serwer do wykonania swoich instrukcji.
CVE-2026-109618 to problem z obsługą pamięci. Wyobraź sobie, że PHP buduje obszar roboczy dla przychodzącego żądania, a serwer w połowie procesu wyczerpuje pamięć. PHP zatrzymuje się, ale procedura czyszcząca zakłada, że niedokończony obszar roboczy jest kompletny i podejmuje odpowiednie działania.
CVE-2026-109619 to raczej kac. Coś, co należało do jednego żądania, nadal istnieje po zwolnieniu pamięci, a późniejsze żądanie w tym samym procesie roboczym może je przejąć i zaufać mu.
Zauważ, gdzie oba te elementy działają: w PHP. PrestaShop nie jest winny i nie może się przed nim obronić, ponieważ atak może nastąpić, zanim uruchomi się choćby jedna linijka kodu PrestaShop. Aktualizacja modułu lub rdzenia nic tu nie zmienia. Rozwiązaniem jest aktualizacja PHP.
Czyj to problem?
W zakresie możliwości jest każdy sposób uruchamiania PHP w sieci: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP i LiteSpeed. Apache z mod_php to najgorszy przypadek, ponieważ atak może zostać uruchomiony przed wykonaniem dowolnego kodu aplikacji.
To, co musisz zrobić, zależy od Twojego środowiska hostingowego i osoby zarządzającej Twoją instalacją PHP:
| Środowisko hostingowe | Kto zarządza PHP? | Rekomendowane działanie |
|---|---|---|
| Hosting www | Twój dostawca hostingu | Skontaktuj się ze swoim usługodawcą hostingowym i poproś o potwierdzenie, że odpowiednie poprawki zabezpieczeń PHP zostały zastosowane w Twoim środowisku. |
| VPS czy serwer dedykowany | Ty lub Twój administrator systemu | Zainstaluj odpowiednie aktualizacje zabezpieczeń dla swojej wersji PHP lub pakietu systemu operacyjnego, a następnie, jeśli to konieczne, uruchom ponownie odpowiednie usługi PHP. |
| Hosting Docker lub kontenerowy | Zespół odpowiedzialny za obraz kontenera | Odtwórz obraz, używając obrazu bazowego PHP z odpowiednimi poprawkami bezpieczeństwa, a następnie wdróż go ponownie i zweryfikuj środowisko uruchomieniowe. |
| Starsze lub nieobsługiwane wersje PHP | Twój dostawca hostingu lub administrator serwera | Sprawdź, czy dostępny jest backport bezpieczeństwa dostawcy. Jeśli nie, zaplanuj przejście na obsługiwaną wersję PHP po sprawdzeniu zgodności ze sklepem, motywem i modułami. |
Twoja lista kontrolna na dziś
- Sprawdź wersję PHP. Back Office, Parametry zaawansowane, Informacje.
- Napisz do swojego gospodarza. Zapytaj wprost: „Czy nasze serwery zostały załatane pod kątem luk CVE-2026-109618 i CVE-2026-109619 oraz czy wszystkie nasze procesy PHP zostały zrestartowane?”. Zachowaj otrzymaną odpowiedź. Wskazówka: niektóre dystrybucje po cichu stosują łatkę, pozostawiając numer wersji bez zmian; w związku z tym wiek numeru wersji nie może być wykorzystany do określenia, czy serwer jest podatny, czy nie.
- Zaktualizuj i uruchom ponownie. Przejdź do wersji stałej lub pakietu z poprawkami od dostawcy. Uruchom ponownie wszystkie procesy PHP. Ponowne uruchomienie to krok, o którym ludzie zapominają. W Dockerze przebuduj obrazy.
- Korzystasz z PHP 8.1 lub starszej wersji? Projekt PHP opublikował minimalne backporty dla wersji 7.4, 8.0 i 8.1, a wiele dystrybucji Linuksa i dostawców LTS udostępnia poprawione pakiety. Sprawdź, czy Twoja dystrybucja je udostępnia. Tak czy inaczej, zacznij planować migrację do wspieranej wersji.
- Pomyśl teraz o PrestaShop. Wybierz wersję, która obsługuje Twój docelowy PHP (tabela poniżej). Będzie ona dostępna po poprawce, a nie przed nią.
Nie można jeszcze zainstalować poprawki? Wytyczne UE wskazują na jedną opcję: odizolowanie narażonej aplikacji od sieci publicznej do czasu jej naprawy. To drastyczne dla sklepu, tak. Warto jednak mieć to w zanadrzu.
Zatrzymania, podczas gdy czekasz
PHP stoi na stanowisku, że żadne rozwiązanie nie jest kompletne, a aktualizacja to jedyne bezpieczne rozwiązanie. Potraktuj wszystko w tej sekcji jako sposób na ograniczenie narażenia na atak na kilka dni, nic więcej.
- czapka z daszkiem post_max_size przy 8M (32M, jeśli konieczne jest przesyłanie), zachowaj upload_max_filesize poniżej i dodaj ograniczenia rozmiaru na serwerze WWW lub serwerze proxy.
- Wyłącz postęp przesyłania za pomocą session.upload_progress.enabled=0. Musi się to znaleźć w pliku php.ini, puli FPM lub konfiguracji serwera; ini_set oraz .user.ini Nie zrobię tego. Uruchom ponownie pracowników.
- Tylko PHP 8.5: fatal_error_backtraces=0, a następnie uruchom ponownie pracowników.
- Tylko dla administratorów: limit_pamięci=-1 przez wartość_administracyjna_phpi tylko z faktycznie wymuszonym limitem pamięci kontenera lub grupy cgroup. Pomiń RLIMIT_AS i RLIMIT_DATA. Nieprawidłowa konfiguracja może spowodować awarię serwera.
- Ukrywanie błędów (zgłaszanie błędów, display_errors, @) nie daje żadnej ochrony.
A co z zaporą sieciową z przodu? Cloudflare, na przykład, wprowadził reguły php2shell, co stanowi cenną dodatkową barierę. Jednak widzi tylko ruch, który przez niego przechodzi. Dlatego serwer źródłowy musi blokować cały ruch z wyjątkiem ruchu pochodzącego z zapory sieciowej WAF. To jak zapięcie pasów bezpieczeństwa, a nie zakup nowego samochodu.
Jedynym kompletnym rozwiązaniem jest uaktualnienie PHP.
Naprawa prawidłowa
Jak to zrobić poprawnie? Po wyjściu z kryzysu upewnij się, że używasz obsługiwanej wersji PHP dla swojego sklepu i połącz ją z wersją PrestaShop, która jest z nią kompatybilna. Pamiętaj o kalendarzu, ponieważ PHP 8.2 zakończy swoją ważność w grudniu 2026 roku. Przed aktualizacją PHP lub planowaniem aktualizacji PrestaShop sprawdź status bezpieczeństwa swojej wersji PHP i potwierdź jej zgodność z wersją PrestaShop, motywem i zainstalowanymi modułami.
| Wersja PHP | Stan bezpieczeństwa | Rozważania dotyczące zgodności z PrestaShop |
|---|---|---|
| PHP 8.5 | Sprawdź status wydania zabezpieczeń i poprawki. | Przed aktualizacją sprawdź kompatybilność z PrestaShop 9 oraz wszystkimi zainstalowanymi motywami i modułami. |
| PHP 8.4 | Sprawdź status wydania zabezpieczeń i poprawki. | Sprawdź kompatybilność z Twoją wersją PrestaShop i rozszerzeniami. |
| PHP 8.3 | Sprawdź status wydania zabezpieczeń i poprawki. | Przed zmianą wersji PHP sprawdź wymagania dotyczące wydania PrestaShop i kompatybilność modułów. |
| PHP 8.2 | Sprawdź odpowiednie poprawki zabezpieczeń i cykl wsparcia technicznego oddziału. | Sprawdź kompatybilność ze swoim obecnym sklepem i planowaną ścieżką aktualizacji. |
| PHP 8.1 | Sprawdź wsparcie dostawcy i dostępność kopii bezpieczeństwa. | Przed aktualizacją sprawdź wymagania PHP dla konkretnej wersji PrestaShop. |
| PHP 8.0, 7.4 i starsze | Te gałęzie są już wycofane z eksploatacji; sprawdź, czy Twój dostawca zapewnia kopie zapasowe zabezpieczeń. | Zaplanuj migrację do obsługiwanej wersji PHP i kompatybilnej wersji PrestaShop po przetestowaniu motywów, modułów i integracji płatności. |
Ważne: Nowsza wersja PHP nie jest automatycznie bezpieczna, a starsza wersja niekoniecznie jest pozbawiona poprawek, jeśli dostawca udostępnia backporty bezpieczeństwa. Przed wprowadzeniem zmian sprawdź aktualny status poprawek i kompatybilność swojego sklepu.
Duża aktualizacja PrestaShop to osobny i dłuższy projekt. Nie jest to szybka odpowiedź na te luki w zabezpieczeniach (CVE). Jeśli PrestaShop musi poczekać, załataj PHP już teraz i zaplanuj aktualizację osobno.
Potrzebujesz pomocy w zabezpieczeniu lub aktualizacji swojego sklepu eCommerce?
Bezpieczeństwo Twojego sklepu eCommerce wymaga regularnych aktualizacji zabezpieczeń i dobrze utrzymanej platformy. Jeśli potrzebujesz pomocy we wdrożeniu odpowiednich poprawek bezpieczeństwa PHP lub planowaniu aktualizacji PrestaShop 9 , zespół KnowBand służy pomocą.
Nasz zespół pomoże Ci ocenić wymagania Twojego sklepu, sprawdzić kompatybilność i zaplanować kolejne kroki, aby zapewnić bezpieczeństwo i płynne działanie sklepu. Oprócz wsparcia w zakresie bezpieczeństwa i aktualizacji, możesz zapoznać się z naszą ofertą. Oferta modułów eCommerce firmy KnowBand aby zwiększyć funkcjonalność Twojego sklepu, poprawić komfort zakupów i wesprzeć rozwój Twojego biznesu.
Potrzebujesz pomocy eksperta? Skontaktuj się z KnowBand aby omówić poprawki zabezpieczeń PHP, aktualizacje PrestaShop lub odpowiednie moduły dla Twojego sklepu.
Szybkie pytania i odpowiedzi
Pytanie 1: Czy muszę aktualizować swoje moduły?
Odpowiedź: Nie, nie z powodu tych luk CVE. Moduł nie może łatać PHP. Sprawdź kompatybilność modułu przed przejściem na nowszą wersję PHP lub PrestaShop.
Pytanie 2: Mój współdzielony host twierdzi, że ma to zapewnione. Czy to wystarczy?
Odpowiedź: Uzyskaj pisemną informację: oba CVE naprawione, PHP uruchomione ponownie. Przyjazne „pracujemy nad tym” nie jest potwierdzeniem.
Pytanie 3: Czy WAF może wykonać to zadanie?
Odpowiedź: Dodaje ochronę, ale tylko dla ruchu proxy, a zmodyfikowane ładunki mogą się przedostać. Mimo wszystko załataj.
Pytanie 4: Czy muszę dokonać aktualizacji PrestaShop natychmiast?
Odpowiedź: Nie. To dłuższa droga. Dzisiaj liczy się PHP.
Pytanie 5: Nadal korzystam z PHP 7.4.
Odpowiedź: Oficjalne aktualizacje się zakończyły, choć istnieje minimalny backport, a wiele dystrybucji i dostawców LTS dostarcza poprawione pakiety. Zapytaj swojego usługodawcę hostingowego, czy jesteś objęty wsparciem, a następnie zaplanuj migrację do wspieranego PHP.
Źródła
- Oficjalne ogłoszenie PHP: https://www.php.net/archive/2026.php
- Porada PrestaShop: https://build.prestashop-project.org/news/2026/php-security-updates-october-2026/
- Wspólne oświadczenie UE (Komisja Europejska DG CNECT, ENISA, CERT-UE, Europol EC3, sieć CSIRT): https://www.enisa.europa.eu/news/joint-statement-on-critical-php-vulnerabilities
Uruchamiasz oprogramowanie firm trzecich, które zawiera własny kod PHP? Oświadczenie UE wskazuje na repozytorium php2shell NCSC-NL w serwisie GitHub.