Wyciek danych gości polskich hoteli: lekcja z ataku na Hotres

Na początku lipca 2026 roku wyszło na jaw, że z systemu rezerwacyjnego Hotres — używanego przez ponad dwa tysiące polskich hoteli i obiektów noclegowych — wyciekły dane gości. Sam obiekt, w którym spędziłeś weekend, nie musiał niczego zawinić: zawiódł dostawca oprogramowania, z którego korzystał. To jeden z najczęstszych i najbardziej niedocenianych scenariuszy: nie włamano się do „Twojego” hotelu, tylko do wspólnego systemu, któremu zaufały tysiące hoteli naraz.

Co się stało i jakie dane wyciekły

Według doniesień (m.in. Niebezpiecznika) atakujący wykorzystał SQL injection — jedną z najstarszych i najlepiej udokumentowanych klas podatności aplikacji webowych. Co istotne, atak został przeprowadzony z konta zalogowanego użytkownika: napastnik nie musiał łamać logowania, wystarczyło mu legalne wejście do panelu, przez które wstrzyknął złośliwe zapytanie do bazy.

Zakres wyciekłych danych obejmował m.in.:

imię i nazwisko gościa,
adres e-mail,
numer telefonu,
terminy pobytu,
koszt rezerwacji.

Dokładna liczba rekordów pozostaje nieznana, ale skala systemu (ponad 2000 obiektów) sugeruje, że mówimy o danych bardzo wielu osób. To nie są dane „wrażliwe” w rozumieniu numerów kart czy dokumentów — ale w rękach oszusta stanowią gotowy scenariusz do ataku, o czym za chwilę.

Na czym polega SQL injection — bez żargonu

Aplikacja webowa rozmawia z bazą danych, wysyłając do niej zapytania. SQL injection to sytuacja, w której dane wpisane przez użytkownika zostają potraktowane nie jak dane, lecz jak część polecenia dla bazy. Zamiast szukać rezerwacji o numerze, który podał użytkownik, baza wykonuje dodatkową instrukcję, którą napastnik przemycił w tym polu — na przykład „wypisz mi wszystkie rezerwacje wszystkich hoteli”.

Obrona jest znana od dwóch dekad i sprowadza się do jednej zasady: nigdy nie skleja się zapytania z tekstu od użytkownika. Używa się tzw. zapytań parametryzowanych, w których dane i polecenie są ściśle rozdzielone. To podstawa, której uczą na pierwszych zajęciach z bezpieczeństwa aplikacji — dlatego SQL injection w produkcyjnym systemie w 2026 roku jest wpadką szczególnie bolesną. Injection od lat znajduje się w czołówce OWASP Top 10.

Dlaczego „atak z zalogowanego konta” to nie okoliczność łagodząca

W komunikatach po takich incydentach często pada argument: „system był dobrze zabezpieczony, a atak przyszedł z konta zalogowanego użytkownika”. To brzmi jak wyjaśnienie, a jest opisem drugiego błędu.

Fundamentalna zasada bezpieczeństwa aplikacji brzmi: każde wejście jest niezaufane — także od zalogowanego użytkownika. Uwierzytelnienie mówi tylko „wiem, kim jesteś”, a nie „ufam wszystkiemu, co wysyłasz”. Zalogowany użytkownik może być złośliwy, może mieć przejęte konto, może testować granice systemu. Jeśli dane z jego formularzy trafiają wprost do zapytań SQL, to nie kwestia „czy”, tylko „kiedy” ktoś to wykorzysta.

W systemie wielodostępnym (multi-tenant), gdzie w jednej bazie siedzą dane tysięcy hoteli, dochodzi trzeci wymiar: izolacja najemców. Zalogowany użytkownik jednego hotelu nigdy nie powinien być w stanie — nawet przez podatność — sięgnąć po dane innego hotelu. Skala wycieku sugeruje, że ta granica została przekroczona. To najgroźniejszy typ błędu w SaaS: pojedyncza luka wystawia dane wszystkich klientów naraz.

To był wyciek u dostawcy, nie w hotelu — czyli ryzyko trzeciej strony

Z perspektywy pojedynczego hotelu to jest właśnie klasyczne ryzyko dostawcy (third-party risk). Hotel powierzył dane swoich gości zewnętrznemu systemowi i to ten system zawiódł — a odpowiedzialność (również wobec RODO i gości) spada również na hotel jako administratora danych.

Dlatego wybór dostawcy oprogramowania to decyzja bezpieczeństwa, nie tylko cenowa. Minimum należytej staranności to zapytanie potencjalnego dostawcy o:

wyniki niezależnych testów penetracyjnych aplikacji i częstotliwość ich przeprowadzania,
sposób izolacji danych między klientami w architekturze wielodostępnej,
procedurę zgłaszania naruszeń i czas reakcji,
zgodność z RODO i zapisy umowy powierzenia danych.

Więcej o tym, jak systematycznie oceniać dostawców, piszemy w artykule o zarządzaniu ryzykiem dostawców (TPRM).

Jeśli jesteś gościem, którego dane mogły wyciec

Same imię, e-mail, telefon i termin pobytu nie pozwolą nikomu „wyczyścić konta”. Niebezpieczne staje się dopiero połączenie tych danych w wiarygodny scenariusz — a to jest gotowy materiał na phishing i vishing „szyty na miarę”:

