Wprowadzenie do problemu / definicja luki
ManoMano (europejska platforma e-commerce z segmentu DIY/dom i ogród) znalazła się w centrum głośnego incydentu bezpieczeństwa, w którym napastnicy mieli pozyskać dane osobowe klientów poprzez kompromitację portalu wsparcia (support). najważniejsze jest to, iż według dostępnych informacji nie doszło do „klasycznego” włamania na główną infrastrukturę sklepu, ale do incydentu w łańcuchu dostaw – po stronie zewnętrznego dostawcy obsługi klienta i używanego narzędzia ticketowego.
W skrócie
- Skala: napastnik twierdzi, iż dotyczy to ok. 37,8 mln rekordów / osób; w publikacjach mówi się o „prawie 38 mln”.
- Kiedy wykryto: ManoMano miało ustalić incydent w styczniu 2026.
- Wektor: kompromitacja dostawcy obsługi klienta (podwykonawcy), z wykorzystaniem dostępu do systemu typu Zendesk.
- Jakie dane: m.in. imię i nazwisko, adres e-mail, numer telefonu oraz treści/metadata zgłoszeń do supportu (w tym komunikacja z obsługą).
- Czego (prawdopodobnie) nie było: w cytowanych stanowiskach podkreślano, iż hasła kont nie zostały ujawnione (lub nie były dostępne w skompromitowanym obszarze).
Kontekst / historia / powiązania
Ten przypadek dobrze pokazuje, dlaczego zespoły bezpieczeństwa coraz częściej traktują systemy obsługi klienta (CRM/ticketing) jako krytyczną powierzchnię ataku:
- W ticketach często znajduje się „miękka” wrażliwa treść (adresy, zamówienia, reklamacje, czasem załączniki), która jest bardzo użyteczna w oszustwach.
- Dostęp do narzędzia wsparcia bywa delegowany na podwykonawców (call center, BPO), co mnoży punkty wejścia, konta, role i ryzyka operacyjne.
- Atakujący nie muszą łamać dobrze bronionej infrastruktury e-commerce – wystarczy przejąć konto agenta lub integrację po stronie dostawcy.
Analiza techniczna / szczegóły luki
Z publicznych doniesień wynika następujący (prawdopodobny) łańcuch zdarzeń:
- Kompromitacja podwykonawcy obsługującego wsparcie klienta (w części publikacji wskazywano lokalizację dostawcy w Tunezji).
- Wejście przez konto w Zendesk / portalu supportowym, które miało uprawnienia do przeglądania danych klientów i historii kontaktu.
- Eksfiltracja danych: dane identyfikacyjne (PII) oraz treści korespondencji i informacje związane z obsługą posprzedażową.
- Sprawca, występujący pod aliasem „Indra”, miał opublikować twierdzenia o skali wycieku na forum przestępczym.
Warto zauważyć istotny niuans: choćby jeżeli hasła nie wyciekły, to zestaw (imię+nazwisko+e-mail+telefon+historia ticketów) jest „paliwem” do ataków socjotechnicznych, bo pozwala tworzyć wysoce wiarygodne scenariusze podszycia.
Praktyczne konsekwencje / ryzyko
Najbardziej realne skutki dla klientów (i firm podszywających się pod ManoMano) to:
- Phishing e-mail: wiadomości „o dopłacie do przesyłki”, „zwrocie”, „weryfikacji konta”, z linkiem do fałszywej bramki logowania lub płatności.
- Vishing / smishing: telefon/SMS, bo numer telefonu ma wysoką wartość w oszustwach „na konsultanta”, „na kuriera”, „na bank”.
- Ataki ukierunkowane na podstawie treści zgłoszeń: jeżeli ktoś pisał do supportu o konkretnym zamówieniu/produkcie, przestępcy mogą to wykorzystać, by „udowodnić autentyczność”.
- Ryzyko wtórne (credential stuffing) poza ManoMano: choćby bez haseł, część ofiar kliknie w link i sama poda dane logowania, albo zainstaluje złośliwą aplikację „do śledzenia przesyłki”.
Rekomendacje operacyjne / co zrobić teraz
Dla klientów (działania natychmiastowe)
- Załóż, iż ktoś może podszywać się pod ManoMano: nie klikaj w linki z wiadomości o „weryfikacji” czy „dopłacie”. Wejdź na stronę/apkę manualnie.
- Włącz MFA wszędzie, gdzie się da (e-mail, bank, marketplace’y). To najtańszy „bezpiecznik” na skutki phishingu.
- Uważaj na rozmowy telefoniczne: jeżeli ktoś dzwoni „z obsługi”, rozłącz się i oddzwoń numerem z oficjalnej strony/aplikacji (nie z treści SMS/e-mail).
- Jeśli używasz tego samego hasła w wielu miejscach: zmień je (szczególnie do poczty). choćby jeżeli w tym incydencie hasła nie wyciekły, to poczta jest kluczem do resetów.
Dla organizacji (checklista po stronie bezpieczeństwa)
- Zarządzanie dostawcami (TPRM): oceń model dostępu podwykonawcy do ticketów (zasada najmniejszych uprawnień, segmentacja ról, JIT/JEA).
- Twarde MFA + polityki dostępu dla kont agentów: wymuszenie MFA, ograniczenia geograficzne/IP, wykrywanie niemożliwych podróży, blokady po anomaliach.
- Monitoring i alertowanie na masowy eksport/odczyt: ticketing powinien mieć reguły na nietypowe wolumeny wyszukiwań, pobrań i eksportów.
- Redukcja danych w ticketach: maskowanie PII w treści, automatyczne usuwanie/retencja, zakaz przesyłania wrażliwych dokumentów jako załączników (lub DLP).
- Playbook na incydenty w SaaS: procedury dla Zendesk/CRM (revocation tokens, rotacja kluczy integracji, przegląd OAuth, szybkie odcięcie dostępu dostawcy).
W doniesieniach podkreślano, iż ManoMano miało po wykryciu incydentu odebrać dostęp podwykonawcy i wzmocnić kontrolę dostępu/monitoring oraz powiadomić odpowiednie organy.
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
W porównaniu do wycieków „z bazy użytkowników” (gdzie często pojawiają się hashe haseł), tu sedno jest inne: to incydent w kanale wsparcia, który może nie zawierać haseł, ale zawiera kontekst. Dla przestępców kontekst = wiarygodność, a wiarygodność = wyższa skuteczność phishingu/vishingu.
To także klasyczny wzorzec „third-party breach”: organizacja może mieć solidne zabezpieczenia w core, ale „wejście bokiem” przez dostawcę daje dostęp do danych wrażliwych operacyjnie.
Podsumowanie / najważniejsze wnioski
- Incydent ManoMano (ujawniony publicznie pod koniec lutego 2026) to przykład, iż systemy obsługi klienta i podwykonawcy są dziś jednym z najczęstszych „skrótów” do danych klientów.
- Nawet przy braku haseł, zestaw PII + historia zgłoszeń to wysokie ryzyko socjotechniki (phishing, vishing, oszustwa płatnicze).
- Priorytety defensywne: MFA wszędzie, monitoring anomalii w SaaS/ticketingu, ograniczenie uprawnień i danych widocznych dla dostawców, oraz dojrzałe TPRM.
Źródła / bibliografia
- SecurityWeek – „38 Million Allegedly Impacted by ManoMano Data Breach” (27 lutego 2026). (SecurityWeek)
- BleepingComputer – „European DIY chain ManoMano data breach impacts 38 million customers” (26 lutego 2026). (BleepingComputer)
- TechRadar (Pro) – opis incydentu i kontekst third-party/Zendesk (27 lutego 2026). (TechRadar)
- The Register – dodatkowe szczegóły dot. skali i artefaktów wycieku (27 lutego 2026). (The Register)
- SC Media / SC World – krótkie podsumowanie: zakres danych i wektor third-party (27 lutego 2026). (SC Media)
