Kolejny wyciek danych medycznych w Polsce. Atak na system Medyc przez SQL Injection
System Medyc padł ofiarą ataku wykorzystującego SQL injection. W jednym z potwierdzonych przypadków wyciekły dane identyfikacyjne pacjentów, a analiza wskazuje również na możliwy dostęp do dokumentacji medycznej.
We wrześniu 2026 roku pojawiły się informacje o kolejnym poważnym incydencie dotyczącym danych pacjentów w Polsce. Tym razem chodzi o system Medyc, produkowany przez Qbusoft i wykorzystywany przez placówki medyczne. Z dostępnych komunikatów wynika, że osoba nieuprawniona wykorzystała podatność typu SQL injection w interfejsie aplikacji i wytransferowała archiwum bazy danych poza środowisko dostawcy.
Co dokładnie się wydarzyło?
Według zawiadomienia opublikowanego przez Odwykowo-Psychiatryczny Ośrodek Leczniczy w Inowrocławiu, ustalenia Qbusoft oraz ekspertów prowadzących analizę śledczą wskazują, że atak miał miejsce w dniach 22–23 sierpnia 2026 r. Wykorzystano błąd bezpieczeństwa w interfejsie aplikacji — podatność SQL injection.
Atak został wykryty dopiero w nocy z 8 na 9 września. W tym konkretnym przypadku polecenia eksportu danych nie były ograniczone czasowo, dlatego placówka poinformowała pacjentów, że naruszenie obejmuje dane z okresu od 1 lipca 2024 r. do 23 sierpnia 2026 r.
SQL Injection — jak taki atak może prowadzić do wycieku bazy?
SQL injection to klasa podatności, w której dane przesyłane przez użytkownika mogą zostać potraktowane przez aplikację jako część zapytania do bazy danych. Jeżeli kod nie rozdziela poprawnie danych od instrukcji SQL, napastnik może próbować zmienić logikę zapytania.
Skutki zależą od konstrukcji aplikacji oraz uprawnień konta bazodanowego. Udany atak może umożliwić odczyt danych, a w niektórych konfiguracjach również ich zmianę lub usunięcie. W przypadku Medyc dostępne komunikaty mówią o skutecznym wytransferowaniu archiwum bazy danych.
Jakie dane potwierdzono jako pobrane?
imię i nazwisko
numer PESEL
adres zamieszkania lub pobytu
numer telefonu
adres e-mail
Placówka poinformowała, że imię, nazwisko i PESEL były przechowywane w bazie w formie zaszyfrowanej. Jednocześnie dostawca nakazał przyjąć scenariusz, że ze względu na sposób działania systemu dane te mogły zostać łatwo odszyfrowane i należy traktować je tak, jakby napastnik uzyskał je w postaci jawnej.
A co z dokumentacją medyczną?
Analiza wykazała uruchomienie skryptów skierowanych do tabel z danymi medycznymi. Dostawca wskazał, że bardzo prawdopodobne jest również pozyskanie dokumentacji medycznej, w tym kart informacyjnych leczenia szpitalnego — czyli wypisów.
Dlaczego dane medyczne są tak groźne w rękach przestępców?
Hasło można zmienić. Kartę płatniczą można zastrzec. Historii leczenia, diagnoz, terapii czy informacji o pobycie w określonej placówce nie da się jednak „wymienić”. Właśnie dlatego dane dotyczące zdrowia należą do szczególnych kategorii danych osobowych.
kradzież tożsamości i próby wyłudzeń finansowych
precyzyjny phishing wykorzystujący prawdziwe informacje o pacjencie
podszywanie się pod placówkę medyczną, lekarza, laboratorium albo ubezpieczyciela
próby uzyskiwania informacji w innych placówkach na podstawie PESEL i danych identyfikacyjnych
naruszenie prywatności i dóbr osobistych
wykorzystanie informacji o stanie zdrowia do szantażu lub manipulacji
oszustwa polegające na oferowaniu fikcyjnych usług, badań lub terapii
Najgroźniejszy może być phishing, który wygląda jak prawdziwy
Po wycieku napastnik nie musi pisać ogólnej wiadomości „Twoje konto jest zagrożone”. Może znać imię i nazwisko, numer telefonu, placówkę, w której pacjent się leczył, a potencjalnie także część informacji medycznych. Dzięki temu oszustwo może wyglądać znacznie bardziej wiarygodnie.
Przykładowy scenariusz to telefon od osoby podszywającej się pod rejestrację lub lekarza, która zna nazwę placówki i powołuje się na prawdziwą historię leczenia. Następnie prosi o dopłatę, kod BLIK, dane karty albo logowanie przez przesłany link. To scenariusz ryzyka — nie informacja, że właśnie tak wykorzystano dane z tego incydentu.
Co zrobił dostawca po wykryciu ataku?
usunął podatność SQL injection tego samego dnia, w którym wykryto incydent
odciął dostęp sprawcy
wdrożył dodatkowe zabezpieczenia techniczne
ograniczył uprawnienia bazodanowe
przeprowadził wymuszoną rotację haseł i sekretów technicznych
objął infrastrukturę stałym nadzorem i monitoringiem
przekazał materiały dowodowe Policji
zgłosił incydent do UODO
Z komunikatu placówki wynika, że Qbusoft zgłosił sprawę do Wydziału Walki z Cyberprzestępczością Policji 9 września oraz do UODO 10 września. Sama placówka, jako administrator danych swoich pacjentów, również dokonała zgłoszenia naruszenia do Prezesa UODO.
To kolejny duży alarm dla polskiej ochrony zdrowia
Ten incydent pojawia się zaledwie kilka tygodni po szeroko opisywanym cyberataku na MyDr. W sierpniu Ministerstwo Cyfryzacji informowało, że w przypadku MyDr nieuprawniony dostęp mógł dotyczyć danych historycznych nawet 18,8 mln osób i ponad 12 tys. placówek medycznych.
Medyc i MyDr to dwa odrębne incydenty i nie należy ich łączyć technicznie ani przypisywać im tego samego wektora ataku. Łączy je natomiast jeden problem systemowy: placówki medyczne powierzają ogromne ilości szczególnie wrażliwych danych zewnętrznym systemom, a bezpieczeństwo jednego dostawcy może wpływać na wielu administratorów danych i ich pacjentów.
Co powinien zrobić pacjent, którego dane mogły wyciec?
Zastrzec numer PESEL w mObywatelu, serwisie gov.pl albo urzędzie gminy.
Zachować szczególną ostrożność wobec telefonów, SMS-ów i e-maili powołujących się na leczenie lub konkretną placówkę.
Nie podawać kodów BLIK, haseł, danych karty ani kodów jednorazowych osobom kontaktującym się niespodziewanie.
Samodzielnie znaleźć numer telefonu do placówki i zweryfikować wiadomość niezależnym kanałem.
Monitorować rachunki, powiadomienia bankowe i próby logowania do kont.
W przypadku podejrzenia wykorzystania danych zgłosić sprawę Policji i odpowiedniej instytucji.
Co ten incydent oznacza dla firm i instytucji?
Najważniejsza lekcja nie dotyczy wyłącznie branży medycznej. Firma może mieć aktualne komputery, antywirusa i poprawnie skonfigurowaną sieć, a mimo to ponosić ryzyko wynikające z oprogramowania dostawcy. Bezpieczeństwo łańcucha dostaw IT staje się elementem bezpieczeństwa całej organizacji.
Trzeba wiedzieć, jakie dane trafiają do zewnętrznych aplikacji i kto jest ich dostawcą.
Warto wymagać informacji o aktualizacjach, testach bezpieczeństwa i procedurach reagowania na incydenty.
Konta bazodanowe i aplikacyjne powinny mieć minimalne niezbędne uprawnienia.
Sekrety, hasła techniczne i tokeny powinny podlegać rotacji i bezpiecznemu przechowywaniu.
Logi i monitoring powinny pozwalać wykrywać nietypowe eksporty danych oraz anomalie.
SQL injection w 2026 roku — stary problem, nadal bardzo groźny
SQL injection jest znany od dekad, ale jego konsekwencje nadal mogą być katastrofalne. Nowoczesny framework czy chmurowa infrastruktura nie eliminują ryzyka, jeśli w którymś miejscu aplikacja nieprawidłowo buduje zapytania do bazy albo konto bazy ma zbyt szerokie uprawnienia.
Co powinny zrobić placówki korzystające z systemu Medyc?
ustalić, czy konkretna instancja lub dane placówki były objęte incydentem
zabezpieczyć korespondencję i informacje techniczne od dostawcy
przeanalizować zakres danych oraz ryzyko dla pacjentów
zweryfikować obowiązki wynikające z art. 33 i 34 RODO wraz z IOD
przekazać pacjentom konkretne zalecenia adekwatne do ujawnionych danych
sprawdzić własne mechanizmy uwierzytelniania pacjentów i nie opierać ich wyłącznie na PESEL
Medyc + MyDr: wspólny wniosek dla organizacji
Dwa głośne incydenty w krótkim czasie pokazują, że cyberbezpieczeństwo nie kończy się na firewallu w siedzibie firmy. Trzeba patrzeć na całość: komputery, serwery, konta użytkowników, aplikacje, dostawców SaaS, kopie zapasowe, uprawnienia oraz dane powierzane podmiotom zewnętrznym.
