Jedna luka w oprogramowaniu do zarządzania dokumentacją medyczną pacjentów otrzymała ocenę 7.3 w skali CVSS (Common Vulnerability Scoring System — skala 0-10 oceniająca powagę luki) [cve]. Podatność, oznaczona jako CVE-2026-10185 [cve], dotyczy systemu SourceCodester Hospitals Patient Records Management System w wersji 1.0 1. Co istotne, atak może być przeprowadzony zdalnie 2, a kod exploita został upubliczniony 3.

Chociaż sam system nie jest szeroko rozpowszechniony w Polsce, przypadek ten stanowi istotne ostrzeżenie dla mniejszych placówek medycznych i prywatnych praktyk. Używanie niszowego lub darmowego oprogramowania do przetwarzania wrażliwych danych pacjentów, bez uprzedniego audytu bezpieczeństwa, stwarza bezpośrednie ryzyko naruszenia zgodności z RODO (Rozporządzenie o Ochronie Danych Osobowych) i utraty danych.

TL;DR

  • Produkt: SourceCodester Hospitals Patient Records Management System 1.0 1.
  • Wektor: Zdalne wstrzyknięcie SQL (SQL Injection) 4 przez manipulację parametru w żądaniu do aplikacji webowej.
  • Identyfikator: CVE-2026-10185 [cve].
  • Wskaźniki kompromitacji (IoC): Nietypowe żądania HTTP POST kierowane do ścieżki /classes/Users.php?f=save 5.
  • Kogo dotyczy: Bezpośrednio — placówki medyczne używające podatnej wersji systemu. Pośrednio — wszystkie polskie podmioty przetwarzające dane medyczne, jako studium przypadku ryzyka związanego z nieaudytowanym oprogramowaniem.
  • Pierwszy ruch reagowania: Natychmiastowa weryfikacja, czy oprogramowanie jest używane w organizacji. W przypadku potwierdzenia, odłączenie systemu od sieci i rozpoczęcie procedury reagowania na incydent.

Wektor ataku

Zidentyfikowana słabość to klasyczne wstrzyknięcie SQL (SQL Injection). Atakujący może manipulować argumentem ID wysyłanym do pliku /classes/Users.php z parametrem f=save 5 4. Błąd walidacji danych wejściowych po stronie serwera pozwala na dołączenie do zapytania SQL dowolnych, złośliwych poleceń.

SQL Injection to technika, w której atakujący wykorzystuje luki w aplikacji do wysyłania własnych zapytań do jej bazy danych. W tym scenariuszu, zamiast numeru identyfikacyjnego użytkownika, operator może przesłać fragment kodu, który nakazuje bazie danych zwrócić wszystkie rekordy pacjentów, zmodyfikować je lub całkowicie usunąć.

Kluczowe czynniki ryzyka w tym przypadku to:

  1. Zdalna eksploatacja: Atak nie wymaga fizycznego dostępu ani wcześniejszego uwierzytelnienia w systemie 2. Może być przeprowadzony przez internet przez każdego, kto zidentyfikuje serwer z podatnym oprogramowaniem.
  2. Publiczny exploit: Kod umożliwiający automatyczne wykorzystanie luki jest publicznie dostępny 3. Obniża to próg wejścia dla potencjalnych napastników.

Konsekwencją udanego ataku jest pełna kompromitacja bazy danych. Może to prowadzić do kradzieży wysoce wrażliwych danych medycznych, ich zaszyfrowania w ramach ataku ransomware lub trwałego usunięcia. Dla polskiej placówki medycznej oznaczałoby to poważny incydent naruszenia ochrony danych w rozumieniu RODO.

Wskaźniki kompromitacji

Brak jest publicznie dostępnych wskaźników kompromitacji (IoC — Indicators of Compromise), takich jak adresy IP serwerów C2 (Command and Control — serwer kontrolujący zainfekowane maszyny) czy hashe plików. Administratorzy systemów powinni jednak aktywnie monitorować logi serwera WWW pod kątem podejrzanych żądań.

Kluczowym wskaźnikiem próby ataku lub udanej kompromitacji mogą być zapytania HTTP POST kierowane do następującego zasobu:

/classes/Users.php?f=save

Należy analizować zawartość tych zapytań, w szczególności wartość parametru ID. Wszelkie wartości zawierające składnię SQL, takie jak UNION, SELECT, --, OR 1=1, powinny być traktowane jako próba ataku i natychmiast zbadane.

Co zrobić w 24-48h

Rekomendowane podejście ma na celu minimalizację ryzyka, nawet jeśli organizacja nie używa bezpośrednio tego konkretnego systemu. Poniższe kroki nie zastępują pełnej konsultacji z zespołem ds. bezpieczeństwa.

  1. Audyt oprogramowania: Należy przeprowadzić pilny przegląd oprogramowania używanego do przetwarzania danych wrażliwych, zwłaszcza danych medycznych. Szczególną uwagę trzeba zwrócić na systemy darmowe, open-source o niejasnym pochodzeniu lub te, które nie są już aktywnie wspierane przez producenta.

  2. Weryfikacja i izolacja: Jeśli w organizacji zidentyfikowano system SourceCodester Hospitals Patient Records Management System 1.0 1, należy go natychmiast odizolować od sieci. Nie wystarczy zablokować dostęp z zewnątrz — system powinien być całkowicie wyłączony do czasu podjęcia decyzji o migracji danych i wycofaniu go z użytku.

  3. Wdrożenie WAF: Zastosowanie Web Application Firewall (WAF) może pomóc w zablokowaniu podstawowych prób ataków typu SQL Injection. Reguły WAF mogą filtrować żądania zawierające typowe dla ataków ciągi znaków. Jest to jednak środek mitygujący, a nie rozwiązanie problemu u źródła.

  4. Przegląd polityki RODO: Ten incydent to dobry moment na przegląd wewnętrznych procedur dotyczących doboru i wdrażania oprogramowania. Każdy system przetwarzający dane osobowe, a zwłaszcza dane szczególnej kategorii, musi przejść ocenę ryzyka. Wyciek danych medycznych w Polsce wiąże się z obowiązkiem zgłoszenia do Urzędu Ochrony Danych Osobowych oraz potencjalnymi, wysokimi karami finansowymi.

Źródła

Zobacz też

Footnotes

  1. W systemie SourceCodester Hospitals Patient Records Management System w wersji 1.0 zidentyfikowano słabość. — https://nvd.nist.gov/vuln/detail/CVE-2026-10185 ↩ ↩2 ↩3

  2. Możliwe jest zdalne wykorzystanie ataku. — https://nvd.nist.gov/vuln/detail/CVE-2026-10185 ↩ ↩2

  3. Exploit został udostępniony publicznie i może być użyty do ataków. — https://nvd.nist.gov/vuln/detail/CVE-2026-10185 ↩ ↩2

  4. Manipulacja argumentem ID powoduje wstrzykiwanie SQL (SQL injection). — https://nvd.nist.gov/vuln/detail/CVE-2026-10185 ↩ ↩2

  5. Luka dotyczy nieznanej funkcji pliku /classes/Users.php?f=save. — https://nvd.nist.gov/vuln/detail/CVE-2026-10185 ↩ ↩2