Zhakowany sklep PrestaShop: jak rozpoznać infekcję i co z nią zrobić

Najgorsza cecha dzisiejszych infekcji sklepów nie jest techniczna, tylko psychologiczna: skimmer płatniczy potrafi celowo wyłączyć się wtedy, kiedy stronę ogląda zalogowany pracownik. Sansec, firma zajmująca się bezpieczeństwem e-commerce, przeanalizowała w lutym 2026 taki skrypt i opisała, że sprawdza on zmienne employee i prestashop.employee oraz element #header_employee_box, a po wykryciu administratora zapisuje w logu [GATEWAY] Admin detected i kończy działanie. Zdanie „sprawdzałem swój checkout i wszystko wygląda normalnie” nie jest więc żadną weryfikacją. Poniżej opisuję, po czym infekcję naprawdę widać, gdzie w PrestaShop siedzi złośliwy kod i w jakiej kolejności to sprzątać, żeby sobie nie zaszkodzić. ---

Po czym poznać, że sklep jest zainfekowany

Ułożyłem to od strony właściciela, a nie od strony logów. Przy każdym punkcie piszę, skąd to wiem.

Widoczne dla klienta:

• Na stronie zamówienia pojawia się formularz karty, którego tam nie było. Sam PrestaShop opisał to w oficjalnym ostrzeżeniu z 22 lipca 2022: po przejęciu sklepu atakujący wstrzykiwali fałszywy formularz płatności na stronę zamówienia w części sklepowej (front office). (potwierdzone: build.prestashop-project.org, wpis z 22.07.2022)
• Klient jest proszony o podanie danych karty dwa razy. To schemat nazwany „double-tap”: najpierw fałszywy formularz, potem prawdziwy. Większość ludzi uznaje to za drobną usterkę i kończy zamówienie, nie wiedząc, że dane już wyciekły. Dlatego zamówienia idą normalnie i przez długi czas nie ma żadnych reklamacji. (potwierdzone: Sansec, analiza z 20.02.2026)
• Podmieniony blok płatności. Po polsku właściciele opisują to dokładnie tak: „Blok płatności zostaje podmieniony przez hakerów na blok do wprowadzania danych karty kredytowej” (forum.prestashop.com, luty 2023) oraz „został podmieniony moduł płatnosci” (styczeń 2024). (potwierdzone: wątki na oficjalnym forum PrestaShop)

Widoczne w Google:

• Ostrzeżenie przy wyniku wyszukiwania albo strona przejściowa w przeglądarce. Google opisuje oba te scenariusze w swojej dokumentacji jako skutek wykrytych problemów bezpieczeństwa. (potwierdzone: support.google.com, dokumentacja Search Console)
• W Search Console, w raporcie Security Issues, pojawia się konkretny typ problemu. Google rozróżnia między innymi: Hacked: Malware, Hacked: Code Injection (wstrzyknięty kod z przekierowaniami, często ukryty cloakingiem), Hacked: Content Injection (spamowy tekst i linki), Hacked: URL Injection (nowe, stworzone przez atakującego podstrony spamowe). Warto sprawdzić, który dokładnie typ masz, bo to podpowiada, gdzie szukać. (potwierdzone: dokumentacja Google)

Widoczne w panelu i na serwerze:

