PHP2Shell: co zrobić z CVE-2026-109618 i CVE-2026-109619 w sklepie PrestaShop, nawet gdy aktualizacja jest niemożliwa

21 października 2026 roku zespół PHP wydał awaryjną aktualizację usuwającą dwie krytyczne luki w samym PHP, znane już pod wspólną nazwą PHP2Shell: CVE-2026-109618 i CVE-2026-109619. Obie mogą pozwolić atakującemu na wykonanie kodu na serwerze WWW bez logowania, a w niektórych konfiguracjach nawet przed uruchomieniem pierwszej linijki kodu Twojego sklepu.

W przypadku większości stron rada jest krótka: zaktualizuj PHP i uruchom je ponownie. W sklepach PrestaShop sprawa jest bardziej skomplikowana i właśnie dlatego powstał ten artykuł. Każde wydanie PrestaShop starsze niż 9.0 oficjalnie obsługuje najwyżej PHP 8.1, a PHP 8.1 i wszystkie starsze wersje nie otrzymały oficjalnego wydania z poprawką. Duża część sklepów PrestaShop na świecie nie może więc w tym tygodniu po prostu „zaktualizować PHP”.

W tym poradniku wyjaśniamy, na czym polegają luki, jak sprawdzić, czy Twój sklep rzeczywiście jest narażony (sam numer wersji tego nie powie), i co zrobić w poszczególnych wersjach PrestaShop. Pokazujemy też rozwiązanie przejściowe, które stosujemy w sklepach, których nie da się teraz zaktualizować: przeniesienie ich na PHP 7.4 z poprawkami od dostawcy, najpierw na kopii staging, oraz naprawienie fragmentów kodu, które przestają działać. To etap przejściowy, a nie docelowe rozwiązanie. Ale znacznie lepszy niż pozostawienie sklepu bez ochrony albo jego wyłączenie.

Czym jest PHP2Shell, prostymi słowami

Obie luki znajdują się w silniku PHP, czyli części, która odbiera żądanie WWW i przygotowuje je, zanim ruszy kod Twojego sklepu. Dlatego nie naprawi ich żadna aktualizacja PrestaShop, moduł ani szablon. Może to zrobić tylko PHP z poprawkami.

Badacze pokazali też, że atakujący może bez logowania odczytywać pamięć procesów roboczych PHP. Mogą się w niej znajdować hasła, tokeny sesji i klucze API pochodzące z żądań innych odwiedzających. Właśnie dlatego sekcja o porządkach na końcu poradnika ma znaczenie nawet wtedy, gdy nikt niczego nie umieścił na Twoim serwerze.

Problem obejmuje każdą instalację PHP obsługującą żądania WWW: PHP-FPM, Apache z mod_php, php-cgi, FrankenPHP i LiteSpeed. Zespół PHP ocenia ryzyko najwyżej w przypadku mod_php, dla którego pokazał exploit uruchamiający się przed jakimkolwiek kodem aplikacji. Dla właściciela sklepu PrestaShop ma to konkretne znaczenie: logowanie do panelu administracyjnego, tryb konserwacji sklepu i każdy moduł bezpieczeństwa działają dopiero po przetworzeniu żądania przez PHP, więc żaden z tych mechanizmów nie zatrzyma ataku.

Ochrona musi działać przed PHP. Wszystko wewnątrz PrestaShop uruchamia się już po wyrządzeniu szkody.

Przebieg wydarzeń

Dlaczego sklepy PrestaShop mają trudniej

Ta tabela nie jest przyjemną lekturą. Pokazuje najwyższą wersję PHP oficjalnie obsługiwaną przez każdą linię PrestaShop, zgodnie z wymaganiami systemowymi PrestaShop, oraz informację, czy w tym zakresie istnieje oficjalne wydanie PHP z poprawkami.

