The Hotres Breach: When Your Vendor Falls, GDPR Knocks on the Hotel's Door

Wiadomość na WhatsAppie, która wie za dużo

Początek lipca, środek sezonu rezerwacyjnego. Gość, który kilka dni wcześniej zarezerwował pokój w pensjonacie nad morzem, dostaje na WhatsAppie wiadomość: potwierdzenie rezerwacji z prawidłową datą pobytu, prawidłową kwotą i prośbą o dopłatę przez załączony link — „w celu gwarancji rezerwacji". Nazwa obiektu się zgadza, termin się zgadza, kwota się zgadza. Nie zgadza się tylko jedno: nadawcą nie jest hotel, lecz przestępca, który te dane po prostu ma.

W poniedziałek 29 czerwca 2026 r. firma Hotres — dostawca popularnego systemu rezerwacyjnego, z którego korzysta ponad 2000 hoteli, pensjonatów, hosteli i apartamentów w Polsce i poza nią — wykryła masowy, prowadzony z wielu adresów IP atak na swoją infrastrukturę. Napastnicy uzyskali dostęp do danych rezerwacyjnych gości. 3 lipca sprawę opisał Niebezpiecznik, publikując komunikaty, które Hotres rozesłał do obsługiwanych obiektów. Od tego czasu do gości hotelowych — od schronisk w Tatrach po apartamenty rezerwowane przez Booking.com, także w obiektach poza Polską — płyną wiadomości SMS i WhatsApp z dokładnymi danymi ich pobytów oraz linkami do fałszywych bramek płatności.

Ta historia ma dwie warstwy. Pierwsza jest techniczna i momentami trudna do skomentowania bez ironii. Druga jest prawna — i to ona powinna dziś spędzać sen z powiek właścicielom obiektów noclegowych, bo w świetle RODO to nie Hotres jest głównym adresatem obowiązków po tym incydencie. Są nim hotele.

Co wiemy o ataku: SQL injection w roku 2026

Według uzupełniającego komunikatu, który Hotres rozesłał do swoich klientów, do kradzieży danych doszło metodą SQL injection — a więc techniką, która figuruje w każdym podręczniku bezpieczeństwa aplikacji od ćwierć wieku i której zapobieganie jest kanonem inżynierii oprogramowania, nie wyższą magią. Firma zastrzegła przy tym, że jej system jest „dobrze zabezpieczony przed atakami", a atak nastąpił „z poziomu konta zalogowanego użytkownika". Zestawienie tych dwóch zdań pozostawiamy bez komentarza — odnotujmy jedynie, że wstrzyknięcie SQL wykonane z poziomu uwierzytelnionego konta pozostaje wstrzyknięciem SQL, a granica uprawnień zalogowanego użytkownika istnieje właśnie po to, żeby jej nie dało się obejść zapytaniem do bazy.

Zakres wykradzionych danych obejmuje imię i nazwisko, adres e-mail, numer telefonu, daty pobytu oraz kwotę rezerwacji. Według relacji medialnych napastnik zdążył odczytać około dwóch tysięcy rezerwacji, głównie letnich pobytów przypadających na lipiec i sierpień — choć pełna skala nie została publicznie potwierdzona, a sama firma w pierwszym komunikacie pisała o naruszeniu „o nieznanej skali". Dla oceny ryzyka to rozróżnienie ma znaczenie drugorzędne: zestaw danych wystarczający do przekonującej personalizacji oszustwa wyciekł i jest aktywnie wykorzystywany.

Smaczków technicznych jest więcej. Czytelnicy Niebezpiecznika szybko wskazali opublikowaną przez Hotres instrukcję bezpieczeństwa, która zawiera listę słów zabronionych w hasłach użytkowników — zabieg, który ma sens głównie wtedy, gdy hasło w postaci jawnej trafia do sklejanego ręcznie zapytania SQL, czyli dokładnie tam, gdzie trafiać nie powinno. Do tego uwierzytelnianie dwuskładnikowe działające wyłącznie w wybranych przeglądarkach desktopowych. Każdy z tych elementów z osobna można wytłumaczyć; razem układają się w obraz systemu, którego architektura bezpieczeństwa nie dorosła do roli, jaką system pełni — centralnego repozytorium danych osobowych gości dwóch tysięcy obiektów.