• Zmienione pliki rdzenia. PrestaShop ma to wbudowane: sekcja Parametry zaawansowane > Informacje (w interfejsie angielskim Advanced Parameters > Information) pokazuje listę zmodyfikowanych plików rdzenia. Mało kto o tym wie, a to jedna z szybszych rzeczy do sprawdzenia. (potwierdzone: oficjalna instrukcja PrestaShop z czerwca 2026)
• Zbędne pliki PHP w katalogu modułu. Ta sama instrukcja każe przejrzeć modules/ps_facetedsearch/ i podkatalogi pod kątem nieoczekiwanych plików PHP. (potwierdzone: build.prestashop-project.org, czerwiec 2026)
• Moduły, których nikt nie instalował. Oficjalny alert PrestaShop Help Center wymienia jako wskaźnik infekcji obecność modułów mloader lub simplefilemanager w katalogu /modules/. (potwierdzone: help-center.prestashop.com, „Security Alert: Recommended Check of Your Stores”)
• Skrypt w pliku motywu. Ten sam alert wskazuje konkretnie: tag <script> z wywołaniem atob() i XMLHttpRequest w pliku aktywnego motywu themes/[motyw]/templates/_partials/head.tpl. (potwierdzone: help-center.prestashop.com)
• Nietypowe, powtarzalne lub błędnie sformułowane żądania w logach dostępu, szczególnie do ścieżek związanych z ps_facetedsearch. (potwierdzone: PrestaShop, czerwiec 2026)
• Nie da się zalogować do panelu administracyjnego. Polski użytkownik opisał w styczniu 2025 przypadek, w którym wirus modyfikował kontroler logowania i wysyłał wpisywane loginy oraz hasła na zewnątrz. (potwierdzone: wątek na forum.prestashop.com z 26.01.2025)
• Hosting zablokował konto. To nie jest objaw infekcji sam w sobie, tylko standardowa procedura. home.pl opisuje w bazie wiedzy, że blokada administracyjna realizowana jest wpisem access deny from all w .htaccess, odwiedzający widzą 403 „Dostęp zabroniony”, a zdjęcie blokady należy do klienta, po wcześniejszym usunięciu podatności. cyberFolks pisze wprost: „obowiązek zabezpieczenia strony i innych treści na koncie przed infekcjami wirusów spoczywa na Tobie jako użytkowniku konta”. (potwierdzone: pomoc.home.pl, cyberfolks.pl)

Czego celowo nie wpisuję na tę listę. Często słyszy się objaw „klienci dzwonią, że mają obciążenia z karty”. Nie znalazłem tego wprost w żadnym z przejrzanych źródeł pierwotnych, więc traktuję to jako obserwację praktyczną, nie jako fakt z przypisem. Logicznie pasuje do skimmingu, ale nie będę się przy tym na nikogo powoływać.

I jeszcze jedno, żeby nie było złudzeń co do skali: 16 lutego 2026 Sansec znalazł skimmer płatniczy na sklepie jednej z największych sieci handlowych świata, działającym na PrestaShop. W dniu publikacji analizy, 20 lutego, skimmer nadal działał, mimo sześciu prób powiadomienia firmy. (potwierdzone: sansec.io) Duży dział IT nie jest tu żadną gwarancją.

---

Gdzie w PrestaShop siedzi złośliwy kod

Poniżej lista miejsc, które faktycznie występowały w udokumentowanych przypadkach. Bez „i tak dalej”, bez straszenia.

Pliki

| Miejsce | Co tam bywa | Źródło |

|---|---|---|

| Katalog główny sklepu | plik blm.php, tworzony po udanym ataku SQL injection, potem używany jako web shell | oficjalny wpis PrestaShop, lipiec 2022 |

| themes/[motyw]/templates/_partials/head.tpl | tag script ładujący skimmer, z atob() i XMLHttpRequest | PrestaShop Help Center |

| modules/ps_facetedsearch/ i podkatalogi | nieoczekiwane pliki PHP, zapisane przez podatność opisaną niżej | PrestaShop, czerwiec 2026 |

| modules/onepagecheckoutps/views/templates/front/payment.tpl | podpięcie złośliwego skryptu w szablonie modułu | Sucuri, lipiec 2022 |

| modules/onepagecheckoutps/views/js/front/onepagecheckoutps.js | zaciemniony (obfuskowany) skimmer w pliku JS modułu | Sucuri |

| controllers/front/IndexController.php | przechwytywanie żądania po stronie serwera | Sucuri |

| classes/tools.php | serwerowa obróbka wykradzionych danych | Sucuri |