„Nie” w trzeciej kolumnie nie oznacza, że poprawka nie istnieje. Oznacza, że musi pochodzić z innego źródła niż php.net: z dystrybucji Linuksa, od dostawcy panelu hostingowego, od dostawcy długoterminowego wsparcia albo z PHP skompilowanego samodzielnie z minimalnym backportem zespołu PHP. Właśnie tam większość sklepów PrestaShop musi w tym tygodniu szukać rozwiązania. I właśnie tam kryją się też dobre wiadomości.

Każdy wiersz bez zielonej komórki zależy od backportu dostawcy albo przejściowego PHP 7.4.

Krok 1: sprawdź, na czym naprawdę działa Twój sklep

Na tym etapie niemal każdy wpada w dwie pułapki.

Pierwsza pułapka: PHP widoczne w SSH nie musi być tym samym PHP, które obsługuje Twój sklep. Serwery często mają kilka wersji PHP zainstalowanych obok siebie, a wiersz poleceń może korzystać z innej niż serwer WWW. W PrestaShop otwórz Parametry zaawansowane, Informacje (Advanced Parameters > Information): widoczna tam wersja PHP faktycznie obsługuje żądania Twojego sklepu. Ustawienie PHP dla domeny w panelu hostingowym powinno wskazywać to samo.

Druga pułapka: numer wersji nie mówi, czy masz poprawki. Dystrybucje i dostawcy hostingu przenoszą poprawki bezpieczeństwa do wersji, której już używasz, zachowując jej dotychczasowy numer. „PHP 7.4.33” może mieć komplet poprawek na jednym serwerze i być całkowicie podatne na drugim. Potwierdzeniem jest komunikat dostawcy dotyczący dokładnie Twojego pakietu albo pisemna odpowiedź hostingu.

# Opcjonalnie: niektóre serwery podają wersję PHP. To nie potwierdza obecności poprawek.
curl -sS -I https://www.example-shop.com/ | grep -i '^X-Powered-By:'

# Dodatkowe potwierdzenie w historii zmian pakietów. Wpisy dla obu CVE to dobry znak.
# Brak wpisu niczego nie dowodzi: niektórzy dostawcy zapisują tylko zmianę wersji. Zapytaj dostawcę.
# Dostosuj nazwę pakietu do wersji PHP i sposobu obsługi żądań Twojego sklepu.

# Debian i Ubuntu
zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php7.4-fpm/changelog.Debian.gz

# Systemowe PHP w RHEL, AlmaLinux, Rocky i CloudLinux
rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]'

# cPanel EasyApache (ea-php) i CloudLinux PHP Selector (alt-php)
rpm -q --changelog ea-php74-php-fpm | grep -E 'CVE-2026-10961[89]'
rpm -q --changelog alt-php74-common | grep -E 'CVE-2026-10961[89]'

Twój hosting może już mieć stare PHP z poprawkami, nawet PHP 5

Większość właścicieli starszych sklepów o tym nie wie. Część dostawców hostingu udostępnia własne kompilacje starych wersji PHP i je również załatała:

• CloudLinux PHP Selector (alt-php): kompilacje z poprawkami dla PHP od 5.2 do 5.6, od 7.0 do 7.4 i od 8.0 do 8.5 trafiły do stabilnych repozytoriów 22 października na CloudLinux 7, 8 i 9 (CloudLinux 10 otrzymuje je przez repozytorium TuxCare).
• Kompilacje cPanel PHP od CloudLinux (ea-php): poprawki od ea-php52 do ea-php85, z zachowaniem starych numerów wersji.
• Własne PHP EasyApache od cPanel: oficjalne wydania dla 8.2 do 8.5 oraz backporty dla 8.1 (8.1.34-5), 8.0 (8.0.30-12) i 7.4 (7.4.33-19). Własne kompilacje cPanel dla 7.3 i starszych nie otrzymały poprawki; cPanel odsyła ich użytkowników do TuxCare.
• Red Hat i dystrybucje oparte na jego pakietach: poprawki są publikowane osobno dla poszczególnych strumieni. Sprawdź erratę dla dokładnie tego strumienia PHP, który jest włączony na Twoim serwerze. Nie zakładaj, że zwykła aktualizacja systemu załatwiła sprawę: pierwsze doniesienia wymieniały część strumieni jako poprawione, a inne nadal czekały.
• TuxCare Endless Lifecycle Support: płatne długoterminowe wsparcie z poprawkami dla wersji PHP, których standardowe wsparcie już się zakończyło.

