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 to bez żargonu: co się stało, jak sprawdzić, czy Cię to dotyczy, co zrobić dziś i co zrobić, jeśli Twój sklep działa na wersji, która poprawki nie dostaje.

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.

Naprawdę ważne jest inne pytanie: czy poprawka do Ciebie dociera? PHP załatało luki w wersjach 8.2.35, 8.3.36, 8.4.27 i 8.5.12. PHP 8.1 i starsze nie dostają już oficjalnych aktualizacji: dla 7.4, 8.0 i 8.1 PHP udostępniło minimalną poprawkę, którą trzeba ręcznie skompilować, a niektórzy dostawcy rozszerzonego wsparcia dodają ją do swoich pakietów. A każda wersja PrestaShop działa tylko z określonymi wersjami PHP:

• PrestaShop 1.6: działa z PHP 5.6 do 7.1. Bez poprawki.
• PrestaShop 1.7: najwyżej PHP 7.4. Bez oficjalnej aktualizacji; tylko na 7.4 da się zastosować minimalną poprawkę skompilowaną ręcznie.
• PrestaShop 8: najwyżej PHP 8.1. Bez oficjalnej aktualizacji; minimalną poprawkę dla 8.1 też trzeba skompilować ręcznie.
• PrestaShop 9: działa z PHP 8.1 do 8.4. Z PHP 8.2 lub nowszym dostaje aktualizację; jeśli jest na 8.1, wystarczy podnieść wersję PHP.

Innymi słowy: jeśli Twój sklep to nie PrestaShop 9, nie ma oficjalnej aktualizacji do zainstalowania, bo Twoja wersja PrestaShop nie może działać z PHP, które ją ma. Zostaje minimalna poprawka, która wymaga pracy technika i nie ochroni Cię przed następną luką.

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 albo 8, zapytaj hosting, czy wdraża poprawkę dla Twojej wersji PHP, poproś swojego technika o rozwiązania awaryjne, które opisujemy niżej, i wyznacz datę aktualizacji do PrestaShop 9. To jedyny sposób, żeby znów mieć PHP z poprawkami.

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 sklep nie może dostać poprawki?

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 sposób na zyskanie kilku dni, a nie na zostanie tak na stałe. Następnym razem, gdy w PHP wyjdzie luka — a wyjdzie — Twój sklep znów będzie w tej samej sytuacji, bo PHP 8.1 i starsze nie dostają już aktualizacji.

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 poprawka jest poza Twoim zasięgiem.

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 nie chcesz pilnować takich ostrzeżeń, właśnie to obejmuje opieka techniczna: ktoś aktualizuje za Ciebie PHP, PrestaShop i moduły i ostrzega Cię, zanim problem dotrze do Twojego sklepu.

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 gałęzie z minimalną poprawką w kodzie źródłowym, podlinkowane w komunikacie; nie są to oficjalne wydania. Częściowe zabezpieczenia podane przez PHP, w php.ini, w puli PHP-FPM (php_admin_value) albo 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;
}

Przy pakietach z repozytorium Remiego (typowych w RHEL, AlmaLinux czy Rocky) Sansec ostrzegał, że aktualizacja nie dociera tego samego dnia: sprawdź zainstalowaną wersję poleceniem php -v. Z Cloudflare ogranicz port 443 serwera źródłowego do jego zakresów IP; w przeciwnym razie atak trafia bezpośrednio na IP serwera.

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