Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
OpenEMR to otwartoźródłowa platforma elektronicznej dokumentacji medycznej, wykorzystywana przez ponad 100 tys. świadczeniodawców ochrony zdrowia. Najnowsza analiza bezpieczeństwa wykazała 38 wcześniej nieudokumentowanych podatności, obejmujących m.in. SQL injection, błędy autoryzacji, XSS, path traversal oraz problemy z obsługą sesji.
Skala odkrycia pokazuje, że systemy przetwarzające dane pacjentów pozostają szczególnie atrakcyjnym celem ataków, a jednocześnie coraz większą rolę w wykrywaniu błędów odgrywają narzędzia oparte na sztucznej inteligencji. W tym przypadku automatyczna analiza kodu znacząco przyspieszyła identyfikację słabości w rozbudowanej aplikacji medycznej.
W skrócie
- W ciągu około trzech miesięcy wykryto 38 podatności i przypisano im identyfikatory CVE.
- Najgroźniejsze błędy mogły prowadzić do kompromitacji bazy danych, wycieku chronionych informacji zdrowotnych oraz potencjalnego zdalnego wykonania kodu.
- Istotna część poprawek trafiła do wydania OpenEMR 8.0.0 z 11 lutego 2026 r., a kolejne poprawki wdrożono w marcu 2026 r.
- Sprawa pokazuje rosnącą skuteczność AI w analizie bezpieczeństwa kodu oraz potrzebę szybkiego reagowania na podatności w systemach ochrony zdrowia.
Kontekst / historia
OpenEMR od lat należy do najbardziej rozpoznawalnych otwartoźródłowych systemów EHR i funkcjonuje w środowiskach, w których przetwarzane są dane o wysokiej wrażliwości. Już wcześniej platforma była przedmiotem analiz bezpieczeństwa, a wcześniejsze audyty wykazywały, że rozbudowana logika biznesowa i szeroka powierzchnia ataku utrudniają pełne zabezpieczenie systemu.
Obecne badanie pokazuje zmianę skali i tempa pracy. W relatywnie krótkim czasie zidentyfikowano więcej problemów niż podczas wcześniejszych, szeroko komentowanych analiz wykonywanych głównie ręcznie. To wyraźny sygnał, że narzędzia AI mogą istotnie skracać czas potrzebny do przeszukiwania dużych repozytoriów oraz identyfikowania błędów logicznych, autoryzacyjnych i implementacyjnych.
Z drugiej strony ten sam postęp technologiczny może działać na korzyść napastników. Jeśli obrońcy są w stanie szybciej odnajdywać luki, to również cyberprzestępcy mogą automatyzować poszukiwanie podatności w systemach krytycznych, w tym w oprogramowaniu medycznym.
Analiza techniczna
Wśród ujawnionych luk dominowały trzy grupy problemów: błędy autoryzacji, podatności typu SQL injection oraz nadmierna ekspozycja danych przez interfejsy API. W wielu miejscach aplikacja akceptowała identyfikatory rekordów przekazywane przez użytkownika bez właściwej weryfikacji uprawnień do odczytu lub modyfikacji danych. Tego rodzaju błędy odpowiadają schematowi IDOR i mogą umożliwiać dostęp do dokumentacji medycznej, danych płatności czy formularzy pacjentów.
Za najpoważniejszą uznano podatność CVE-2026-24908 z oceną CVSS 10.0. Problem dotyczył parametru _sort w Patient REST API. Przekazywane wartości były dołączane do klauzuli SQL bez skutecznej walidacji i bez ograniczenia do bezpiecznego zbioru pól. W praktyce uwierzytelniony atakujący mógł wykorzystać ten mechanizm do odczytu hashy haseł, analizy zawartości tabel bazy danych, a w sprzyjających warunkach również do operacji na plikach po stronie serwera, co otwierało drogę do dalszej eskalacji.
Drugim szczególnie istotnym błędem była luka CVE-2026-23627 w module immunizacji. Parametr patient_id trafiał do zapytań SQL bez prawidłowej parametryzacji. Pozwalało to uwierzytelnionemu użytkownikowi budować złośliwe zapytania prowadzące do przejęcia kontroli nad bazą danych, kradzieży informacji zdrowotnych i pozyskania poświadczeń. W środowiskach z nadmiernymi uprawnieniami po stronie DBMS ryzyko eskalacji było jeszcze większe.
Wyróżniono także CVE-2026-24487, dotyczącą interfejsu FHIR CareTeam. Mechanizm powinien ograniczać odpowiedzi do danych przypisanych do konkretnego pacjenta, jednak z powodu błędu architektonicznego filtr pacjenta nie był prawidłowo stosowany. W rezultacie endpoint mógł zwracać informacje o zespołach opieki dla wszystkich pacjentów, a nie wyłącznie dla rekordu objętego zakresem tokena. To szczególnie niebezpieczny przykład błędu logiki biznesowej w integracjach opartych na standardzie FHIR.
Istotny jest także sam proces remediacji. Dla każdej z 38 podatności przygotowano propozycje poprawek zgodne z architekturą repozytorium, co przyspieszyło wdrażanie łatek. Dodatkowo analizator AI został włączony do procesu code review, aby podobne problemy były wykrywane wcześniej, jeszcze przed wdrożeniem zmian do środowisk produkcyjnych.
Konsekwencje / ryzyko
Wpływ opisanych podatności należy ocenić jako wysoki, szczególnie w sektorze ochrony zdrowia. Systemy EHR przechowują dane osobowe, historię leczenia, informacje finansowe oraz dokumenty o znaczeniu operacyjnym i regulacyjnym. Ich kompromitacja może prowadzić do naruszenia poufności danych pacjentów, zakłóceń działania placówki, manipulacji dokumentacją medyczną, a także do wtórnych incydentów, takich jak ransomware, kradzież tożsamości czy oszustwa ubezpieczeniowe.
Dodatkowe ryzyko wynika z faktu, że część błędów mogła zostać wykorzystana przez użytkownika posiadającego jedynie podstawowy, uwierzytelniony dostęp. W praktyce oznacza to możliwość nadużycia przejętego konta, słabego hasła, skompromitowanego tokena lub poświadczeń wykradzionych w innym incydencie. Tam, gdzie organizacje nie wdrożyły segmentacji, monitorowania aktywności bazy danych oraz minimalizacji uprawnień, skutki potencjalnego ataku mogły być znacznie poważniejsze.
W środowisku medycznym należy uwzględnić również konsekwencje prawne i zgodnościowe. Ekspozycja danych zdrowotnych może uruchamiać obowiązki notyfikacyjne, audyty, wysokie koszty obsługi incydentu oraz długotrwałe straty reputacyjne. To przypomnienie, że błędy aplikacyjne w systemach klinicznych wpływają nie tylko na bezpieczeństwo informacji, ale też na ciągłość świadczenia usług i bezpieczeństwo pacjentów.
Rekomendacje
Organizacje korzystające z OpenEMR powinny w pierwszej kolejności zweryfikować używaną wersję systemu i niezwłocznie zastosować wszystkie poprawki opublikowane po wydaniu 8.0.0, w tym aktualizacje udostępnione w marcu 2026 r. Samo wdrożenie łatek nie powinno jednak kończyć procesu reakcji.
- Przeprowadzić przegląd logów aplikacyjnych, serwerowych i bazodanowych pod kątem anomalii związanych z REST API, modułem immunizacji oraz interfejsami FHIR.
- Wymusić rotację poświadczeń oraz skontrolować uprawnienia użytkowników i tokenów OAuth2.
- Ograniczyć uprawnienia kont bazy danych, szczególnie w zakresie funkcji umożliwiających odczyt i zapis plików na serwerze.
- Wdrożyć parametryzację zapytań, whitelistę parametrów wejściowych i dodatkowe kontrole ACL na poziomie aplikacji.
- Przeprowadzić testy autoryzacyjne pod kątem IDOR, brakujących kontroli dostępu i błędów zakresu w API.
- Monitorować nietypowe zapytania SQL, odpowiedzi zawierające nadmierny zakres danych oraz próby enumeracji rekordów pacjentów.
- Włączyć skanowanie bezpieczeństwa do pipeline’u CI/CD i procesu code review, z naciskiem na analizę semantyczną kodu.
Dla dostawców oprogramowania i zespołów utrzymaniowych płynie z tego szerszy wniosek: systemy medyczne wymagają ciągłego testowania bezpieczeństwa logiki biznesowej. Tradycyjne skanery dobrze wykrywają część klas błędów, ale często gorzej radzą sobie z lukami autoryzacyjnymi, niewłaściwym zakresem dostępu i problemami architektonicznymi w API.
Podsumowanie
Przypadek OpenEMR dobrze ilustruje dwa równoległe trendy w bezpieczeństwie aplikacji. Po pierwsze, systemy ochrony zdrowia pozostają szczególnie atrakcyjnym i ryzykownym celem ze względu na wartość danych oraz złożoność logiki biznesowej. Po drugie, narzędzia AI realnie zwiększają tempo wykrywania podatności, co może działać zarówno na korzyść obrońców, jak i atakujących.
Wykrycie 38 luk, w tym błędów umożliwiających kompromitację bazy danych i potencjalne zdalne wykonanie kodu, powinno skłonić administratorów do pilnego przeglądu aktualizacji, konfiguracji uprawnień i ekspozycji API. To również ważny sygnał dla całej branży, że bezpieczeństwo systemów EHR musi być traktowane jako proces ciągły, łączący szybkie łatanie, analizę architektury i automatyzację kontroli bezpieczeństwa już na etapie tworzenia oprogramowania.
Ź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
- AISLE – AISLE Discovers 38 CVEs in Healthcare Software Used by 100,000 Medical Providers — https://aisle.com/blog/aisle-discovers-38-critical-security-vulnerabilities-in-healthcare-software-used-by-100000-providers
- GitHub Advisory – SQL Injection in Patient API Sort Parameter — https://github.com/openemr/openemr/security/advisories/GHSA-rcc2-45v3-qmqm
- GitHub Advisory – SQL Injection in Immunization Search/Report — https://github.com/openemr/openemr/security/advisories/GHSA-x3hw-rwrg-v25h
- GitHub Advisory – FHIR Patient Compartment Bypass in CareTeam Resource — https://github.com/openemr/openemr/security/advisories/GHSA-4frq-f657-hwrc