| config/alias.php | backdoor do zdalnego wykonania kodu | Sucuri |

| config/smarty.config.inc.php | nie sam kod atakującego, tylko funkcja przechowywania cache Smarty w MySQL, wykorzystana jako wektor w 2022 roku; PrestaShop kazał wtedy wyciąć te linie ręcznie | PrestaShop, Friends-of-Presta |

| app/config/parameters.php | nadpisanie danych dostępowych do bazy przez otwarty instalator | Sansec, kwiecień 2026 |

| pliki override | instalator modułów PrestaShop wywołuje eval() na plikach override przy ładowaniu modułu, więc to nie jest zwykły katalog z customizacjami, tylko realny wektor wykonania kodu | Sansec |

| pliki JS o bezsensownych nazwach | w analizie Sucuri było to js/dfsasdf3124sfcad2.js | Sucuri |

Baza danych

• Wartość PS_SHOP_NAME w tabeli konfiguracji (przy domyślnym prefiksie ps_configuration). W fali ataków ze stycznia 2025 atakujący wstrzykiwali złośliwy skrypt właśnie tam. To bardzo sprytne miejsce: nazwa sklepu renderuje się praktycznie na każdej podstronie, więc skrypt z jednego pola konfiguracji trafia na cały front. (potwierdzone: oficjalny wpis PrestaShop z 22.01.2025)
• Cache bloku filtrów faceted search, wykorzystywany w podatności z czerwca 2026. (potwierdzone: GitHub Security Advisory GHSA-m5f5-28qr-9g9r)
• Cache Smarty przechowywany w MySQL, wektor z 2022 roku. (potwierdzone: build.prestashop-project.org, lipiec 2022)

Konfiguracja serwera i wdrożenia

• Pozostawiony katalog instalatora. 14 kwietnia 2026 Sansec opublikował badanie: ponad 200 sklepów PrestaShop w 27 krajach miało publicznie dostępny katalog /install/ lub /install-dev/ na produkcji. Atakujący wchodzi do instalatora bez uwierzytelnienia, przez parametr ?step=process wymusza wykonanie, może nadpisać app/config/parameters.php danymi swojej bazy, podpiąć sklep pod siebie i założyć sobie konto administratora. (potwierdzone: sansec.io)
• Włączony tryb debug na produkcji. W tym samym badaniu Sansec znalazł 15 sklepów z otwartym Symfony Profiler, który pokazuje dane sesji, w tym ciasteczko sesji otwartym tekstem, dane dostępowe do bazy i sekrety aplikacji. (potwierdzone: sansec.io)

Czego nie potwierdziłem. Krążą porady, żeby szukać złośliwego kodu w zadaniach cron i w polach własnego CSS/JS w ustawieniach back office. Nie znalazłem udokumentowanego przypadku ani u PrestaShop, ani u Sansec, ani u Sucuri, ani u Friends-of-Presta. Sprawdzić i tak warto, ale nie będę udawać, że mam na to źródło. Najbliższy potwierdzony odpowiednik to właśnie wstrzyknięcie do PS_SHOP_NAME, czyli do pola ustawień.

Skąd te dziury się biorą, czyli trzy udokumentowane fale

