Przejęcie checkoutu w Shopify: które aplikacje, co sprawdzić i jak wrócić do sprzedaży

Rejestr zgłoszeń dotyczących aplikacji sprawdzony 19 października 2026 (czas warszawski); instrukcje platformy sprawdzone 18 października. Godziny aktualizacji dostawców podajemy w UTC. Nazwy przycisków i menu podajemy tak, jak widnieją w angielskiej wersji panelu Shopify i w jego dokumentacji.

Jeśli przekierowanie dzieje się teraz: w Online Store wybierz Public → Private → Update, żeby ograniczyć publiczny dostęp do sklepu (instrukcja Shopify), a potem skontaktuj się z pomocą Shopify i twórcą podejrzanej aplikacji. Zachowaj adres URL lub zrzut ekranu, który klient już przysłał, oraz godzinę zdarzenia; nie proś go o ponowne wpisywanie danych. Nie musisz znać przyczyny, żeby powstrzymać dalsze narażenie klientów. Pełne kroki ograniczania dostępu wyjaśniają, jak sprawdzić blokadę i jej zasięg.

Jeśli masz tylko nazwę aplikacji z czyjegoś zgłoszenia, najpierw ustal, czy twój sklep w ogóle był objęty incydentem. Sama instalacja aplikacji nie dowodzi, że sklep został zaatakowany.

Możesz przejść przez poradnik po kolei albo od razu otworzyć ostrzeżenie o serii usunięć aplikacji, rejestr aplikacji, ograniczenie dostępu do sklepu, zgłoszenie do wsparcia, ponowne otwarcie lub komunikację z klientami.

Zacznij od swojej sytuacji

Prawidłowy wynik dzisiaj nie dowodzi, że nikt nie był narażony wcześniej. Tak samo poprawka dostawcy nie wskazuje wszystkich klientów, którzy mogli trafić na fałszywy formularz.

Podejrzana seria usunięć aplikacji z App Store

Ostrzeżenie: w przejrzanym przez nas zestawieniu archiwalnym 126 aplikacji oznaczono jako usunięte z App Store, z czego 89 wpisów ma datę 15 października 2026. Tak duża liczba wpisów z jednego dnia wymaga wyjaśnienia i sprawdzenia aplikacji, od których zależy twój sklep. Nie dowodzi jednak, że wszystkie 126 aplikacji zostało zaatakowanych ani że usunięto je z tego samego powodu.

Oddzielaj tę szerszą listę od rejestru incydentów poniżej. Pobierz zestawienie 126 aplikacji: przyczyna usunięcia każdej z nich jest oznaczona jako niezweryfikowana. Zestawienie nie wyjaśnia, czy podane daty oznaczają rzeczywiste usunięcie, czy dzień, w którym narzędzie je wykryło. Żadna z tych dat nie ustala, kiedy aplikacja mogła zostać zaatakowana.

Shopify opisuje też inne powody usuwania aplikacji. Zgodnie z zasadami wersjonowania API aplikacje, które po terminie aktualizacji nadal korzystają z niewspieranych zasobów, są usuwane z App Store. Harmonogram wskazuje 16 października 2026 o 15:00 UTC jako koniec dostępności wersji API 2025-10. To alternatywne wyjaśnienie, które warto sprawdzić w tym okresie; nie mamy dowodów, że dotyczy tej grupy aplikacji.

Nie znaleźliśmy publicznego oświadczenia Shopify, które wiązałoby listę 126 aplikacji lub 89 wpisów z 15 października z jednym incydentem bezpieczeństwa. Udokumentowane przejęcia checkoutu również nie dowodzą, że za wszystkimi aplikacjami stał ten sam napastnik.

Jeśli używasz aplikacji z tego zestawienia, zapytaj twórcę, dlaczego jest niedostępna, czy problem dotyczy już działających instalacji i czy twój sklep obejmuje komunikat o incydencie. Zaobserwowane niebezpieczne przekierowanie wymaga natychmiastowego odcięcia zagrożonej ścieżki. Sam wpis w archiwum jest powodem do sprawdzenia sprawy, a nie automatycznym dowodem ataku ani zaleceniem usunięcia wszystkich aplikacji.

Które aplikacje wiązano ze zgłoszeniami?