Ta sama etykieta „PHP 7.1” w panelu hostingowym może więc oznaczać PHP z poprawkami na jednym hostingu i podatne na atak na innym. Zanim zaplanujesz jakiekolwiek zmiany w kodzie, zadaj hostingowi jedno konkretne pytanie. Oto wiadomość, którą możesz wysłać bez zmian:

Temat: PHP2Shell (CVE-2026-109618, CVE-2026-109619) na moim koncie

Cześć,
mój sklep działa na Waszych serwerach na PHP X.Y (handler: PHP-FPM / mod_php / LiteSpeed).
Czy kompilacja PHP obsługująca moją stronę zawiera poprawki dla CVE-2026-109618 i
CVE-2026-109619? Proszę o podanie dokładnej wersji pakietu i informację, czy procesy PHP
zostały ponownie uruchomione po jego instalacji. Jeśli moja wersja nie ma poprawek,
na jakie wersje PHP z poprawkami mogę przejść w ramach mojego planu hostingowego?
Dziękuję.

Jeśli odpowiedź brzmi „tak, obie luki załatane, procesy uruchomione ponownie”, pilna część jest załatwiona bez zmiany choćby linijki kodu. Przeczytaj sekcję o sprawdzaniu śladów ewentualnego włamania, a potem spokojnie zaplanuj aktualizację.

Krok 2: wybierz ścieżkę dla swojej wersji PrestaShop

Niezależnie od wersji pierwszy wybór jest taki sam: pakiet z poprawkami dla gałęzi PHP, na której Twój sklep już działa. Zmiana gałęzi PHP to większy krok i zawsze wymaga najpierw kopii staging, na której sprawdzisz moduły, nadpisania i składanie zamówień.

Zapytaj hosting, zanim zaplanujesz zmiany w kodzie: najtańsza droga to wydanie z poprawkami, które już masz do dyspozycji.

PrestaShop 9

Zaktualizuj PHP do wydania z poprawkami w swojej gałęzi: 8.2.35, 8.3.36 lub 8.4.27, a na 9.1 również 8.5.12. Uruchom PHP ponownie i potwierdź wersję na stronie Informacje. Jeśli Twój sklep na 9.0 nadal działa na PHP 8.1, przejście na 8.2 lub nowsze oznacza zmianę gałęzi: najpierw przetestuj ją na staging albo na razie skorzystaj z 8.1 z poprawkami od dostawcy.

PrestaShop 8.0 do 8.2

Te wersje oficjalnie obsługują PHP od 7.2 do 8.1, a żadna z tych gałęzi nie ma wydania z poprawkami z php.net. Dostawcy dają jednak więcej możliwości, niż mogłoby się wydawać: 8.1 z poprawkami (8.1.34-5 od cPanel, alt-php81 od CloudLinux, pakiet php8.1 z Ubuntu 22.04, TuxCare), ale też 8.0 lub 7.4 z poprawkami od tych samych dostawców. Wszystkie mieszczą się w oficjalnym zakresie PrestaShop 8. Jeśli nie masz dostępu do żadnej kompilacji z poprawkami, trwałym rozwiązaniem jest aktualizacja do PrestaShop 9. Dopóki nie uruchomisz sklepu na PHP z poprawkami, zastosuj opisane niżej środki tymczasowe.

PrestaShop 1.7.8

PHP 7.4 to najwyższa oficjalnie obsługiwana wersja, a kompilacje 7.4 z poprawkami są stosunkowo łatwo dostępne: cPanel 7.4.33-19, CloudLinux alt-php74, TuxCare oraz pakiety dystrybucji, jeśli Twój dostawca je opublikował. Jeśli sklep działa na starszym PHP, przejście na 7.4 z poprawkami mieści się w oficjalnym zakresie 1.7.8. Mimo to przetestuj je na staging.