1. Lipiec 2022. SQL injection plus eval injection, CVE-2022-31181, CVSS 9.8. Advisory podaje jako podatne wersje od 1.6.0.10 do 1.7.8.7, przy czym poprawka trafiła właśnie do 1.7.8.7. Wśród komponentów wymieniony był moduł Wishlist w wersjach 2.0.0 do 2.1.0. PrestaShop zalecił wtedy fizyczne wycięcie funkcji cache Smarty w MySQL: usunięcie linii 43 do 46 w config/smarty.config.inc.php dla gałęzi 1.7 i linii 40 do 43 dla 1.6. (potwierdzone: build.prestashop-project.org oraz security.friendsofpresta.org) Uwaga na marginesie: w prasie ta sama luka bywa oznaczana jako CVE-2022-36408, ale w źródłach pierwotnych tego numeru nie potwierdziłem, więc trzymam się CVE-2022-31181.
2. 22 stycznia 2025. Fala ataków wykorzystująca SQL injection, cytując producenta platformy, „nie w rdzeniu PrestaShop, tylko w modułach firm trzecich”. PrestaShop wydał wtedy między innymi aktualizację modułu ps_contactinfo do wersji 3.3.3. Oficjalnego numeru CVE dla tej fali nie znalazłem ani we wpisie PrestaShop, ani w bazie GitHub Advisories, więc go nie podaję. (potwierdzone: build.prestashop-project.org, 22.01.2025)
3. Czerwiec 2026. CVE-2026-54159 w module ps_facetedsearch: PHP Object Injection, CVSS 10.0, wersje modułu od 3.0.0 do 4.0.3 włącznie, na każdym sklepie PrestaShop 1.7.1.0 i nowszym. Wartość suwaka filtra (cena albo waga) brana jest z adresu URL bez wystarczającej walidacji, trafia do wewnętrznego cache bloku filtrów z serializacją, a potem czytana jest z powrotem natywnym unserialize(). Przez odpowiednio spreparowaną wartość atakujący przemyca złośliwy zserializowany obiekt PHP, a łańcuch gadżetów (gadget chain) zapisuje dowolny plik PHP wewnątrz katalogu modułu. Atak jest zdalny i nieuwierzytelniony: wystarczy jedno żądanie do front office, bez logowania i bez socjotechniki. Poprawka: ps_facetedsearch 4.0.4, wydania PrestaShop 9.1.4 i 8.2.7 z 4 czerwca 2026, ostrzeżenie producenta z 3 czerwca 2026. (potwierdzone: GitHub Security Advisory GHSA-m5f5-28qr-9g9r oraz build.prestashop-project.org)

I najważniejszy wniosek z tych trzech fal, wypowiedziany przez samego producenta platformy: krytyczne dziury są zwykle nie w rdzeniu, tylko w modułach, i bardzo często w modułach załatanych dawno temu, ale nieaktualizowanych w konkretnym sklepie. Rdzeń też jest poprawiany, natomiast masowe włamania idą inną drogą. Widać to w rejestrze Friends-of-Presta: CVE-2025-69633 w Advanced Popup Creator (9.8), CVE-2025-61922 w PrestaShop Checkout (9.1), CVE-2026-39079 w UPS Shipping (8.6), a po stronie rdzenia w tym samym czasie CVE-2025-51586 z oceną 3.7, czyli niską (enumeracja użytkowników w formularzu logowania). (potwierdzone: security.friendsofpresta.org)

---

Co robić krok po kroku, i czego nie robić

Zacznę od uczciwej uwagi: PrestaShop nie ma oficjalnego, jednego protokołu „co robić, gdy sklep został zhakowany”. Szukałem tego na build.prestashop-project.org, w devdocs i w help center. Są zalecenia profilaktyczne i są instrukcje do konkretnych podatności, ale nie ma ogólnego planu leczenia. Wszystkie pełne poradniki w wynikach wyszukiwania należą do firm, które sprzedają tę usługę, łącznie z tym tekstem. Warto o tym wiedzieć, czytając kolejne akapity.

Kolejność, którą stosuję