Drugie uderzenie: oszuści są szybsi niż komunikaty

Podobnie jak przy opisywanym przez nas ataku na Nową Rudę, właściwa szkoda nie kończy się na samym włamaniu. Wykradzione dane niemal natychmiast poszły w ruch. Goście otrzymują wiadomości podszywające się pod obiekty, w których faktycznie mają rezerwacje: z prośbą o „dopłatę", o „weryfikację karty płatniczej", o „potwierdzenie, że rezerwacji nie złożył bot". Scenariusze są dopracowane, bo przestępca zna nazwę obiektu, termin i kwotę — czyli dokładnie te szczegóły, którymi prawdziwy hotel uwiarygodniłby swój kontakt.

To modelowy przykład zjawiska, które w analizach incydentów nazywa się drugim uderzeniem: monetyzacją wycieku poprzez ataki socjotechniczne na osoby, których dane wyciekły. W szczycie sezanu urlopowego skuteczność takich wiadomości jest wyższa niż zwykle — ludzie czekają na kontakt od hotelu, spodziewają się płatności i działają w pośpiechu. Z perspektywy oceny ryzyka naruszenia, do której zaraz przejdziemy, ma to znaczenie fundamentalne: nie rozważamy tu hipotetycznej możliwości nadużycia danych, tylko obserwujemy nadużycie w toku. Pieniądze realnie znikają z kont gości.

Warto odnotować i to, że fałszywe wiadomości docierają również do osób, które rezerwowały przez pośredników pokroju Booking.com — bo system rezerwacyjny obiektu, zintegrowany z kanałami sprzedaży, przetwarza dane gościa niezależnie od tego, którędy rezerwacja wpłynęła. Gość nie ma pojęcia, że jego dane w ogóle przeszły przez Hotres. I tu dochodzimy do sedna.

Hotel jest administratorem, Hotres procesorem — i to zmienia wszystko

W terminologii RODO role są rozdzielone jednoznacznie. Administratorem danych gości jest obiekt noclegowy — to hotel decyduje o celach i sposobach przetwarzania: przyjmuje rezerwację, realizuje umowę pobytu, rozlicza płatność. Hotres jest podmiotem przetwarzającym (art. 4 pkt 8 RODO), czyli procesorem: przetwarza dane wyłącznie w imieniu i na zlecenie hoteli, na podstawie umowy powierzenia z art. 28 RODO. Ten podział nie jest akademicki — od niego zależy, kto po incydencie ma jakie obowiązki i kto poniesie odpowiedzialność za ich zaniedbanie.

Obowiązki procesora po naruszeniu reguluje art. 33 ust. 2 RODO i jest on zwięzły: podmiot przetwarzający po stwierdzeniu naruszenia ochrony danych osobowych bez zbędnej zwłoki zgłasza je administratorowi. Kropka. Procesor nie zgłasza naruszenia do Prezesa UODO — nie jest stroną tego postępowania, chyba że sam występuje w roli administratora danych (np. własnych pracowników czy kont użytkowników systemu). Cała reszta machiny uruchamia się po stronie administratora, czyli każdego z dwóch tysięcy obiektów z osobna: ocena ryzyka naruszenia, zgłoszenie do organu nadzorczego w 72 godziny (art. 33 ust. 1), zawiadomienie osób, których dane dotyczą, jeżeli ryzyko dla ich praw i wolności jest wysokie (art. 34), wpis do wewnętrznej dokumentacji naruszeń (art. 33 ust. 5).

Dla właściciela pensjonatu, który system rezerwacyjny kupił lata temu jako usługę „z pudełka" i nigdy nie zaprzątał sobie głowy różnicą między administratorem a procesorem, oznacza to przebudzenie w nowej rzeczywistości: naruszenie wydarzyło się u dostawcy, ale postępowanie przed Prezesem UODO — jeśli do niego dojdzie — będzie się toczyć przeciwko niemu. Dokładnie na tej konstrukcji opiera się zresztą kara 11 mln zł dla DPD Polska, o której pisaliśmy na początku czerwca: administrator odpowiada za to, komu i jak powierzył dane, a parasol „to wina podwykonawcy" nie otwiera się nigdy.