PrestaShop 1.6.1.x i 1.7.0 do 1.7.7

Te wersje oficjalnie kończą obsługę na PHP 7.1, 7.2 lub 7.3. Najpierw zapytaj hosting, czy dla Twojej obecnej wersji istnieje kompilacja z poprawkami (patrz wyżej). Jeśli tak, przejdź na nią i pilna część jest załatwiona. Jeśli nie, przyda się nasze rozwiązanie przejściowe.

Nasze rozwiązanie przejściowe: PHP 7.4 z poprawkami

Tak właśnie postępujemy w sklepach pod naszą opieką, których nie da się zaktualizować w tym miesiącu. Pomysł jest prosty: uruchomić sklep na PHP 7.4, do którego dostawca nadal dostarcza poprawki, choć dana wersja PrestaShop oficjalnie obsługuje tylko starsze PHP, i naprawić fragmenty kodu, które sobie z tym nie radzą. Z naszego doświadczenia wynika, że rdzeń PrestaShop 1.6.1 i 1.7 na 7.4 generuje głównie komunikaty notice i ostrzeżenia o przestarzałych funkcjach, a nie błędy krytyczne. Zwykle faktycznie przestaje działać kilka starych modułów i nadpisań. To rozwiązanie przejściowe i mówimy o tym wprost: przez pewien czas działasz poza oficjalną macierzą zgodności PrestaShop. Ale luka zostaje zamknięta, a sklep może dalej sprzedawać, gdy Ty planujesz docelową aktualizację.

Rozwiązanie przejściowe: zamyka lukę i pozwala sklepowi sprzedawać do czasu właściwej aktualizacji.

Konkretny przykład, dlaczego 7.4 zadziała tam, gdzie PHP 8 już nie: plik Cookie.php w samym PrestaShop 1.6.1.23 zawiera $this->_path{0}. W PHP 7.4 ta składnia z nawiasami klamrowymi jest jedynie przestarzała; w PHP 8.0 powoduje błąd krytyczny. Ta jedna linijka decyduje, czy rozwiązanie przejściowe działa, czy sklep w ogóle się nie ładuje.

1. Przygotuj kopię staging i odizoluj ją od działającego sklepu

Skopiuj pliki i bazę danych w osobne miejsce, na przykład na subdomenę zabezpieczoną hasłem. Następnie, zanim kopia odpowie choćby na jedno żądanie:

• Podłącz ją do osobnej bazy danych. Skopiowana konfiguracja nadal zawiera dane dostępowe do bazy działającego sklepu (config/settings.inc.php w 1.6, app/config/parameters.php w 1.7). Zmień je na dane bazy staging, najlepiej z użytkownikiem bazy, który nie ma dostępu do produkcji. Wszystkie kolejne kroki zakładają, że robisz to najpierw.
• Zablokuj połączenia wychodzące. Zanim kopia odpowie na pierwsze żądanie lub uruchomi jakiekolwiek zadanie, zablokuj na poziomie serwera, niezależnie od PrestaShop, wysyłkę poczty i połączenia z usługami produkcyjnymi (API płatności, przewoźników i platform marketplace). Zezwól tylko na połączenia z usługami sandbox, które chcesz testować. Same ustawienia PrestaShop nie wystarczą: niektóre moduły wysyłają pocztę lub komunikują się z platformami marketplace przez własne połączenia. Następnie wyłącz skopiowane zadania cron i przełącz każdy moduł płatności w tryb testowy lub sandbox.
• Zablokuj dostęp odwiedzającym i wyszukiwarkom za pomocą ochrony hasłem na serwerze WWW.

Następnie, wyłącznie w bazie staging:

-- TYLKO BAZA STAGING. Zastąp ps_ swoim prefiksem tabel.
-- 1. Sam PrestaShop nigdy nie wysyła poczty z tej kopii
UPDATE ps_configuration SET value = '3' WHERE name = 'PS_MAIL_METHOD';