1. Zrób pełną kopię stanu „jak jest”, zanim cokolwiek ruszysz. Pliki i baza. To nie jest kopia do przywrócenia, to materiał dowodowy: bez niego nie odtworzysz, którędy weszli, a bez tego nie zamkniesz sprawy. Jeżeli masz mocne podejrzenie, że dane kart wyciekają teraz, rozważ wcześniejsze wyłączenie sprzedaży albo trybu przyjmowania płatności na czas sprzątania. To już moja praktyka, nie zalecenie producenta.
2. Zabezpiecz logi dostępu, zanim zostaną nadpisane przez rotację. To najczęstszy powód, dla którego przyczyny nie da się później ustalić. W wątku na oficjalnym forum PrestaShop właściciel opisuje, że hosting (LH.pl) odwirusował mu sklep, ale na pytanie, którędy weszli, odpowiedział, że takich logów nie prowadzi. (potwierdzone: forum.prestashop.com, wątek z 02.03.2023)
3. Sprawdź to, co da się sprawdzić z zewnątrz, bez logowania. Skimmer z alertu PrestaShop siedzi w head.tpl, a więc trafia do kodu źródłowego strony frontowej i jest tam widoczny. To ważne właśnie dlatego, że wersja oglądana przez zalogowanego pracownika może być czysta.
4. Przejdź listę kontrolną producenta: zmienione pliki rdzenia w Parametry zaawansowane > Informacje, zbędne pliki PHP w katalogach modułów, obecność modułów mloader i simplefilemanager, nietypowe powtarzalne żądania w logach.
5. Przejrzyj bazę, nie tylko pliki. Wartość PS_SHOP_NAME, cache bloku filtrów, cache Smarty. Sklep z czystymi plikami i skryptem w konfiguracji nadal jest zainfekowany.
6. Ustal, którędy weszli, i zamknij to wejście. Część kroków nie wymaga żadnej aktualizacji: usunięcie /install/ i /install-dev/ z produkcji, ustawienie _PS_MODE_DEV_ na false, odcięcie niepotrzebnych dostępów. To bezpośrednie zalecenia Sansec po ich badaniu instalatorów.
7. Wyczyść wszystkie znalezione ogniska naraz, a potem zmień hasła: administratorzy back office, baza danych, FTP i SFTP, panel hostingu, konta pracowników.
8. Dopiero teraz aktualizuj podatny komponent. Docelowo ps_facetedsearch 4.0.4 albo PrestaShop 9.1.4 lub 8.2.7. Kolejność ma znaczenie: aktualizacja nałożona na niewyczyszczony sklep łata dziurę, ale zostawia na dysku to, co atakujący już tam zapisał. Obie gałęzie, 9.x i 8.2.x, nadal dostają poprawki bezpieczeństwa, co widać po tym, że 4 czerwca 2026 patche wyszły równolegle dla obu. Oficjalne zalecenie PrestaShop przy każdej aktualizacji brzmi: korzystaj z Update Assistant i zrób pełną kopię bazy i plików przed jakąkolwiek aktualizacją.
9. Jeżeli nie możesz zaktualizować od razu, PrestaShop podaje tymczasowe środki dla ps_facetedsearch: usunięcie suwaków ceny i wagi z renderowanych szablonów, wyczyszczenie cache filtrów, sprawdzenie katalogu modułu pod kątem zbędnych plików PHP oraz blokowanie na poziomie WAF żądań z sygnaturami serializacji PHP w rodzaju O: czy ;i:. Producent sam podkreśla, że to tylko most, a aktualizację trzeba zaplanować jak najszybciej.
10. Dopiero na końcu zgłoś stronę do ponownego sprawdzenia w Search Console i osobno załatw sprawy formalne, o których w następnej sekcji.

Czego nie robić

