Jedna prosta luka w oprogramowaniu do zarządzania danymi pacjentów wystarczyła, aby umożliwić zdalny atak. Zaobserwowaliśmy publiczną publikację exploita na podatność w systemie SourceCodester Hospitals Patient Records Management System w wersji 1.0 1. Choć samo oprogramowanie jest niszowe, wektor ataku — klasyczne wstrzyknięcie SQL — pozostaje jednym z najczęstszych sposobów na nieautoryzowany dostęp do baz danych. Analizujemy ten przypadek jako studium dla polskich placówek medycznych i firm tworzących dla nich oprogramowanie.

TL;DR

  • Produkt: SourceCodester Hospitals Patient Records Management System v1.0 1.
  • Podatność: CVE-2026-10184 [cve.id], krytyczność CVSS 7.3 (High) [cve.cvss] [cve.severity].
  • Wektor: Zdalne wstrzyknięcie SQL (SQL Injection) 2 przez manipulację parametru ID w pliku Users.php 3.
  • Wskaźniki: Żądania HTTP do ścieżki /classes/Users.php?f=delete z nietypowymi wartościami w parametrze ID.
  • Kogo dotyczy: Bezpośrednio — użytkowników wskazanego systemu. Pośrednio — wszystkich administratorów systemów przechowujących dane wrażliwe, w tym dane medyczne w Polsce, jako przykład typowego wektora ataku.
  • Pierwszy ruch: Weryfikacja, czy oprogramowanie jest używane w organizacji. Przegląd logów serwerów WWW pod kątem próby wykorzystania podobnych wektorów na innych aplikacjach.

Wektor ataku

Podatność zidentyfikowana jako CVE-2026-10184 [cve.id] dotyczy konkretnego komponentu systemu do zarządzania danymi pacjentów 1. Luka znajduje się w pliku /classes/Users.php, w funkcji dostępnej poprzez parametr f=delete 3.

Atakujący może spreparować specjalne zapytanie do serwera, manipulując wartością argumentu ID 2. Aplikacja nie filtruje poprawnie danych wejściowych pochodzących od użytkownika. Pozwala to na dołączenie do oryginalnego zapytania SQL dodatkowych komend, które zostaną wykonane bezpośrednio na bazie danych. Jest to klasyczny przykład ataku typu SQL Injection (wstrzyknięcie SQL).

Konsekwencje udanego ataku na system przechowujący dane medyczne są poważne. Sprawca może uzyskać nieautoryzowany dostęp do odczytu, modyfikacji, a nawet usunięcia rekordów pacjentów. Atak może być przeprowadzony w pełni zdalnie 4, bez potrzeby fizycznego dostępu do infrastruktury. Sytuację pogarsza fakt, że szczegóły techniczne i gotowy kod exploita zostały upublicznione 5. Oznacza to, że próg wejścia dla potencjalnych atakujących jest skrajnie niski — nie muszą oni samodzielnie analizować aplikacji, a jedynie skorzystać z gotowego narzędzia.

Choć oprogramowanie SourceCodester jest rzadko spotykane w polskich placówkach, ten incydent stanowi ważną przestrogę. Wiele systemów medycznych, zwłaszcza tych tworzonych na zamówienie lub opartych o mniej popularne rozwiązania open-source, może zawierać podobne, proste błędy.

Wskaźniki kompromitacji

Nie zidentyfikowano konkretnych adresów IP ani haszy plików powiązanych z kampaniami wykorzystującymi tę lukę. Głównym wskaźnikiem kompromitacji (IoC, Indicators of Compromise) jest sam wzorzec ruchu sieciowego. Administratorzy powinni przeszukiwać logi serwerów WWW pod kątem żądań kierowanych do wrażliwego endpointu, szczególnie tych zawierających znaki typowe dla SQL Injection w parametrze ID.

Wzorzec do monitorowania w logach serwera WWW:

GET /classes/Users.php?f=delete&id=...