Publicznie dostępne dowody potwierdzają poniższe wpisy według stanu na 19 października 2026. Każdy wiersz podaje datę incydentu i rodzaj dowodu: relację z pierwszej ręki, potwierdzoną przez dostawcę awarię albo potwierdzony przez dostawcę incydent phishingowy. Rejestr obejmuje aplikacje wymienione w publicznych zgłoszeniach. Brak aplikacji w rejestrze nie oznacza, że jest bezpieczna, a obecność w nim nie jest bieżącą oceną jej bezpieczeństwa.

Wcześniejsze zgłoszenia i powiązane incydenty

Daty i rodzaj dowodów mają znaczenie, jeśli w otrzymanym ostrzeżeniu pojawia się nazwa starszej aplikacji.

Fast Bundle to powiązany, historyczny incydent bezpieczeństwa, z innym ograniczeniem dowodów. Jego oficjalna chronologia stanu usługi potwierdza atak 17 lipca 2026 i podaje, że naprawę i pełny powrót do App Store zakończono do 3 sierpnia. Chronologia nie potwierdza mechanizmu fałszywego checkoutu. Nie należy liczyć go jako kolejnego potwierdzonego październikowego przejęcia checkoutu.

Nazwy z list ostrożnościowych też trzeba sprawdzić. Nie ustaliliśmy udziału w przejęciu checkoutu aplikacji Hulk Contact Form Builder, Swym Back in Stock Alerts ani Hextom Free Shipping Bar. Wcześniejszy zarzut sprzedawcy wobec Hulk Advanced Wishlist również nie ma w przejrzanych źródłach potwierdzonej daty incydentu ani opisu technicznego. Instalacja obok innej aplikacji, wspólny twórca czy niedostępna strona w App Store nie wystarczą, żeby dopisać aplikację do potwierdzonych przypadków.

Niedostępna strona w App Store, wyłączone rozszerzenie, usunięcie złośliwego kodu i powrót sprzedawcy do sprzedaży to różne zdarzenia. Pytaj, co faktycznie stało się z komponentem zainstalowanym w twoim sklepie.

1. Odetnij zaobserwowane przekierowanie

Jeśli wiesz, który komponent jest podejrzany, wyłącz problematyczne działanie i zaangażuj jego twórcę. Jeśli nie da się pewnie odizolować niebezpiecznej ścieżki zakupu, ogranicz dostęp do Online Store na czas dochodzenia Shopify i twórcy aplikacji.

Udokumentowane przez Shopify kroki na komputerze, sprawdzone 18 października 2026:

1. W panelu Shopify otwórz Online Store.
2. Otwórz menu dostępu oznaczone Public.
3. Wybierz Private i kliknij Update.

Alternatywnie: Online Store → Preferences → Store access → Private mode. Ustaw hasło dostępu do sklepu inne niż hasło logowania do panelu i zapisz zmiany. Zobacz instrukcję Shopify dotyczącą dostępu do sklepu.

Sprawdź efekt w przeglądarce bez zalogowanej sesji i bez zapisanego hasła odwiedzającego. Zamiast ścieżki zakupu powinna pojawić się strona z hasłem. Hasło dostępu przekaż tylko osobom prowadzącym dochodzenie; opublikowane hasło niweczy blokadę.

Te ustawienia ograniczają tylko Online Store. Poinformuj wsparcie o każdej witrynie sklepu zbudowanej poza Online Store i każdym innym kanale sprzedaży i potwierdź, co nadal jest dostępne. Wstrzymanie reklamy czy samego przycisku checkoutu nie zamyka wszystkich ścieżek, które klient może mieć już otwarte.

Dla podejrzanego osadzenia aplikacji otwórz w aktywnym motywie Edit theme → App embeds, wyłącz właściwe osadzenie i zapisz. Shopify opisuje te ustawienia w dokumentacji aplikacji w motywie. Zapisz każdą zmianę. Osadzenie to tylko jeden z możliwych punktów integracji: jego wyłączenie nie dowodzi, że cały kod aplikacji zniknął.

Zbieraj dowody szybko, równolegle z odcinaniem problemu. Nie zostawiaj niebezpiecznej ścieżki otwartej tylko po to, żeby lepiej ją nagrać.