-- 2. Ustaw adres kopii (jeden sklep, zainstalowany w katalogu głównym domeny)
SELECT id_shop_url, id_shop, domain, domain_ssl, physical_uri FROM ps_shop_url;
UPDATE ps_shop_url
SET domain = 'staging.example-shop.com', domain_ssl = 'staging.example-shop.com', physical_uri = '/'
WHERE id_shop_url = 1;
UPDATE ps_configuration SET value = 'staging.example-shop.com'
WHERE name IN ('PS_SHOP_DOMAIN', 'PS_SHOP_DOMAIN_SSL');

W instalacji multistore przypisz osobno każdy adres sklepu zamiast korzystać z przykładu dla jednego sklepu.

2. Przełącz kopię na 7.4 z poprawkami i zbierz wszystkie błędy

W panelu hostingowym wybierz PHP 7.4 z poprawkami dla strony staging. Ustaw error_reporting na E_ALL, zapisuj błędy do pliku i wyłącz ich wyświetlanie na ekranie. Sprawdź, czy wpisy rzeczywiście trafiają do logu, a następnie uporządkuj problemy od najczęstszych:

# Uszereguj błędy PHP na staging od najczęstszych (standardowy format logu PHP)
grep -E 'PHP (Fatal error|Parse error|Recoverable fatal error|Warning|Notice|Deprecated):' /path/to/php-error.log \
  | sed -E 's/^\[[^]]*\] //' | sort | uniq -c | sort -rn | head -40

3. Przeskanuj kod, który najczęściej sprawia problemy

Zanim zaczniesz przeklikiwać sklep, szybki skan statyczny modułów, nadpisań i szablonu wskaże typowych podejrzanych. To tylko częściowa lista kontrolna: pomija wywołania pośrednie, wywołania rozbite na kilka wierszy i część odwołań do elementów z użyciem nawiasów klamrowych, więc pusty wynik nie dowodzi zgodności. Przejrzyj każde trafienie.

# Funkcje usunięte lub oznaczone jako przestarzałe w PHP 7.x
grep -rnE --include='*.php' \
  '\beach\s*\(|create_function\s*\(|get_magic_quotes_(gpc|runtime)\s*\(|\bmysql_[a-z_]+\s*\(|\beregi?(_replace)?\s*\(|\bsplit\s*\(|mcrypt_[a-z_]+\s*\(' \
  modules override themes

# Wywołania preg_replace: sprawdź każde pod kątem usuniętego modyfikatora /e
grep -rnE --include='*.php' '\bpreg_replace\s*\(' modules override themes

# Indeksowanie ciągów nawiasami klamrowymi ($str{0}), przestarzałe w PHP 7.4
grep -rnE --include='*.php' '\$[A-Za-z_][A-Za-z0-9_]*\{[^}$]*\}' modules override themes

# Sprawdzenie składni każdego pliku PHP docelowym plikiem wykonywalnym PHP, z katalogu głównego staging
# (nazwa bywa różna: php7.4, php74, /opt/cpanel/ea-php74/root/usr/bin/php ...)
find . -type f -name '*.php' -exec php7.4 -l {} \; | grep -v '^No syntax errors'

Brak błędów składni dowodzi tylko, że pliki dają się sparsować. Nie mówi nic o brakujących rozszerzeniach ani o działaniu składania zamówień. Temu służy krok 5.

4. Naprawiaj problemy, zaczynając od najmniejszych zmian

Oto problemy, które najczęściej spotykamy po przeniesieniu starego sklepu na PHP 7.4, wraz z rozwiązaniami:

Najpierw napraw błędy krytyczne, potem ostrzeżenia na ścieżce składania zamówienia, a na końcu resztę. Komunikaty notice i ostrzeżenia o przestarzałych funkcjach nie są nieszkodliwe tylko dlatego, że odwiedzający ich nie widzą: własny mechanizm obsługi błędów modułu może zamieniać je w wyjątki, a ich lawina może zapełnić dysk. Jeśli autor modułu udostępnia aktualizację, wybierz ją zamiast własnej poprawki. Prowadź też listę wszystkich zmienionych plików: przyda się przy przełączeniu działającego sklepu i ponownie przy docelowej aktualizacji. Przy okazji usuń wiersze php_value i php_flag w pliku .htaccess dotyczące ustawień, których PHP już nie rozpoznaje. Komunikat bezpieczeństwa PHP wyraźnie zaleca usunięcie nieprawidłowych lub przestarzałych ustawień stosowanych dla poszczególnych żądań.

