PHP2Shell: luka w PHP, która zagraża Twojemu sklepowi PrestaShop

20 października pojawiło się ostrzeżenie, które postawiło w stan gotowości pół internetu: dwie poważne luki w PHP, języku, na którym działa Twój sklep PrestaShop, pozwalające obcej osobie przejąć kontrolę nad serwerem bez loginu i hasła. Nazwano je PHP2Shell. PHP opublikowało poprawkę bezpieczeństwa 21 października, a to, co musisz zrobić, zależy od jednej rzeczy: wersji PHP, na której działa Twój sklep.

Wyjaśniamy bez technicznego żargonu: co się stało, jak sprawdzić, czy cię to dotyczy, co zrobić dziś i jak się dowiedzieć, czy Twój hosting już zainstalował poprawkę.

Czym jest PHP2Shell i dlaczego to takie groźne?

PHP to silnik, który pracuje pod PrestaShop, WordPressem, Magento i większością sklepów i stron na świecie. Obie luki, zarejestrowane jako CVE-2026-109618 i CVE-2026-109619, mają ocenę wagi 9,2 na 10. W praktyce ten, kto umie je wykorzystać, może uruchomić na Twoim serwerze, co tylko zechce: zostawić tylne drzwi, ukraść dane Twoich klientów albo wstawić do sklepu fałszywą captchę, jak w przypadku ClickFix.

Od innych ostrzeżeń różni się tym, że atak nie przechodzi przez PrestaShop ani przez żaden moduł. Dzieje się w PHP, zanim Twój sklep w ogóle odczyta wizytę. Nieważne, jak dobrze jest zadbany: jeśli PHP na serwerze ma lukę, sklep też.

Do tego informacje wyciekły przed czasem. Firma zajmująca się bezpieczeństwem Sansec podaje, że razem z ostrzeżeniem pojawił się zrzut ekranu gotowego narzędzia do ataku, i spodziewał się masowych ataków, gdy tylko poprawka zostanie opublikowana. Według tego samego źródła Cloudflare widział już wtedy pierwsze próby i wprowadził reguły, które mają je blokować.

Czy to dotyczy mojego sklepu PrestaShop?

Najpewniej tak. W swoim komunikacie bezpieczeństwa PHP uznaje za zagrożoną każdą instalację, która serwuje strony internetowe, niezależnie od tego, jak serwer ją uruchamia, a najwyższe ryzyko wskazuje na serwerach Apache z mod_php, gdzie jest już zademonstrowany atak działający bez loginu i hasła. Sansec mówi o każdym serwerze z PHP 5.4 lub nowszym, czyli w praktyce o każdym działającym dziś sklepie PrestaShop.

Pytanie, które naprawdę ma znaczenie, jest inne: czy dostaniesz poprawkę? PHP naprawił błąd w wersjach 8.2.35, 8.3.36, 8.4.27 i 8.5.12. Dla starych wersji, które nie mają już oficjalnego wsparcia, PHP opublikował łatkę bez nowego wydania, a w ciągu jednego–dwóch dni panele i systemy używane przez hostingi zamieniły ją w zwykłą aktualizację: cPanel i CloudLinux od PHP 5.2 do 8.1; DirectAdmin, Ubuntu, Red Hat, AlmaLinux i repozytorium Remi w wersjach od 7.4 do 8.1, które nadal utrzymują. A każda wersja PrestaShop działa tylko z określonymi wersjami PHP:

• PrestaShop 1.6: działa z PHP 5.6–7.1. Łatka jest, jeśli Twój hosting używa cPanel lub CloudLinux; gdzie indziej tylko w ramach płatnego wsparcia rozszerzonego, np. TuxCare lub Zend.
• PrestaShop 1.7: najwyżej PHP 7.4. Załatane 7.4 jest już w niemal wszystkich panelach: wystarczy, że hosting je zainstaluje.
• PrestaShop 8: najwyżej PHP 8.1. Tak samo jak w 1.7: załatane 8.1 już istnieje i zależy od Twojego hostingu.
• PrestaShop 9: działa z PHP 8.1–8.4. Na PHP 8.2 lub nowszym dostaje oficjalną aktualizację; na 8.1 wystarczy podnieść wersję PHP.

Innymi słowy: prawie każdy sklep może dziś działać na PHP bez tej luki. Ale jeśli to nie PrestaShop 9, zależy to od tego, czy hosting zainstalował łatkę, a ponieważ numer wersji się nie zmienia, nie widać tego na pierwszy rzut oka: trzeba go zapytać. To też łatka awaryjna: PHP 8.1 i starsze nie mają oficjalnego wsparcia, więc przy następnej luce znów będziesz zależeć od kogoś, kto naprawi ją na własną rękę.

Jak sprawdzić, jaką masz wersję

Wejdź do panelu sklepu i otwórz Zaawansowane → Informacja. Zobaczysz tam wersję PrestaShop, a nieco niżej wersję PHP. Z tymi dwiema liczbami wiesz już, w jakiej jesteś sytuacji.

Co zrobić dziś i w jakiej kolejności