Komunikat Hotres pod lupą: trzy zdania, trzy problemy

Komunikat, który Hotres rozesłał do obiektów, zawiera fragment, który warto przytoczyć w całości, bo na szkoleniach z RODO takie cytaty są bezcenne: „Przypominamy, że jako Administrator Danych mają Państwo obowiązek ocenić ryzyko dla praw i wolności osób, których dane dotyczą. Jeżeli nie otrzymaliście informacji od gości hotelowych o podejrzanych wiadomościach, to można domniemywać, że incydent was nie dotyczy. W przypadku stwierdzenia naruszenia należy to zgłosić do Prezesa Urzędu Ochrony Danych Osobowych (UODO) w ciągu 72 godzin od momentu otrzymania niniejszej wiadomości."

Zdanie pierwsze jest prawidłowe — i to jedyna w pełni bezpieczna część tego akapitu. Zdanie drugie jest prawnie nie do obrony. RODO nie zna konstrukcji domniemania braku naruszenia z powodu braku skarg. Ocena ryzyka musi się opierać na faktach dotyczących samego naruszenia: jakie dane, ilu osób, w czyich rękach, z jakim prawdopodobieństwem nadużycia — a nie na tym, czy poszkodowani zdążyli się już poskarżyć. Brak sygnałów od gości może znaczyć tyle, że przestępcy jeszcze nie przerobili tej partii rekordów albo że goście skargi kierują gdzie indziej. Obiekt, który na podstawie takiego „domniemania" zaniecha oceny i zgłoszenia, w ewentualnym postępowaniu nie obroni się argumentem, że dostawca mu tak doradził.

Zdanie trzecie zawiera błąd subtelniejszy, ale istotny: termin 72 godzin z art. 33 ust. 1 RODO biegnie od stwierdzenia naruszenia przez administratora — czyli od momentu, w którym administrator uzyskał wystarczającą wiedzę, że doszło do naruszenia ochrony danych, którego skutki mogą dotyczyć jego gości — a nie mechanicznie „od otrzymania niniejszej wiadomości". W praktyce dla większości obiektów te momenty będą blisko siebie i liczenie od maila Hotresu jest bezpiecznym uproszczeniem. Problem w tym, że komunikat łączy to uproszczenie z zachętą do domniemania, że problemu nie ma — a wtedy 72 godziny mijają, obiekt nie zgłasza nic, i dopiero skarga gościa, który stracił pieniądze, uruchamia postępowanie z najgorszej możliwej pozycji: naruszenie było, zgłoszenia nie było, a administrator dysponował ostrzeżeniem od procesora na piśmie.

Obowiązki obiektu krok po kroku: 72 godziny, które już biegną

Co zatem powinien zrobić obiekt korzystający z Hotres — i każdy administrator w analogicznej sytuacji? Najpierw ustalić stan faktyczny: zażądać od procesora konkretów, do których ma umowne i ustawowe prawo — jakie tabele danych zostały odczytane, czy dotyczyły rezerwacji tego obiektu, w jakim okresie, ilu rekordów. Art. 28 ust. 3 lit. f RODO zobowiązuje procesora do pomocy administratorowi w wywiązaniu się z obowiązków z art. 32–36, a więc także w zebraniu informacji potrzebnych do oceny i zgłoszenia naruszenia. Odpowiedź „nie wiemy, skala nieznana" nie zwalnia administratora z działania — przeciwnie, niepewność co do skali sama w sobie podwyższa ocenę ryzyka.