<?php
// config/defines_custom.inc.php (PrestaShop 1.6 automatycznie dołącza ten plik)
// PHP 7.2+ nie zawiera mcrypt, ale podpis cookie w 1.6.1 nadal odczytuje tę
// stałą. Wartość taka sama jak w rozszerzeniu mcrypt zachowuje ważność istniejących cookie.
if (!defined('MCRYPT_RIJNDAEL_128')) {
    define('MCRYPT_RIJNDAEL_128', 'rijndael-128');
}

Oto omawiany kod, bez zmian względem PrestaShop 1.6.1.23 (classes/Rijndael.php):

// PrestaShop 1.6.1.23, classes/Rijndael.php
protected function generateHmac($encrypted)
{
    $macKey = $this->generateKeygenS2k('sha256', $this->_key, $this->_iv, 32);
    return hash_hmac(
        'sha256',
        $this->_iv . MCRYPT_RIJNDAEL_128 . $encrypted,
        $macKey
    );
}

5. Sprawdź całą ścieżkę sprzedaży, potem wdróż poprawki i przełącz PHP

Na staging przejdź przez wszystko, co przynosi pieniądze lub generuje pracę: stronę główną, strony kategorii z filtrami, wyszukiwanie, strony produktów z kombinacjami, koszyk, składanie zamówienia z każdym przewoźnikiem i każdą metodą płatności w trybie testowym, potwierdzenie zamówienia, stronę zamówienia w panelu administracyjnym, faktury i dokumenty dostawy w PDF, stronę konfiguracji każdego modułu, importy i adresy zadań cron.

Gdy w logu nie pojawiają się już błędy, zaplanuj przełączenie działającego sklepu na godzinę o małym ruchu:

• Wykonaj kopię zapasową, której odtworzenie masz już przetestowane, zarówno plików, jak i bazy danych.
• Wdróż przetestowane poprawki kodu i przełącz PHP w ramach tej samej operacji. Poprawki pozostają na staging, dopóki ich nie skopiujesz. Nigdy nie zastępuj bazy działającego sklepu bazą staging.
• Od razu sprawdź składanie zamówień, a następnie obserwuj log błędów przez 48 godzin.
• Jeśli musisz wrócić do starego PHP bez poprawek, ogranicz na ten czas dostęp do sklepu i utrzymuj ograniczenia do ponownego uruchomienia PHP z poprawkami.

Zanim zainstalujesz poprawki: środki tymczasowe

Zespół PHP opublikował środki ograniczające narażenie na konkretne ścieżki ataku. Jak sam podkreśla, nie zapewniają one bezpieczeństwa instalacji, a pełne rozwiązanie daje wyłącznie aktualizacja. Nie zapewniają też bezpiecznego okresu oczekiwania. Warto je zastosować na te godziny lub dni, zanim Twój sklep zacznie działać na PHP z poprawkami. Oto jak przełożyć je na sklep PrestaShop.

Ustawienia PHP

Musisz je ustawić w php.ini, w puli PHP-FPM lub w konfiguracji serwera, a nie w .user.ini ani przez ini_set(). Następnie uruchom ponownie wszystkie procesy robocze PHP.

; Tymczasowe środki przeciw PHP2Shell w php.ini (potem uruchom PHP ponownie)
; Rdzeń PrestaShop nie śledzi postępu przesyłania plików, więc można to bezpiecznie wyłączyć
session.upload_progress.enabled = 0
; Mniejsze rozmiary treści żądań. Wartości przykładowe: dopasuj je do potrzeb sklepu,
; nigdy nie podnoś już ustawionego niższego limitu
post_max_size = 32M
upload_max_filesize = 24M
max_file_uploads = 10