2. Zbierz krótki, przydatny zapis dowodów

Zachowaj zgłoszenie, które klient już przysłał, zamiast prosić go o powtórzenie zdarzenia albo ponowne wpisanie danych płatniczych. Zapisz:

• kiedy to się stało, ze strefą czasową;
• stronę i działanie tuż przed przekierowaniem, na przykład przycisk Checkout w wysuwanym koszyku;
• nieoczekiwaną stronę docelową i ewentualny zrzut ekranu;
• przeglądarkę i urządzenie, jeśli je znasz;
• komunikaty aplikacji i dostawców oraz istotne niedawne zmiany;
• godzinę i treść każdego działania ograniczającego.

Pełne zgłoszenia klientów trzymaj w miejscu z ograniczonym dostępem. Zanim wkleisz adres URL lub zrzut ekranu na publicznym forum, usuń z niego tokeny i dane osobowe. Nie zbieraj numerów kart ani kodów CVV jako dowodów; zgłoszenie do wsparcia ich nie potrzebuje.

Usunięcie aplikacji lub wyczyszczenie ustawień może utrudnić odtworzenie zdarzeń. Jeśli możesz to zrobić bezpiecznie, zachowaj komunikaty i zapis podejrzanych ustawień. Zapytaj dostawcę, jakich jeszcze dowodów potrzebuje i jak je bezpiecznie przekazać.

3. Sprawdź rzeczywiste ścieżki zakupu

Liczy się to, czy droga klienta zgadza się z zamierzonym procesem płatności w sklepie. Prawdziwy operator płatności może działać pod inną domeną, więc zasada „każda zewnętrzna domena jest złośliwa” jest błędna. Ustal oczekiwane strony docelowe na podstawie skonfigurowanych metod płatności, a w razie potrzeby zapytaj platformę lub dostawcę.

Dla każdej ścieżki, którą faktycznie oferuje twój sklep:

1. Otwórz nowe okno prywatne, wcześniej zamykając inne okna prywatne, żeby nie korzystać z ich sesji.
2. Dodaj do koszyka zwykły produkt i użyj właściwego przycisku zakupu: strony koszyka, wysuwanego koszyka albo przycisku szybkiego zakupu.
3. Zanim wpiszesz jakiekolwiek dane osobowe lub płatnicze, sprawdź, dokąd trafiasz i jak wygląda strona.
4. Zapisz ścieżkę, urządzenie i przeglądarkę, godzinę i wynik. Na nieoczekiwanym formularzu przerwij i wróć do odcinania problemu i kontaktu ze wsparciem.

Nie wpisuj prawdziwych danych na podejrzanej stronie, żeby ją sprawdzić. Techniczną analizę podejrzanego kodu zostaw zespołowi, który prowadzi dochodzenie.

Nowa sesja ma znaczenie, bo udokumentowany skrypt powiązany z Hulk zapisywał informację w pamięci sesji przeglądarki, żeby nie przekierować tej samej osoby drugi raz. Druga próba w tej samej sesji mogła więc wyglądać normalnie. Opisuje to oryginalna analiza.

Działanie sesji opisane w analizie skryptu powiązanego z Hulk. Inne incydenty mogą przebiegać inaczej.

Wyniki sprawdzeń w nowej sesji zapisuj osobno od zgłoszeń powracających klientów. Zapytaj dostawcę, czy wcześniej wczytana konfiguracja lub dane zapisane w przeglądarkach wymagają naprawy. Wyczyszczenie własnej przeglądarki nie mówi nic o tym, co widzieli inni klienci.

Jeśli dostawca już wskazał twój sklep jako narażony, badaj ten okres dalej, nawet jeśli obecna ścieżka działa normalnie.

4. Wyślij jedno kompletne zgłoszenie do wsparcia

Przy zaobserwowanym przekierowaniu skontaktuj się z pomocą Shopify i twórcą aplikacji. Centrum pomocy Shopify otwieraj ze znanego, zaufanego miejsca. Do twórcy aplikacji Shopify prowadzi przez Settings → Apps → menu aplikacji → Get support. Jeśli aplikacji nie ma już na liście albo tej opcji brakuje, skorzystaj z oficjalnej strony dostawcy lub poproś o pomoc Shopify. Ścieżki opisuje poradnik Shopify o wsparciu dla aplikacji.