Należy zwrócić szczególną uwagę na nietypowe wartości po id=, zawierające apostrofy, średniki, komentarze SQL (--, #) lub słowa kluczowe takie jak UNION, SELECT, OR.

Co zrobić w 24-48h

Rekomendowane podejście nie ogranicza się tylko do tego konkretnego CVE, ale stanowi ogólną procedurę reagowania na informację o nowej, publicznie znanej luce w oprogramowaniu.

  1. Identyfikacja zasobów: Pierwszym krokiem jest sprawdzenie, czy oprogramowanie SourceCodester Hospitals Patient Records Management System jest lub kiedykolwiek było używane w infrastrukturze. Nawet jeśli odpowiedź brzmi „nie”, proces ten jest okazją do weryfikacji i aktualizacji firmowego spisu oprogramowania (software inventory).

  2. Proaktywne przeszukanie logów: Należy zlecić zespołowi SOC (Security Operations Center — zespół monitoringu bezpieczeństwa) lub administratorom przeszukanie logów serwerów WWW z ostatnich 30 dni pod kątem wzorca ataku opisanego w sekcji IoC. Nawet jeśli podatne oprogramowanie nie jest obecne, taka analiza może ujawnić próby ataków na inne aplikacje.

  3. Kontekst polski — RODO i NIS2: Wyciek danych medycznych pacjentów stanowi naruszenie ochrony danych osobowych o szczególnym charakterze w rozumieniu RODO (Rozporządzenie o Ochronie Danych Osobowych). Taki incydent wiąże się z obowiązkiem zgłoszenia do Urzędu Ochrony Danych Osobowych (UODO) w ciągu 72 godzin oraz potencjalnie wysokimi karami finansowymi. Dodatkowo, sektor ochrony zdrowia jest jednym z kluczowych objętych dyrektywą NIS2, która nakłada na podmioty medyczne nowe, surowe obowiązki w zakresie cyberbezpieczeństwa. Ten przypadek pokazuje, jak krytyczne jest posiadanie procedur na wypadek podobnego zdarzenia.

  4. Przegląd polityki WAF: Jeśli w organizacji używany jest Web Application Firewall (WAF), warto sprawdzić, czy jego reguły są aktualne i czy skutecznie blokują podstawowe próby wstrzyknięcia SQL. Ten incydent to dobry pretekst do testu, czy WAF nie działa w trybie samego monitorowania.

  5. Komunikacja z dostawcami: Dla polskich placówek medycznych, które korzystają z oprogramowania od zewnętrznych dostawców, jest to sygnał do zadania pytań. Warto wystosować zapytanie do producentów kluczowych systemów (np. HIS, LIS, RIS) z prośbą o oświadczenie, czy ich produkty są odporne na ataki typu SQL Injection i czy przechodzą regularne, niezależne testy bezpieczeństwa. Powyższe kroki nie gwarantują stuprocentowego bezpieczeństwa, ale stanowią podstawę dojrzałego podejścia do zarządzania ryzykiem w obliczu stale pojawiających się nowych zagrożeń. Rekomendowane działania nie zastępują profesjonalnej konsultacji z zakresu cyberbezpieczeństwa.

Źródła

Zobacz też

Footnotes

  1. W SourceCodester Hospitals Patient Records Management System w wersji 1.0 odkryto lukę bezpieczeństwa. — https://nvd.nist.gov/vuln/detail/CVE-2026-10184 ↩ ↩2 ↩3

  2. Manipulacja argumentu ID prowadzi do wstrzyknięcia SQL (SQL injection). — https://nvd.nist.gov/vuln/detail/CVE-2026-10184 ↩ ↩2

  3. Luka dotyczy nieznanej funkcji w pliku /classes/Users.php?f=delete. — https://nvd.nist.gov/vuln/detail/CVE-2026-10184 ↩ ↩2

  4. Atak może być przeprowadzony zdalnie. — https://nvd.nist.gov/vuln/detail/CVE-2026-10184 ↩

  5. Exploit został publicznie udostępniony i może być wykorzystany do ataków. — https://nvd.nist.gov/vuln/detail/CVE-2026-10184 ↩