• Nie przywracaj samej kopii zapasowej i nie uznawaj sprawy za zamkniętą. Backup sklepu z ps_facetedsearch 4.0.3 przywróci wersję 4.0.3, czyli dokładnie ten sam nieuwierzytelniony RCE. To mój wniosek, nie cytat, ale oparty na twardej przesłance: PrestaShop każe sprawdzać katalog modułu na obecność zbędnych plików PHP osobno, już po aktualizacji, co oznacza, że sam patch nie usuwa zainstalowanego wcześniej web shella. Dodatkowo home.pl uprzedza w swojej bazie wiedzy, że kopie trzyma 3 dni, więc przy infekcji starszej niż tydzień przywrócenie backupu i tak przywróci pliki już zainfekowane.
• Nie usuwaj jednego znalezionego pliku i nie kończ na tym. W analizie Sucuri jedna infekcja była rozłożona na minimum pięć plików w czterech różnych miejscach: moduł, kontroler front, classes, config. Usunięcie jednego z nich nie zmienia nic poza tym, że traci się ślad.
• Nie opieraj się na tym, że „u mnie w przeglądarce wygląda dobrze”. To dokładnie ten mechanizm, o którym pisałem na wstępie: skrypt wykrywa administratora i wyłącza się.
• Nie zakładaj, że lista skryptów zewnętrznych coś ci powie na pierwszy rzut oka. Skimmer z 2026 roku pakował dane karty do localStorage pod kluczami cardNum, exp, cvv, kodował je Base64 i wysyłał żądaniem GET na ścieżkę w rodzaju /api/send-metrics?metrics=<payload>, podszywając się pod analitykę. W przypadku z 2022 roku było jeszcze gorzej: dane szły najpierw na własny adres sklepu (index.php?pop=7), a dopiero serwer szyfrował je kluczem publicznym atakującego i wysyłał na zewnątrz przez CURL. W ruchu przeglądarki nie widać wtedy nic podejrzanego.
• Nie licz na to, że hosting to posprząta. cyberFolks pisze wprost, że nie ingeruje w treści użytkowników i że obowiązek zabezpieczenia leży po stronie klienta, a home.pl wymaga, żeby klient sam usunął wpis blokujący z .htaccess, wcześniej zamykając podatność.
• Nie obiecuj sobie terminu zdjęcia ostrzeżenia przez Google. Nie potwierdziłem żadnego oficjalnego SLA dla sekcji Security Issues. Ogólna formuła Google o tym, że przegląd „może zająć od kilku dni do kilku tygodni”, dotyczy wniosków o ponowne rozpatrzenie w ogóle. Kto obiecuje konkretną datę, obiecuje coś, na co nie ma wpływu.
• Nie zostawiaj sklepu wyłączonego na miesiące ze strachu. Realny scenariusz z polskiego forum: „Mój sklep został zhakowany 2 raz w ciągu 3 miesięcy (...) nie odważyłem się ponownie udostępnić sklepu i jest on obecnie w trybie Przerwy Technicznej”. Sklep był wyczyszczony przez hosting, ale nikt nie ustalił przyczyny, więc właściciel nie miał podstaw, żeby go włączyć. Bez znalezienia wejścia nie ma momentu, w którym można powiedzieć „skończone”.

---

Dlaczego sklep to zupełnie inny przypadek niż zwykła strona

Przy blogu na WordPressie zhakowanie jest problemem technicznym i wizerunkowym. Przy sklepie dochodzą trzy rzeczy, których na stronie firmowej po prostu nie ma. Poniższy fragment to opis przepisów, a nie porada prawna: w konkretnej sprawie ocenę zostaw prawnikowi albo inspektorowi ochrony danych.

Po pierwsze, dane osobowe i dane kart. Jeżeli doszło do skimmingu albo do wycieku danych klientów, wchodzi RODO. Artykuł 33 ustęp 1 mówi, że administrator zgłasza naruszenie organowi nadzorczemu bez zbędnej zwłoki, w miarę możliwości nie później niż w terminie 72 godzin po stwierdzeniu naruszenia, chyba że jest mało prawdopodobne, by naruszenie skutkowało ryzykiem naruszenia praw lub wolności osób fizycznych. Zgłoszenie ma zawierać charakter naruszenia, kategorie i przybliżoną liczbę osób oraz wpisów, których dotyczy, kontakt do inspektora ochrony danych lub innej osoby odpowiedzialnej, prawdopodobne konsekwencje oraz zastosowane i planowane środki. Administrator ma też obowiązek dokumentowania każdego naruszenia. (potwierdzone: tekst rozporządzenia 2016/679)