Następnie ocenić ryzyko dla praw i wolności gości. Metodyki są dostępne od lat — od ENISA po materiały Prezesa UODO — ale w tym przypadku wynik trudno uznać za dyskusyjny: wyciekły dane identyfikacyjne i kontaktowe powiązane z konkretną transakcją, a przestępcy już prowadzą kampanie wyłudzeń na tych danych. To nie jest ryzyko potencjalne, tylko zmaterializowane. W naszej ocenie w typowym przypadku obiektu, którego rezerwacje odczytano, spełnione są przesłanki i zgłoszenia do Prezesa UODO z art. 33, i zawiadomienia gości z art. 34 — bo wysokie ryzyko strat finansowych po stronie gości jest oczywiste, a szybkie ostrzeżenie realnie ogranicza szkodę. Zgłoszenia dokonuje się elektronicznie, formularz jest dostępny w serwisie UODO, a jeśli 72 godziny nie wystarczą na komplet informacji — RODO wprost dopuszcza zgłoszenie etapami (art. 33 ust. 4).

Jest i trzeci obowiązek, o którym w gorączce incydentu łatwo zapomnieć: dokumentacja. Art. 33 ust. 5 RODO wymaga udokumentowania każdego naruszenia — także takiego, którego po ocenie nie zgłoszono — wraz z okolicznościami, skutkami i podjętymi działaniami. Obiekt, który po analizie uzna, że akurat jego rezerwacji atak nie objął, powinien mieć na piśmie, na jakiej podstawie tak uznał i o co zapytał procesora. To dokładnie ta kartka papieru, która za dwa lata, przy kontroli albo skardze, oddziela staranność od zaniedbania.

Umowa powierzenia: papier, który zaczyna działać dopiero w kryzysie

Incydent tej skali jest też testem jakości umów powierzenia — testem, który branża hotelarska właśnie zdaje publicznie. Art. 28 ust. 3 RODO wymaga, by umowa z procesorem określała m.in. obowiązek zgłaszania naruszeń administratorowi, zakres pomocy przy obowiązkach z art. 32–36, prawo administratora do audytów i inspekcji oraz zasady korzystania z podpowierzenia. W praktyce MŚP umowa powierzenia z dostawcą SaaS to często załącznik do regulaminu, zaakceptowany kliknięciem przy zakładaniu konta i nieczytany nigdy później. Do czasu.

Warto dziś — nie za miesiąc — wyjąć tę umowę i sprawdzić kilka rzeczy. Czy określa maksymalny czas, w jakim procesor musi powiadomić obiekt o naruszeniu, i czy „bez zbędnej zwłoki" doprecyzowano godzinami? Czy zobowiązuje procesora do przekazania informacji wystarczających do oceny ryzyka — zakresu danych, liczby rekordów, wektora ataku? Czy przewiduje wsparcie przy zawiadamianiu osób, których dane dotyczą, i kto ponosi jego koszty? Czy daje realne, a nie iluzoryczne prawo audytu? I wreszcie: czy dostawca w ogóle wykazuje „wystarczające gwarancje wdrożenia odpowiednich środków technicznych i organizacyjnych", jak wymaga art. 28 ust. 1 — bo wybór procesora, który takich gwarancji nie daje, jest samodzielnym naruszeniem po stronie administratora. Orzecznictwo, które omawialiśmy przy wyroku WSA w sprawie Fortum i Piki, nie pozostawia tu złudzeń: administrator, który nie weryfikuje dostawcy i nie egzekwuje umowy, odpowiada obok niego — a często zamiast niego.

Art. 32: co incydent mówi o „odpowiednich środkach"

RODO nie przepisuje konkretnych technologii — art. 32 wymaga środków „odpowiednich" do ryzyka, ocenianych z uwzględnieniem stanu wiedzy technicznej. I właśnie dlatego SQL injection jest dla organu nadzorczego takim wdzięcznym materiałem: ochrona przed nim — zapytania parametryzowane, walidacja danych wejściowych, najmniejsze uprawnienia konta aplikacyjnego w bazie, testy bezpieczeństwa — to stan wiedzy technicznej sprzed dwóch dekad, opisany w OWASP Top 10 od pierwszego wydania. Trudno o czytelniejszy przykład rozminięcia się środków z ryzykiem niż podatność z antologii klasyki w systemie przechowującym dane osobowe gości dwóch tysięcy obiektów.

