Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
OpenEMR to otwartoźródłowa platforma elektronicznej dokumentacji medycznej wykorzystywana przez placówki ochrony zdrowia na całym świecie. Ujawnienie 38 wcześniej niepublicznych podatności pokazuje, że nawet dojrzałe i szeroko wdrażane systemy medyczne pozostają narażone na krytyczne błędy aplikacyjne. Sprawa zwraca również uwagę na rosnące znaczenie narzędzi opartych na sztucznej inteligencji, które przyspieszają analizę bezpieczeństwa i identyfikację złożonych luk w kodzie.
W skrócie
- W OpenEMR wykryto 38 nowych podatności o istotności od średniej do krytycznej.
- Wśród błędów znalazły się m.in. SQL injection, braki w autoryzacji, cross-site scripting, path traversal i problemy z sesjami.
- Najgroźniejsze scenariusze obejmowały przejęcie bazy danych, wyciek danych medycznych oraz możliwość zdalnego wykonania kodu.
- Poprawki zostały opublikowane, a część z nich trafiła do wersji 8.0.0 i kolejnych aktualizacji wydanych w marcu.
Kontekst / historia
Analiza bezpieczeństwa została przeprowadzona przy użyciu platformy wspieranej przez AI, która autonomicznie przeszukała kod źródłowy projektu. W ciągu około trzech miesięcy zidentyfikowano 38 nowych numerów CVE i przekazano je zespołowi utrzymującemu OpenEMR. To wynik pokazujący, jak bardzo automatyzacja może zwiększyć tempo wykrywania problemów w porównaniu z tradycyjnymi, ręcznymi audytami bezpieczeństwa.
Przypadek OpenEMR wpisuje się w szerszy trend wykorzystania modeli AI do wspierania badań nad podatnościami. Z jednej strony oznacza to szybsze znajdowanie luk i sprawniejsze przygotowywanie poprawek, z drugiej zaś zwiększa presję na zespoły bezpieczeństwa, które muszą szybciej oceniać wpływ błędów, priorytetyzować działania i zamykać okna ekspozycji zanim podatności zostaną wykorzystane w praktyce.
Analiza techniczna
Zidentyfikowane luki obejmowały kilka klas błędów szczególnie groźnych dla systemów przechowujących dokumentację kliniczną. Najpoważniejsze znaczenie miały podatności typu SQL injection, które mogą prowadzić do bezpośredniego dostępu do wrażliwych danych pacjentów i informacji uwierzytelniających.
Jednym z kluczowych przykładów była podatność CVE-2026-24908 z maksymalnym wynikiem CVSS 10.0, dotycząca Patient REST API. Luka umożliwiała użytkownikowi z ważnymi poświadczeniami wykonywanie zapytań pozwalających na pobranie hashy haseł i przeglądanie dowolnych tabel bazy danych. W określonych warunkach scenariusz ataku mógł zostać rozwinięty do odczytu lub zapisu plików na serwerze, a następnie do pełnej kompromitacji systemu.
Kolejnym istotnym problemem była CVE-2026-23627 związana z modułem śledzenia szczepień. Ta podatność również dotyczyła SQL injection i pozwalała uwierzytelnionemu napastnikowi manipulować zapytaniami SQL w sposób prowadzący do przejęcia kontroli nad bazą danych, kradzieży informacji zdrowotnych oraz danych logowania. W części scenariuszy możliwe było także osiągnięcie zdalnego wykonania kodu.
Na uwagę zasługuje również CVE-2026-24487, czyli obejście autoryzacji w punkcie końcowym FHIR CareTeam. Mechanizm powinien ograniczać widoczność danych do personelu klinicznego powiązanego z konkretnym pacjentem, jednak wada logiki autoryzacyjnej powodowała ujawnianie danych dotyczących wszystkich pacjentów w systemie. W środowisku medycznym taki błąd może prowadzić do masowego naruszenia poufności i podważać podstawowe zasady kontroli dostępu.
Z technicznego punktu widzenia zestaw wykrytych podatności wskazuje na kilka problemów projektowych: niewystarczającą walidację danych wejściowych, niepełne egzekwowanie autoryzacji na poziomie endpointów API, nadmierne zaufanie do danych dostarczanych przez użytkownika oraz słabe zabezpieczenia warstwy sesji. W systemach EHR łączących klasyczny interfejs webowy, REST API i moduły FHIR błędy tego typu mogą zostać połączone w jeden łańcuch ataku prowadzący od uwierzytelnienia do eskalacji dostępu i eksfiltracji danych.
Konsekwencje / ryzyko
Ryzyko operacyjne i biznesowe związane z tymi lukami należy ocenić jako wysokie. Kompromitacja systemu EHR może oznaczać dostęp do dokumentacji pacjentów, danych personelu, informacji rozliczeniowych oraz elementów integracji z innymi usługami medycznymi. Taki incydent może skutkować nie tylko naruszeniem poufności danych zdrowotnych, ale również przestojami operacyjnymi, kosztownym reagowaniem na incydent i utratą zaufania pacjentów.
Dodatkowym problemem jest fakt, że część scenariuszy ataku wymagała jedynie ważnych poświadczeń, a nie uprawnień administracyjnych. To oznacza, że potencjalnym źródłem incydentu może być zarówno przejęte konto użytkownika, jak i insider dysponujący ograniczonym dostępem. W organizacjach medycznych, gdzie działają liczne konta aplikacyjne, integracje zewnętrzne i użytkownicy o różnych rolach, znacząco zwiększa to powierzchnię ataku.
Rekomendacje
Organizacje korzystające z OpenEMR powinny w pierwszej kolejności potwierdzić wersję wdrożonego oprogramowania i upewnić się, że zastosowano wszystkie poprawki opublikowane po ujawnieniu podatności. Aktualizacja nie powinna ograniczać się wyłącznie do środowiska produkcyjnego — konieczne jest również sprawdzenie środowisk testowych, kopii zapasowych, komponentów zależnych i dodatkowych modułów.
- zweryfikować wersję OpenEMR i niezwłocznie wdrożyć dostępne poprawki bezpieczeństwa,
- przeprowadzić przegląd uprawnień zgodnie z zasadą najmniejszych uprawnień,
- zresetować hasła kont uprzywilejowanych oraz ocenić ryzyko ujawnienia hashy haseł,
- przeanalizować logi aplikacyjne, bazodanowe i systemowe pod kątem nietypowych zapytań SQL i prób dostępu do danych pacjentów,
- ograniczyć komunikację sieciową serwera aplikacyjnego do niezbędnych połączeń,
- wdrożyć monitoring API oraz detekcję anomalii dla endpointów REST i FHIR,
- rozważyć użycie WAF i reguł wykrywających SQL injection, path traversal oraz nadużycia sesji,
- włączyć automatyczne testy bezpieczeństwa i analizę kodu do procesu CI/CD.
Po wdrożeniu poprawek warto dodatkowo przetestować scenariusze dostępu do danych pacjentów, aby upewnić się, że polityki autoryzacji rzeczywiście ograniczają widoczność rekordów do właściwych użytkowników, ról i kontekstów klinicznych.
Podsumowanie
Wykrycie 38 podatności w OpenEMR pokazuje, że systemy ochrony zdrowia nadal pozostają atrakcyjnym celem ataków, a ich złożoność sprzyja powstawaniu krytycznych błędów bezpieczeństwa. Jednocześnie sprawa potwierdza, że narzędzia AI stają się coraz ważniejszym elementem procesu wykrywania luk, znacząco skracając czas potrzebny na analizę dużych projektów. Dla organizacji korzystających z OpenEMR priorytetem powinno być szybkie wdrożenie poprawek, kontrola skuteczności autoryzacji oraz rozszerzenie monitoringu o scenariusze nadużyć związanych z API, bazą danych i sesjami użytkowników.
Źródła
- Dark Reading – AI Finds 38 Security Flaws in Electronic Health Record Platform — https://www.darkreading.com/vulnerabilities-threats/ai-finds-38-security-flaws-openemr
- OpenEMR Project — https://www.open-emr.org/
- GitHub Advisory Database – CVE-2026-24908 — https://github.com/advisories
- GitHub Advisory Database – CVE-2026-23627 — https://github.com/advisories
- GitHub Advisory Database – CVE-2026-24487 — https://github.com/advisories