BigCommerce i Ribon: wyciek przez przejęty klucz aplikacji

Jeden z powiadomionych sprzedawców, Master of Malt, ujawnił także dostęp do danych klientów: imion i nazwisk, adresów e-mail, numerów telefonów oraz adresów dostawy. Dostęp miał występować między 13 a 17 września 2026.

Dla organizacji korzystających z usług SaaS ten przypadek pokazuje ryzyko związane z uprawnieniami zewnętrznych integracji. Zaufana aplikacja może mieć szeroki dostęp do danych i treści, a jej przejęty klucz może ominąć zabezpieczenia skupione wyłącznie na kontach pracowników.

Co wiadomo o incydencie BigCommerce i Ribon

Ribon i Ribon 1.5 były aplikacjami zewnętrznego dostawcy używanymi w sklepach działających na BigCommerce. BigCommerce przekazało mediom, że 17 września potwierdziło przejęcie danych dostępowych tych aplikacji w następstwie naruszenia systemów Fastr, firmy powiązanej z operatorem Ribon.

Przejęty dostęp miał dwa opisane skutki. BigCommerce potwierdziło wykorzystanie danych dostępowych do wstrzyknięcia złośliwych skryptów do niewielkiej liczby witryn sprzedawców. Z kolei Master of Malt poinformował, że napastnik użył klucza aplikacji do pobierania danych klientów.

SecurityWeek, serwis informacyjny poświęcony cyberbezpieczeństwu, przytoczył stanowisko BigCommerce wskazujące na incydent w systemach Fastr jako źródło przejęcia danych dostępowych. Publiczne materiały nie wyjaśniają jednak dokładnie, w jaki sposób doszło do pierwotnego naruszenia Fastr. Tego elementu nie należy uzupełniać domysłami.

Jak klucz zewnętrznej aplikacji otworzył drogę do danych

Integracja SaaS często działa na podstawie klucza lub tokenu, który pozwala jej wykonywać określone operacje bez każdorazowego logowania człowieka. To wygodne, ale oznacza też, że taki sekret staje się samodzielnym środkiem dostępu.

W tym incydencie problem nie polegał na nakłonieniu administratora sklepu do wpisania hasła na fałszywej stronie. Napastnik dysponował danymi dostępowymi aplikacji, której sklepy wcześniej zaufały. Jeżeli integracja ma uprawnienia do odczytu danych lub modyfikowania elementów witryny, przejęcie jej dostępu może przenieść te możliwości na napastnika.

BigCommerce usunęło aplikacje z dotkniętych sklepów, aby odwołać dostęp, powiadomiło sprzedawców i udostępniło logi potrzebne do dochodzenia.

Jakie dane ujawnił Master of Malt

Master of Malt poinformował, że napastnik uzyskał dostęp do danych klientów przechowywanych w środowisku BigCommerce. Wymieniono imiona i nazwiska, adresy e-mail, numery telefonów oraz adresy dostawy.

Według informacji przekazanych przez BigCommerce hasła do kont i dane kart płatniczych są przechowywane oddzielnie i nie zostały ujawnione w tym incydencie. Nie ma więc podstaw, aby rozszerzać opis wycieku o dane płatnicze.

Nie podano potwierdzonej łącznej liczby osób ani sklepów, których dane zostały pobrane. Master of Malt wskazał, że Ribon było używane przez setki sklepów, ale sama obecność aplikacji nie dowodzi, że każdy z nich doświadczył wycieku.

Dlaczego taki wyciek może zwiększyć ryzyko phishingu

Imię i nazwisko, adres e-mail, numer telefonu oraz informacja o relacji ze sklepem mogą pomóc przygotować bardziej wiarygodną wiadomość. Napastnik może próbować nawiązać do dostawy, zamówienia, zwrotu albo obsługi konta.

To jest scenariusz ryzyka, a nie potwierdzony dalszy etap tego konkretnego incydentu. Publiczne źródła opisujące Ribon nie potwierdzają, że ujawnione dane zostały już wykorzystane w kampanii phishingowej.

Dla pracownika i klienta praktyczna zasada pozostaje taka sama: sama znajomość prawdziwych danych nie dowodzi, że wiadomość pochodzi od właściwej firmy. Prośbę o logowanie, płatność, kod lub zmianę danych warto zweryfikować niezależnym kanałem.

Podobny problem z zaufaniem do legalnego komponentu opisujemy w materiale o incydencie Brevo i ClickFix. Tam źródłem ryzyka była zmiana treści dostarczanej przez zewnętrzny komponent; tutaj przejęty klucz aplikacji dawał dostęp w granicach uprawnień integracji.

Co powinna sprawdzić organizacja korzystająca z integracji SaaS

Lista zewnętrznych aplikacji powinna obejmować nie tylko ich nazwy, ale również zakres dostępu: jakie dane mogą odczytywać, co mogą zmieniać i jak szybko można odwołać ich uprawnienia.

Warto też sprawdzić, czy każda integracja nadal jest potrzebna. Nieużywana aplikacja z aktywnym kluczem pozostawia dodatkową drogę dostępu bez wartości biznesowej.

Kolejny element to logi. Organizacja powinna móc ustalić, które operacje wykonała konkretna aplikacja, kiedy to nastąpiło i jakich danych dotyczyło. Bez takiej informacji trudno ocenić rzeczywisty zakres zdarzenia po komunikacie dostawcy.

Znaczenie ma również zasada najmniejszych uprawnień: integracja powinna otrzymywać tylko te możliwości, których wymaga jej funkcja. Ogranicza to skutki sytuacji, w której jej dane dostępowe zostaną przejęte.

Jak uwzględnić ten scenariusz w security awareness

Szkolenie nie powinno sprowadzać tego incydentu do hasła „nie ufaj dostawcom”. Zewnętrzne aplikacje są normalnym elementem środowiska firmowego. Ważniejsze jest rozpoznanie, że dane pochodzące z legalnej usługi mogą zostać użyte do uwiarygodnienia późniejszego kontaktu.

Ćwiczenie może przedstawiać wiadomość odnoszącą się do prawdziwej relacji biznesowej i części poprawnych danych, ale zawierającą nietypową prośbę o logowanie, płatność lub podanie kodu. Oceniane zachowanie to niezależna weryfikacja i zgłoszenie, a nie rozpoznawanie ataku po błędach językowych.

PHISHLY pozwala ćwiczyć takie decyzje w kontrolowanych testach phishingowych dla firm i łączyć je z szerszym programem security awareness.

Co wynika z incydentu Ribon

Incydent rozdziela dwie kwestie, które łatwo połączyć w jeden skrót. BigCommerce nie potwierdziło włamania do własnej platformy. Potwierdziło natomiast nadużycie danych dostępowych aplikacji zewnętrznego dostawcy, które dawały realne możliwości działania w sklepach.

Dlatego przegląd bezpieczeństwa usług SaaS powinien obejmować również integracje i ich sekrety. Klucz aplikacji może mieć znaczenie porównywalne z kontem uprzywilejowanym, jeśli pozwala czytać dane klientów albo modyfikować treść witryny.

Z perspektywy security awareness ujawnione dane kontaktowe tworzą dodatkowy kontekst, który może zostać wykorzystany do podszywania się pod znaną firmę. To wystarczający powód, aby uczyć niezależnej weryfikacji próśb, nawet gdy wiadomość zawiera prawdziwe informacje o odbiorcy.