1. Sprawdź obie wersje, PrestaShop i PHP, tak jak opisaliśmy wyżej.
2. Zrób pełną kopię zapasową, plików i bazy danych, i trzymaj ją poza serwerem. Jeśli coś się stanie, tylko ona pozwoli Ci wrócić.
3. Jeśli Twój sklep to PrestaShop 9, poproś hosting o aktualizację PHP do 8.2.35, 8.3.36, 8.4.27, 8.5.12 lub nowszej, albo zrób to sam w panelu hostingu, jeśli pozwala wybrać wersję. Jeśli jesteś na PHP 8.1, przejdź przy okazji na 8.3 lub 8.4.
4. Jeśli korzystasz z Cloudflare, sprawdź, czy chmurka przy Twojej domenie jest pomarańczowa: wtedy ruch przechodzi przez jego reguły, zanim dotrze do Twojego serwera. Niewiele to daje, jeśli adres Twojego serwera jest znany i przyjmuje ruch od każdego, więc poproś swojego technika, żeby otworzył go tylko dla Cloudflare.
5. Jeśli Twój sklep to 1.6, 1.7 lub 8, zapytaj hosting, czy zainstalował już łatkę na PHP2Shell dla Twojej wersji PHP. Jeśli nie, poproś swojego technika o środki awaryjne, które opisujemy niżej. I ustal termin aktualizacji do PrestaShop 9: tak wracasz do PHP z oficjalnym wsparciem.

Tym razem włączenie przerwy technicznej w panelu Cię nie ochroni: PHP odczytuje wizytę, zanim PrestaShop zdecyduje się pokazać stronę przerwy technicznej.

A jeśli mój hosting nie ma łatki?

PHP proponuje kilka ustawień serwera, które zamykają część dróg ataku, i zaznacza, że nie czynią one sklepu bezpiecznym: robi to tylko aktualizacja. Sansec dodaje jeszcze jedno rozwiązanie awaryjne: zablokować na serwerze rodzaj przesyłania, którym wędrują pliki wgrywane na stronę. Ma ono swoją cenę: dopóki jest włączone, nikt nie może wgrywać plików do Twojego sklepu. Ani Ty zdjęć nowego produktu, ani Twoi klienci załącznika w formularzu kontaktowym. Sklep dalej normalnie sprzedaje.

To daje kilka dni, nie więcej: albo hosting zainstaluje łatkę, albo przenosisz się do takiego, który ją ma. A przy następnej luce w PHP —a będą— Twój sklep znów będzie od tego zależał, bo PHP 8.1 i starsze nie mają już oficjalnego wsparcia.

Jakie PHP obsługuje każda wersja PrestaShop i do kiedy dostaje poprawki, zebraliśmy w jednej tabeli w artykule jaka wersja PHP dla PrestaShop.

Czy warto teraz zaktualizować PrestaShop?

To pytanie, które zawsze się odkłada, bo sklep działa. PHP2Shell pokazuje, co się dzieje, gdy odkłada się je za długo: dnia, w którym przychodzi problem, nie wybierasz ty, a to, czy poprawka do ciebie dotrze, zależy od innych.

Przejście na PrestaShop 9 daje Ci PHP, które dostaje poprawki przez lata. Robi się to bez zamykania sklepu, zachowujesz produkty, klientów, zamówienia i pozycje w Google, a mały sklep kosztuje od 690 €. Wszystko opisujemy w tekście aktualizacja PrestaShop 1.7 lub 1.6 do 9 i na naszej stronie o migracji z PrestaShop 1.6 i 1.7 na 9.

A jeśli wolisz nie śledzić takich ostrzeżeń, do tego służy opieka techniczna nad PrestaShop: nadzorujemy Twój sklep, aktualizujemy jego moduły, a jeśli działa na serwerze BK Modules, także PHP, żeby takie ostrzeżenie Cię nie zaskoczyło.

Potrzebujesz pomocy dziś?

Jeśli nie wiesz, w jakiej jesteś sytuacji, jeśli hosting Ci nie odpowiada albo jeśli Twój sklep to 1.6, 1.7 lub 8 i chcesz z tego wyjść, podaj nam swoją wersję PrestaShop i PHP. Powiemy Ci, co zrobić dziś, a jeśli trzeba, podamy zamkniętą cenę przejścia na PrestaShop 9.

Chcę zaktualizować swój sklep

Dla Twojego zespołu technicznego

Wersje z poprawką: 8.2.35, 8.3.36, 8.4.27 i 8.5.12. Dla 7.4, 8.0 i 8.1 PHP publikuje minimalną poprawkę w kodzie źródłowym, podlinkowaną w komunikacie, bez nowego wydania. Załatane pakiety zachowują numer wersji, więc php -v ich nie odróżnia: trzeba sprawdzić rewizję pakietu (rpm -q, dpkg -l). Rewizje z poprawką: cPanel EasyApache 4 ea-php74 7.4.33-19, ea-php80 8.0.30-12, ea-php81 8.1.34-5; CloudLinux ea-php / alt-php 5.2–8.5 (21–22/10); Remi 7.4.33-31, 8.0.30-21, 8.1.34-6; Ubuntu 22.04 8.1.2-1ubuntu2.28. Częściowe środki podane przez PHP ustawia się w php.ini, w puli PHP-FPM (php_admin_value) lub w konfiguracji serwera, nigdy przez ini_set() ani .user.ini, z restartem wszystkich procesów:

; CVE-2026-109618
memory_limit = -1
post_max_size = 32M   ; 8M, jeśli nie wgrywa się plików
; CVE-2026-109619
session.upload_progress.enabled = 0
; tylko w PHP 8.5
fatal_error_backtraces = 0

PHP prosi, żeby nie zastępować memory_limit limitami systemowymi (RLIMIT_AS, RLIMIT_DATA). Rozwiązanie Sansec, czyli blokada multipart/form-data (psuje każde wgrywanie plików, także w panelu), w Apache:

RewriteEngine On
RewriteCond %{HTTP:Content-Type} multipart/form-data [NC]
RewriteRule ^ - [F]

W Nginx:

if ($http_content_type ~* "multipart/form-data") {
    return 403;
}

Z Cloudflare ograniczyć port 443 serwera źródłowego do jego zakresów IP; inaczej atak trafia prosto na IP serwera.