; W pliku puli PHP-FPM (np. /etc/php/7.4/fpm/pool.d/shop.conf) te same
; ustawienia wyglądają tak; usuń początkowe średniki, aby je włączyć:
; php_admin_flag[session.upload_progress.enabled] = off
; php_admin_value[post_max_size] = 32M
; php_admin_value[upload_max_filesize] = 24M

Po zmianie limitów sprawdź przesyłanie plików, z których Twój zespół faktycznie korzysta: duże archiwum modułu lub duże zdjęcie produktu może je przekroczyć. Oficjalna lista sugeruje też memory_limit = -1 jako środek przeciw luce związanej z brakiem pamięci, wymuszony tak, aby żadne ustawienie aplikacji nie mogło przywrócić limitu. Pozwala to pojedynczemu żądaniu zużyć całą pamięć serwera, więc jest to opcja wyłącznie dla administratorów, którzy potrafią objąć PHP limitem pamięci kontenera lub cgroup i wiedzą, co się stanie po jego przekroczeniu. Nie usuwa to luki w pełni, a komunikat przestrzega przed stosowaniem zamiast tego RLIMIT_AS lub RLIMIT_DATA. Na hostingu współdzielonym zostaw to dostawcy. Dla PHP 8.5 komunikat wymienia też fatal_error_backtraces = 0.

Zablokuj przesyłanie plików tam, gdzie sklep go nie potrzebuje

Znany exploit dociera jako żądanie multipart/form-data, czyli w formacie używanym przez przeglądarki do przesyłania plików. Większość publicznej części sklepu PrestaShop nigdy go nie potrzebuje. Zablokowanie go poza panelem administracyjnym odcina tę znaną ścieżkę. Co przestanie działać: załączniki w formularzu kontaktowym, pola plików w personalizacji produktów i każdy moduł pozwalający klientom przesyłać pliki. Dla większości sklepów to akceptowalny kompromis na kilka dni.

Najpierw jeden warunek: wyjątek dla panelu administracyjnego ma sens tylko wtedy, gdy na serwerze WWW ograniczysz dostęp do panelu do swoich adresów IP, tak aby żądania z innych adresów w ogóle nie docierały do PHP. Strona logowania PrestaShop nie chroni przed luką wykorzystywaną przed uruchomieniem PrestaShop. Nasz artykuł o bezpieczeństwie panelu administracyjnego zawiera gotowe listy dozwolonych adresów dla Apache i nginx. Jeśli nie możesz tak ograniczyć dostępu do panelu, pomiń wyjątek i na kilka dni wstrzymaj przesyłanie plików również w panelu.

W Apache wstaw ten fragment na samym początku pliku .htaccess sklepu, nad wierszem # ~~start~~, aby PrestaShop zachował go przy ponownym generowaniu pliku. Zastąp admin-folder-name nazwą katalogu panelu administracyjnego:

# Tymczasowy środek przeciw PHP2Shell: blokuj żądania multipart poza panelem administracyjnym.
# Usuń po zainstalowaniu poprawek.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP:Content-Type} multipart/form-data [NC]
RewriteCond %{REQUEST_URI} !^/admin-folder-name/
RewriteRule ^ - [F]
</IfModule>

Reguła działa tylko tam, gdzie mod_rewrite jest aktywne i pliki .htaccess mogą z niego korzystać. Dlatego ją przetestuj: próba przesłania nieszkodliwego pliku przez formularz kontaktowy powinna teraz zwracać stronę błędu 403, a sama ta strona nie może być skryptem PHP.

W nginx, w bloku server sklepu:

# Tymczasowy środek przeciw PHP2Shell: blokuj żądania multipart poza panelem administracyjnym.
set $block_multipart 0;
if ($http_content_type ~* "multipart/form-data") { set $block_multipart 1; }
if ($uri ~ "^/admin-folder-name/") { set $block_multipart 0; }
if ($block_multipart) { return 403; }

Użyj $uri, czyli znormalizowanej ścieżki, jak powyżej. Surową wartość $request_uri dałoby się oszukać ścieżką taką jak /admin-folder-name/../index.php.

