Naruszenie danych u partnera logistycznego Trezora objęło 67 tys. klientów z USA

Wprowadzenie do problemu / definicja

Incydenty bezpieczeństwa po stronie dostawców zewnętrznych należą do najtrudniejszych wyzwań w nowoczesnym cyberbezpieczeństwie. Najnowsza sprawa dotycząca Trezora pokazuje, że nawet jeśli producent nie odnotuje bezpośredniego włamania do własnej infrastruktury, naruszenie u partnera logistycznego może doprowadzić do ujawnienia danych klientów i wygenerować poważne ryzyko operacyjne.

W tym przypadku problem dotyczy danych zamówień przechowywanych przez ShipMonk. Trezor podkreśla, że incydent nie objął portfeli sprzętowych, kluczy prywatnych ani seed phrase, jednak sam wyciek danych identyfikacyjnych i adresowych klientów stanowi istotne zagrożenie.

W skrócie

Naruszenie objęło dodatkowo około 67 tys. klientów z USA.
Ujawnione dane obejmowały m.in. imię i nazwisko, adres e-mail, numer telefonu, adres dostawy oraz numer zamówienia.
Dane dotyczyły zamówień z okresu od listopada 2019 do sierpnia 2021.
Incydent miał miejsce po stronie partnera logistycznego ShipMonk, a nie w infrastrukturze Trezora.
Największe ryzyko dotyczy phishingu, socjotechniki oraz potencjalnych zagrożeń fizycznych.

Kontekst / historia

Sprawa jest rozwinięciem wcześniejszego incydentu ujawnionego w sierpniu 2026 roku. Wówczas informowano o mniejszej skali wycieku, obejmującej około 13,7 tys. klientów. Komunikacja firmy sugerowała wtedy, że zakres incydentu został ograniczony dzięki 90-dniowej polityce retencji danych związanych z zamówieniami.

Na początku września 2026 roku Trezor przekazał jednak, że ShipMonk zidentyfikował dodatkowy zbiór historycznych danych klientów z USA. Szczególnie istotne jest to, że dane te miały wcześniej zostać usunięte zgodnie z deklarowaną polityką retencji. Oznacza to, że problem nie dotyczy wyłącznie samego włamania, ale również nadzoru nad procesami usuwania danych oraz rzeczywistej kontroli nad praktykami partnerów biznesowych.

Analiza techniczna

Dostępne informacje wskazują, że źródłem incydentu był nieautoryzowany dostęp do systemów ShipMonk. To klasyczny przykład ataku na łańcuch dostaw, w którym przestępcy nie uderzają bezpośrednio w producenta końcowego, lecz w podmiot przetwarzający jego dane operacyjne.

W doniesieniach dotyczących sprawy pojawia się również wątek krytycznej podatności typu SQL injection w Metabase, oznaczonej jako CVE-2026-72898. Jeśli podatny komponent analityczny miał dostęp do baz danych zawierających informacje o zamówieniach, wykorzystanie luki mogło umożliwić odczyt i eksport rekordów klientów.

Najbardziej niepokojący aspekt incydentu dotyczy jednak trwałości danych w środowisku partnera. Trezor deklarował ograniczoną retencję danych zakupowych do 90 dni, tymczasem ujawnione rekordy obejmowały znacznie starszy okres. Może to wskazywać na kilka potencjalnych słabości:

nieskuteczne usuwanie danych z systemów operacyjnych,
pozostawienie danych w warstwach pośrednich lub narzędziach analitycznych,
brak spójnej anonimizacji danych historycznych,
nieprawidłową segmentację środowisk i zbiorów danych,
niewystarczającą weryfikację wykonania polityk retencyjnych.

Z perspektywy bezpieczeństwa jest to ważna lekcja: sama polityka prywatności i formalne zapisy umowne nie gwarantują ochrony, jeśli organizacja nie potrafi technicznie potwierdzić, że dane rzeczywiście zostały usunięte.

Konsekwencje / ryzyko

Choć incydent nie naruszył bezpieczeństwa kryptograficznego urządzeń Trezora, jego skutki dla klientów mogą być poważne. Połączenie danych identyfikacyjnych, kontaktowych i adresowych z informacją o zakupie portfela sprzętowego znacząco zwiększa skuteczność ataków socjotechnicznych.

Cyberprzestępcy mogą wykorzystywać te informacje do przygotowywania wiarygodnych kampanii phishingowych, fałszywych wiadomości od przewoźników, podszywania się pod wsparcie techniczne lub prób wyłudzenia danych związanych z aktywami cyfrowymi. W ekosystemie kryptowalut sam fakt posiadania urządzenia do cold storage może zostać potraktowany jako sygnał, że ofiara przechowuje wartościowe środki.

Z perspektywy organizacyjnej incydent zwiększa także ryzyko reputacyjne, kontraktowe i regulacyjne. Jeżeli partner nie wywiązał się z ustaleń dotyczących retencji danych, rodzi to pytania o skuteczność audytów, egzekwowanie wymagań bezpieczeństwa oraz zgodność z zasadą minimalizacji danych.

Rekomendacje

Osoby, których dane mogły zostać objęte incydentem, powinny przyjąć, że wzrośnie liczba prób phishingu i innych form oszustw. Szczególną ostrożność należy zachować wobec wiadomości e-mail, SMS-ów, połączeń telefonicznych oraz korespondencji, które odnoszą się do zamówienia, dostawy lub rzekomej weryfikacji portfela.

Nie należy nigdy ujawniać seed phrase ani kluczy prywatnych.
Warto weryfikować każdą wiadomość dotyczącą dostawy, zwrotu lub wsparcia technicznego.
Należy zachować ostrożność wobec kontaktów telefonicznych podszywających się pod support lub firmę kurierską.
Dobrym krokiem jest wzmocnienie zabezpieczeń kont pocztowych i powiązanych usług, w tym stosowanie MFA.

Po stronie firm kluczowe znaczenie ma zaostrzenie kontroli nad dostawcami. Organizacje powinny wymagać technicznego potwierdzania retencji danych, regularnych audytów, testów zgodności oraz weryfikacji środowisk pomocniczych, takich jak systemy analityczne, kopie zapasowe czy narzędzia raportowe.

W przypadku usług obsługujących produkty o podwyższonym profilu ryzyka warto rozważyć krótszą retencję, szerszą anonimizację, segmentację danych klientów oraz ograniczanie liczby podmiotów mających dostęp do pełnych danych identyfikacyjnych i adresowych.

Podsumowanie

Incydent związany z Trezorem i ShipMonk pokazuje, że bezpieczeństwo organizacji jest tak silne, jak bezpieczeństwo jej partnerów. Nawet bez naruszenia samego produktu wyciek danych zamówień może prowadzić do realnych zagrożeń dla klientów, w tym phishingu, oszustw ukierunkowanych i zwiększonego ryzyka fizycznego.

Najważniejszy wniosek z tej sprawy dotyczy konieczności praktycznej, a nie wyłącznie formalnej, kontroli nad retencją danych u dostawców zewnętrznych. Systemy logistyczne i analityczne powinny być traktowane jako pełnoprawna część powierzchni ataku i podlegać równie rygorystycznym kontrolom jak kluczowa infrastruktura biznesowa.