Po drugie, obowiązek powiadomienia samych klientów. Artykuł 34 mówi, że jeżeli naruszenie może powodować wysokie ryzyko dla praw i wolności osób fizycznych, administrator zawiadamia o nim także osoby, których dane dotyczą. Wyjątki są, między innymi gdy dane były zabezpieczone środkami czyniącymi je nieczytelnymi, na przykład szyfrowaniem, albo gdy podjęto działania eliminujące wysokie ryzyko. Wykradzenie danych kart trudno uznać za sytuację niskiego ryzyka. Dla wielu właścicieli to najboleśniejsza część całej sprawy i lepiej wiedzieć o niej od razu niż w trzecim tygodniu.

Praktyczna uwaga do tych 72 godzin. W Polsce naruszenia zgłasza się do UODO, z tym samym terminem z art. 33 ust. 1. Jeżeli w pierwszym zgłoszeniu nie masz jeszcze pełnego obrazu, w sekcji 1 formularza zaznacza się „Zgłoszenie wstępne”. Czyli nie trzeba mieć skończonego dochodzenia, żeby zdążyć. Kontakt: infolinia 606-950-000, ul. Stanisława Moniuszki 1A, 00-014 Warszawa, [email protected]. (potwierdzone: uodo.gov.pl) Nie wypisuję tu wszystkich kanałów składania zgłoszenia, bo na stronie, którą otwierałem, nie były wyliczone, a nie zamierzam zgadywać.

Po trzecie, wymagania branżowe wobec strony płatności. PCI DSS w wersji 4.0 dodał wymaganie 6.4.3 (inwentaryzacja i autoryzacja wszystkich skryptów ładowanych w przeglądarce na stronie płatności, z uzasadnieniem i kontrolą integralności) oraz 11.6.1 (mechanizm wykrywania i alertowania o nieautoryzowanych zmianach zawartości strony płatności i nagłówków HTTP w postaci, w jakiej otrzymuje je przeglądarka kupującego, uruchamiany nie rzadziej niż raz na siedem dni). Oba stały się obowiązkowe od 31 marca 2025 w ramach PCI DSS v4.0.1. Uczciwe zastrzeżenie: te dwa wymagania znam ze zgodnych ze sobą opracowań branżowych, samego dokumentu PCI DSS nie otwierałem, więc traktuj to jako mocną przesłankę, nie jako cytat z normy. Osobno potwierdzone jest to, że PCI Security Standards Council wspólnie z Retail & Hospitality ISAC wydał 1 sierpnia 2019 biuletyn o zagrożeniu skimmingiem online, a 10 marca 2025 osobny materiał „Payment Page Security and Preventing E-Skimming”. W biuletynie z 2019 roku pada też stwierdzenie, że złośliwy kod tego typu jest bardzo trudny do wykrycia, oraz wyjaśnienie terminu Magecart jako parasolowej nazwy dla kilku grup przestępczych.

A czego tu nie napiszę. Nie mam potwierdzonego źródła mówiącego, jak często operatorzy płatności wypowiadają umowy po incydencie skimmingu. Więc ani tym nie straszę, ani nie zapewniam, że nic się nie stanie. Faktem, który mogę udokumentować, jest to, że formalne wymagania wobec skryptów na stronie płatności istnieją i są rozliczalne.

Kontekst polski. Według agregatora StoreLeads, stan na 24 lipca 2026, śledzonych jest 154 783 działających sklepów na PrestaShop, z czego w Polsce 13 719, co daje nam trzecie miejsce na świecie po Francji i Hiszpanii. To dane komercyjnego agregatora, nie oficjalna statystyka PrestaShop, więc podaję je ze źródłem i datą. Udziałów rynkowych w procentach świadomie nie podaję: dostępne szacunki różnią się między sobą wielokrotnie i żadnemu z nich nie ufam na tyle, żeby go tu wpisać.

---