Ochrona przed serwerem Twojego sklepu

• Cloudflare wdrożyło reguły WAF dla znanych wektorów ataku, również w darmowych planach. Pomagają tylko wtedy, gdy cały ruch do sklepu rzeczywiście przechodzi przez Cloudflare i nikt nie może połączyć się bezpośrednio z Twoim serwerem. W płatnych planach sprawdź też, czy reguły zarządzane są ustawione na blokowanie. Pojawiły się doniesienia, że atakujący szukają sposobów obejścia tych reguł.
• Imunify360, często spotykane na hostingu współdzielonym, udostępniło reguły blokujące publiczne narzędzie wykorzystujące luki i warianty CVE-2026-109619. Według CloudLinux jego reguły nie obejmują jeszcze CVE-2026-109618. Inne firewalle mają własny, odmienny zakres ochrony.
• Tryb konserwacji nie pomaga. PrestaShop podejmuje decyzję o wyświetleniu strony konserwacji dopiero po przetworzeniu żądania przez PHP. Jeśli hosting nie może szybko zainstalować poprawek, zapytaj, czy może całkowicie zatrzymać niezaufane żądania, zanim dotrą do PHP.

Po instalacji poprawek: sprawdź, czy nie doszło do włamania

Próby ataków obserwowano przed ujawnieniem luk, a luka pozwalająca odczytać pamięć może ujawnić poufne dane bez pozostawienia śladu w sklepie. Jeśli po połowie października Twój sklep był dostępny w internecie na PHP bez poprawek, poświęć godzinę na te kontrole. Wykrywają typowe ślady; brak wyników nie dowodzi, że nic się nie wydarzyło.

# Pliki wykonywalne w katalogach przeznaczonych na obrazy i przesyłane pliki.
# PrestaShop umieszcza index.php w niemal każdym katalogu: je też porównaj z czystą kopią.
find img upload download -type f \( -iname '*.php' -o -iname '*.phtml' -o -iname '*.phar' \)

# Pliki zmienione od pierwszych prób ataku (17 października 2026), również pamięć podręczna.
# To tylko wskazówki: znaczniki czasu można sfałszować. Przejrzyj całą listę.
find . -type f -newermt '2026-10-17 00:00:00 UTC'

-- Konta panelu administracyjnego, od najnowszych. Widzisz coś nieznanego?
SELECT id_employee, firstname, lastname, email, active, last_connection_date
FROM ps_employee
ORDER BY id_employee DESC;

Najpewniejsze jest porównanie z czystą kopią Twojego wydania PrestaShop, Twoich modułów oraz kopią zapasową sprzed 17 października. Uwzględnij pliki JavaScript, bo to w nich działa wstrzyknięty kod wykradający dane płatnicze. Jeśli coś znajdziesz, zabezpiecz dowody i powstrzymaj atak, zanim zmienisz jakiekolwiek hasło. Inaczej nowe dane dostępowe wyciekną tą samą drogą.

Następnie z zaufanego urządzenia zmień poufne dane, które mógł ujawnić wyciek pamięci: wszystkie hasła do panelu administracyjnego, klucze API modułów płatności, przewoźników i platform marketplace, klucze webservice oraz hasła SMTP. Hasło bazy danych zmień jednocześnie na serwerze bazy i w konfiguracji sklepu (config/settings.inc.php w 1.6, app/config/parameters.php w 1.7 i nowszych), a także we wszystkich innych miejscach, które korzystają z niego do połączenia. Inaczej sklep przestanie działać.

Najczęściej zadawane pytania

Źródła

• Zespół PHP: komunikat bezpieczeństwa i ogłoszenia o wydaniach, wraz z komunikatami GHSA-w8hw-w9fx-j79w i GHSA-6wmf-4rv5-p3rp
• PrestaShop: wymagania systemowe wersji 1.6 i 1.7, 8 i 9
• CloudLinux: zakres poprawek PHP2Shell i status pakietów
• Sansec: analiza PHP2Shell dla e-commerce