Uważaj na wiadomości „w sprawie Twojej rezerwacji”. Oszust, który zna Twoje nazwisko, hotel i daty pobytu, może wysłać SMS lub e-mail o „konieczności dopłaty” albo „potwierdzeniu karty” — i zabrzmi to wiarygodnie. Prawdziwy hotel nie prosi o dane karty w linku z SMS-a. Jak rozpoznawać takie próby, opisujemy w poradniku o phishingu.
Weryfikuj niezależnym kanałem. Masz wątpliwości co do wiadomości? Zadzwoń do hotelu na numer z jego oficjalnej strony, nie na ten z podejrzanej wiadomości.
Nie płać „dopłat” z linku. Żadna legalna rezerwacja nie wymaga nagłej dopłaty przez link przysłany SMS-em czy mailem.
Sprawdź, gdzie krążą Twoje dane. Warto skorzystać z serwisów monitorujących wycieki — jak to zrobić, tłumaczymy w Czy moje dane wyciekły?.

Dobrą praktyką na przyszłość jest też podawanie przy rezerwacji minimum danych i, jeśli to możliwe, osobnego adresu e-mail do rezerwacji — dzięki temu ewentualny wyciek łatwiej namierzyć i ograniczyć.

Jeśli prowadzisz hotel albo tworzysz taki system

Dla obiektów: potraktujcie to jako sygnał do przeglądu, komu i jak powierzacie dane gości, oraz do przygotowania planu reagowania na incydent — bo obowiązki wobec UODO (zgłoszenie naruszenia zwykle w 72 godziny) i wobec gości spoczywają również na Was.

Dla twórców oprogramowania rezerwacyjnego i każdego SaaS przetwarzającego dane osobowe lekcja jest twarda:

Zapytania parametryzowane, bez wyjątków. SQL injection jest w 2026 roku w pełni rozwiązanym problemem — jego obecność świadczy o braku podstaw, nie o wyrafinowaniu atakującego.
Każde wejście niezaufane, także od zalogowanych. Walidacja i autoryzacja muszą działać na poziomie każdego zapytania.
Twarda izolacja najemców. Użytkownik jednego klienta nie może technicznie dosięgnąć danych innego — to trzeba testować, nie zakładać.
Regularny test penetracyjny. Pasywny skaner konfiguracji nie wykryje SQL injection — to podatność w logice aplikacji, którą znajduje dopiero manualny test penetracyjny. Gdyby taki test przeprowadzono, ta luka niemal na pewno zostałaby wychwycona przed atakującym. O różnicy między skanem a pentestem pisaliśmy w osobnym artykule.
RODO to też środki techniczne. Zgodność nie kończy się na polityce prywatności — obejmuje faktyczne techniczne środki ochrony danych.

Podsumowanie

Wyciek z Hotres to podręcznikowy przykład dwóch prawd naraz. Dla gościa: Twoje dane rzadko wyciekają tam, gdzie je zostawiłeś — częściej u dostawcy, o którym nawet nie wiesz, więc czujność wobec „wiadomości w sprawie rezerwacji” jest dziś obowiązkowa. Dla firmy: najgroźniejsze wycieki nie wynikają z genialnych ataków, lecz z braku podstaw — parametryzacji zapytań, izolacji danych i regularnych testów. SQL injection w 2026 roku nie jest pechem. Jest znaleziskiem, które dobry test penetracyjny wyłapuje, zanim zrobi to ktoś inny.

Jeśli prowadzisz system przetwarzający dane klientów i chcesz sprawdzić go, zanim zrobi to napastnik, skontaktuj się z nami — testy penetracyjne aplikacji to jedna z naszych podstawowych usług.

Najczęstsze pytania (FAQ)

Czy jeśli nocowałem w hotelu korzystającym z Hotres, moje dane na pewno wyciekły? Niekoniecznie — dokładny zakres wycieku i lista dotkniętych obiektów nie są w pełni jawne. Bezpieczniej jednak założyć, że mogły, i zachować wzmożoną czujność wobec wiadomości powołujących się na Twoją rezerwację. Warto też sprawdzić swój adres e-mail w serwisach monitorujących wycieki.

Wyciekły tylko imię, e-mail i telefon — czy to naprawdę groźne? To zależy od kontekstu. Same w sobie te dane nie pozwolą przejąć konta bankowego, ale w połączeniu z wiedzą o Twoim pobycie stają się paliwem do bardzo wiarygodnego phishingu „w sprawie rezerwacji”. Największym realnym ryzykiem po tym wycieku są właśnie ukierunkowane oszustwa, nie bezpośrednia kradzież pieniędzy.

Czy hotel odpowiada za wyciek, skoro to wina systemu zewnętrznego? W świetle RODO hotel jako administrator danych ponosi współodpowiedzialność za to, komu je powierza i na jakich zasadach. Wybór dostawcy oprogramowania jest więc również decyzją dotyczącą bezpieczeństwa i zgodności — a należyta staranność obejmuje weryfikację, czy dostawca testuje swoje aplikacje.

Dlaczego skaner bezpieczeństwa nie wykrył tej podatności? Bo pasywny skaner sprawdza konfigurację (HTTPS, nagłówki, ekspozycję), a nie logikę aplikacji. SQL injection tkwi w sposobie, w jaki aplikacja buduje zapytania do bazy — to znajduje dopiero manualny test penetracyjny, który aktywnie próbuje wstrzyknąć złośliwe dane w kontrolowany sposób.

Źródła i dalsza lektura: Niebezpiecznik, Sekurak, CERT Polska, Hotres — zalecenia bezpieczeństwa.