Dla firm technologicznych — bo Hotres jest przecież jedną z setek polskich firm SaaS obsługujących cudze dane — płynie z tego lekcja szersza niż jedna podatność. Bezpieczny cykl rozwoju oprogramowania, regularne testy penetracyjne, przeglądy kodu pod kątem bezpieczeństwa, monitorowanie anomalii w zapytaniach do bazy (masowy odczyt rezerwacji z wielu adresów IP to sygnatura, którą dojrzały monitoring wyłapuje w minutach, nie dniach) — to wszystko elementy, które norma ISO/IEC 27001:2022 porządkuje w załączniku A, od zabezpieczeń cyklu rozwojowego po zarządzanie podatnościami. Certyfikat nie jest gwarancją nieomylności, ale systematycznie zmniejsza prawdopodobieństwo, że o architekturze bezpieczeństwa systemu dowiemy się z komunikatu o wycieku. A dla klientów takich systemów — hoteli, ale też każdej firmy kupującej SaaS — pytanie o certyfikację, wyniki testów i podejście do bezpieczeństwa aplikacji powinno być stałym elementem zakupów, nie uprzejmością.

Każda organizacja ma swojego Hotresa

Byłoby wygodnie potraktować tę historię jako branżową ciekawostkę z sektora turystyki. Byłoby to też nierozsądne. Praktycznie każda organizacja — MŚP, urząd gminy, spółka komunalna — ma w swoim krajobrazie IT odpowiednik Hotresu: zewnętrzny system SaaS, w którym leżą dane osobowe jej klientów, mieszkańców albo pracowników, a którego bezpieczeństwa nigdy nie zweryfikowała. Systemy dziedzinowe w samorządach, platformy e-usług, systemy HR i kadrowo-płacowe, narzędzia marketingowe z bazami kontaktów, elektroniczne obiegi dokumentów. Koncentracja danych u dostawców rośnie z każdym rokiem — a wraz z nią atrakcyjność tych dostawców jako celu: po co włamywać się do dwóch tysięcy obiektów po kolei, skoro można raz, do ich wspólnego usługodawcy.

Regulator widzi to zjawisko doskonale. W RODO odpowiedzią jest właśnie art. 28 z całym orzecznictwem o odpowiedzialności administratora za wybór i nadzór nad procesorem. W świecie NIS-2 i znowelizowanej ustawy o krajowym systemie cyberbezpieczeństwa odpowiedzią jest bezpieczeństwo łańcucha dostaw jako obowiązkowy element systemu zarządzania — podmioty kluczowe i ważne muszą oceniać i nadzorować swoich dostawców usług ICT, a kierownicy podmiotów odpowiadają za to osobiście. Obie regulacje mówią w gruncie rzeczy to samo: outsourcing przetwarzania nie jest outsourcingiem odpowiedzialności. Można oddać dane, nie można oddać ryzyka.

Wnioski operacyjne są uniwersalne. Po pierwsze, inwentaryzacja: lista dostawców przetwarzających dane osobowe organizacji, z przypisanym zakresem danych i umową powierzenia. Po drugie, weryfikacja: dla dostawców krytycznych — dowody bezpieczeństwa, nie deklaracje. Po trzecie, procedura na wypadek naruszenia u dostawcy: kto w organizacji odbiera takie zawiadomienie, kto ocenia ryzyko, kto podejmuje decyzję o zgłoszeniu i zawiadomieniu osób — z góry, na spokojnie, a nie w 60. godzinie z 72 dostępnych. Po czwarte, minimalizacja: im mniej danych oddajemy dostawcy, tym mniej wycieka, gdy dostawca zawiedzie — o czym pisaliśmy szeroko przy okazji kary dla Glovo za skany dowodów.

Dlaczego z Fib.Code, gdy incydent przychodzi od dostawcy