W sprawie ujawnionego incydentu Selleasy LogBase podaje w oficjalnym komunikacie adres [email protected]. Podaj numer istniejącego zgłoszenia, żeby cała historia sklepu była w jednym miejscu.

Skopiuj poniższe zgłoszenie albo pobierz je jako plik tekstowy:

Sklep i osoba kontaktowa:
Numer zgłoszenia w Shopify / numer zgłoszenia u twórcy aplikacji:
Dokładna nazwa aplikacji i jej twórca:
Co zaobserwowaliśmy (lub jaki komunikat dostawcy otrzymaliśmy):
Pierwsza / ostatnia znana obserwacja, ze strefą czasową:
Ścieżka zakupu oraz urządzenie/przeglądarka:
Obecne ograniczenie dostępu lub wyłączony komponent:
Podjęte działania: kto i kiedy:
Dowody dostępne bezpiecznym kanałem:

Prosimy o potwierdzenie:
1. Czy ten sklep był objęty incydentem i jaki jest okres narażenia?
2. Którego komponentu lub ustawienia to dotyczyło i co zmieniono?
3. Jakie informacje klienci mogli podać na zewnętrznej stronie?
4. Czy naprawa obejmuje wcześniej wczytaną/zapisaną konfigurację?
5. Jakie dowody potwierdzają naprawę w tym sklepie?
6. Czy nadal obowiązuje jakieś ograniczenie platformy i kto je zdejmie?
7. Kto odpowiada za następną informację i kiedy możemy się jej spodziewać?

Dochodzenie, usunięcie problemu, zakres narażenia i zgoda na wznowienie sprzedaży to osobne odpowiedzi. Ogólne „aplikacja jest bezpieczna” ich nie zastępuje. Z kolei zwykły czas odpowiedzi wsparcia twórcy aplikacji nie jest powodem, żeby czekać z eskalacją aktywnego przekierowania.

5. Potwierdź usunięcie i oceń okres narażenia

Wykonaj instrukcje naprawy, które dostawca przygotował dla twojego sklepu. Zapisz, które rozszerzenie, konfigurację lub kod zmieniono i czy twój zespół musi zrobić coś jeszcze.

Odinstalowanie nie zawsze oznacza pełne sprzątanie. Shopify podaje, że niektóre aplikacje zostawiają kod w motywie i wymagają dodatkowych kroków. Jego instrukcja odinstalowania omawia też zależności i dane aplikacji. Nie usuwaj na ślepo nieznanego kodu i nie odinstalowuj hurtem niepowiązanych narzędzi. Korzystaj z instrukcji usuwania od dostawcy; poradnik audytu i usuwania aplikacji opisuje zwykłą kolejność usuwania.

Razem z zespołem prowadzącym dochodzenie przejrzyj dostęp do kont i paneli dostawców. Wskazówki Shopify dotyczące bezpiecznego logowania pomagają lepiej chronić konto. Zmiana hasła czy włączenie weryfikacji dwuetapowej nie usuwa jednak złośliwego skryptu dostarczonego przez dostawcę.

Przy ocenie skutków ustal okres narażenia twojego sklepu, pola formularza, które mogły zostać wypełnione, znane zgłoszenia i dowody stojące za każdym ustaleniem. Klient mógł wpisać dane w fałszywy formularz i nie złożyć prawdziwego zamówienia. Zrealizowane zamówienia nie są więc pełną listą potencjalnie narażonych osób.

Zapewnienie dostawcy, że jego własna baza danych nie została naruszona, dotyczy innego systemu niż zewnętrzny formularz phishingowy. Zachowaj to rozróżnienie w wewnętrznych notatkach i w komunikacji z klientami. Komunikat Selleasy pokazuje, dlaczego te pytania wymagają osobnych odpowiedzi.

6. Sprawdź poprawkę i uzgodnij ponowne otwarcie

Zanim przywrócisz zablokowaną ścieżkę zakupu, zbierz jeden zapis zamknięcia:

Jeśli Shopify polecił ci utrzymać ograniczenie dostępu, wyjaśnij to z jego zespołem. Poprawka komponentu przez dostawcę i decyzja platformy o ponownym otwarciu mogą być osobnymi sprawami. Przypadek WAGD opisany 16 października i zaktualizowany 17 października pokazuje ten problem z koordynacją; to datowany przypadek, a nie informacja o dzisiejszym stanie tego sklepu.

Sprawdź funkcje, które mogły ucierpieć przy odcinaniu problemu: wymagane opcje produktu, ilości, sumy w koszyku i właściwy checkout. Gdy zespół prowadzący dochodzenie potwierdzi prawdziwą ścieżkę, a ograniczenia zostaną zdjęte, przeprowadź pełny test zakupu metodą zatwierdzoną przez platformę lub dostawcę. Nigdy nie testuj płatności na podejrzanej, podrobionej stronie.

Jeśli dochodzenie w sprawie wcześniejszego narażenia ma jeszcze otwarte pytania, prowadź je dalej. Ponowne otwarcie sklepu i zamknięcie wszystkich pytań o skutki dla klientów nie muszą nastąpić jednocześnie; zapisz, kto odpowiada za każdą otwartą sprawę.

7. Przekaż klientom rzetelne, przydatne informacje

Klienci potrzebują faktów, działań, które mogą podjąć, i miejsca, gdzie znajdą kolejne informacje. Wyraźnie oddzielaj potwierdzone obserwacje, ustalenia dostawcy i pytania bez odpowiedzi.

Na przykład „usunęliśmy problematyczną aplikację” opisuje działanie. Nie oznacza, że „żadne dane klientów nie zostały podane”. Nie zamieniaj braku dowodów w zapewnienie i nie publikuj wrażliwych dowodów, które stworzą kolejne narażenie.

Poradnik amerykańskiej FTC dla firm zaleca rzetelny plan komunikacji i jasne odpowiedzi na pytania, których można się spodziewać. Obowiązki zgłoszeniowe, terminy i wymagania operatora płatności zależą od firmy, incydentu i miejsca prowadzenia sprzedaży, więc poproś doradcę lub operatora płatności, żeby jak najszybciej je potwierdził. Poniższy wzór porządkuje fakty; nie jest sformułowaniem prawnym.

Temat: Informacja o problemie z checkoutem w sklepie [sklep]

[Data, godzina i strefa czasowa] [potwierdziliśmy obserwację / otrzymaliśmy komunikat].
[Wyjaśnij potwierdzone zachowanie prostym językiem.]

Wykonaliśmy już: [działania faktycznie zakończone].
Nasz dostawca potwierdził [ustalenie, źródło/data i jego zakres].
Nadal ustalamy [pozostałe pytania].

Jeśli [sytuacja klienta, której to dotyczy], [działanie uzgodnione z zespołem
dochodzenia/operatorem płatności; nie wymyślaj zapewnień ani ustaleń o narażeniu].

W razie pytań skontaktuj się z nami przez [oficjalny kanał kontaktu].
Kolejną informację opublikujemy w [miejsce] do [godzina/data realna do dotrzymania].

Wypełniaj tylko te pola, które możesz poprzeć faktami. Jeśli ktoś mówi, że wpisał dane karty na podejrzanej stronie phishingowej, od razu skieruj go do wydawcy karty przez zaufany kanał kontaktu; nie proś o przesłanie tych danych na adres wsparcia. Zapisuj, komu, co i kiedy przekazano.

Gdy minie największa presja

Zachowaj chronologię incydentu i ustalenia dostawców. Wykorzystaj je, żeby pozbyć się zbędnych zależności i ułatwić śledzenie przyszłych zmian. Nasz poradnik audytu aplikacji zawiera arkusz do tego późniejszego przeglądu; nie musisz go kończyć, zanim odetniesz aktywny problem.

Budujemy Setkę, w której kod sklepu, obsługiwane integracje i droga do płatności pozostają w kontrolowanej architekturze platformy. Nasze wyjaśnienie modelu bezpieczeństwa sklepu opisuje tę granicę dla sprzedawców, którzy rozważają inny sposób prowadzenia sklepu. Twoje najpilniejsze zadanie to przeprowadzić obecny sklep i jego klientów przez ten incydent.