W Fib.Code obsługujemy organizacje dokładnie na tym styku, na którym pękł Hotres: jako zewnętrzny inspektor ochrony danych i pełnomocnik do spraw bezpieczeństwa informacji prowadzimy rejestry umów powierzenia, weryfikujemy dostawców przed podpisaniem umowy i w trakcie jej trwania, a gdy dochodzi do naruszenia — przeprowadzamy ocenę ryzyka, przygotowujemy zgłoszenie do Prezesa UODO i zawiadomienia osób, których dane dotyczą, w reżimie 72 godzin. Wdrażamy też systemy zarządzania bezpieczeństwem informacji według ISO/IEC 27001 i ISO 22301 — po obu stronach barykady: u organizacji kupujących usługi IT i u dostawców oprogramowania, którzy chcą móc wykazać swoim klientom coś więcej niż zapewnienie, że system jest „dobrze zabezpieczony".

Pracujemy według trzech zasad. Po pierwsze, zaczynamy od stanu faktycznego, nie od szablonu — bo umowa powierzenia skopiowana z internetu chroni tak samo dobrze jak parasol z papieru. Po drugie, wymiarujemy zabezpieczenia i procedury do realnego ryzyka organizacji, żeby budżet szedł tam, gdzie są dane i zagrożenia, a nie tam, gdzie jest moda. Po trzecie, każdy proces kończymy przećwiczeniem go z ludźmi, którzy będą musieli zadziałać w kryzysie — bo procedura zgłaszania naruszeń, której nikt nigdy nie przećwiczył, w 60. godzinie incydentu jest tylko literaturą.

Efekt naszej pracy to organizacja, która wie, komu powierzyła dane i na jakich warunkach, potrafi w kilka godzin ustalić, czy naruszenie u dostawcy jej dotyczy, i ma gotowy, przećwiczony tryb działania na 72 godziny — z dowodami staranności, które można położyć na stole przed organem nadzorczym, ubezpieczycielem i własnym zarządem.

Co zrobić w ten weekend z własnym dostawcą SaaS

Jeżeli prowadzicie obiekt noclegowy korzystający z Hotres — nie czekajcie na poniedziałek. Jeszcze dziś zażądajcie od dostawcy pisemnej informacji, czy odczytane dane obejmują wasze rezerwacje, oceńcie ryzyko i podejmijcie udokumentowaną decyzję w sprawie zgłoszenia do Prezesa UODO oraz zawiadomienia gości; jeżeli od powzięcia wiedzy o naruszeniu minęło już ponad 72 godziny, zgłoście naruszenie mimo to, wyjaśniając przyczynę opóźnienia — spóźnione zgłoszenie jest zawsze lepszą pozycją niż brak zgłoszenia. Uprzedźcie recepcję o fali oszustw i opublikujcie na stronie oraz w kanałach społecznościowych krótkie ostrzeżenie dla gości: hotel nigdy nie prosi o dopłatę ani dane karty linkiem w wiadomości.

Wszystkim pozostałym proponujemy na ten weekend ćwiczenie o wysokiej stopie zwrotu: wybierzcie jednego, najważniejszego dostawcę SaaS przetwarzającego dane waszych klientów i odpowiedzcie sobie na pięć pytań. Gdzie jest umowa powierzenia i co faktycznie mówi o naruszeniach? W jakim czasie dostawca musi was powiadomić? Jakie informacje wtedy dostaniecie i czy wystarczą do oceny ryzyka? Kto u was odbierze takie zawiadomienie w środku sierpnia i co zrobi w pierwszej godzinie? I czy dostawca kiedykolwiek pokazał wam dowód — certyfikat, wynik testu, raport z audytu — że jego deklaracje o bezpieczeństwie mają pokrycie? Jeśli na dwa z pięciu pytań odpowiedź brzmi „nie wiemy", to znaczy, że wasz Hotres jeszcze się nie wydarzył — ale pracuje nad tym.

Zapraszamy do kontaktu: l.grabowski@fibcode.com | fibcode.com/pl/kontakt. Bezpośrednio powiązane materiały: kara 11 mln zł dla DPD — umowy powierzenia i łańcuch podwykonawców, wyrok WSA w sprawie Fortum i Piki — odpowiedzialność za dostawcę IT, ransomware w Nowej Rudzie — drugie uderzenie po incydencie — razem pokazują, jak RODO i KSC rozliczają organizacje z cudzych błędów.