CVE-2026-62293

Podatność w HAPI FHIR przed wersją 6.9.10 umożliwia atak XML External Entity (XXE) przez funkcję saxonTransform w klasie XsltUtilities. Brak ograniczeń ACCESS_EXTERNAL_DTD i ACCESS_EXTERNAL_STYLESHEET pozwala atakującemu na odczyt lokalnych plików, ataki blind XXE oraz SSRF na dowolne adresy URL.

HAPI FHIR to pełna implementacja standardu HL7 FHIR dla interoperacyjności opieki zdrowotnej w Javie. Przed wersją 6.9.4 usługa HTTP FHIR Validator udostępnia nieuwierzytelniony punkt końcowy "/loadIG", który wykonuje wychodzące żądania HTTP do adresów URL kontrolowanych przez atakującego. W połączeniu z wadą dopasowania prefiksu startsWith() w dostawcy poświadczeń (ManagedWebAccessUtils.getServer()), atakujący może ukraść tokeny uwierzytelniające (Bearer, Basic, klucze API) skonfigurowane dla legalnych serwerów FHIR, rejestrując domenę, której prefiks pasuje do skonfigurowanego adresu URL serwera. Problem został naprawiony w wersji 6.9.4.

HAPI FHIR to kompletna implementacja standardu HL7 FHIR dla interoperacyjności w opiece zdrowotnej w Javie. Przed wersją 6.9.12, SHCParser w org.hl7.fhir.r5/src/main/java/org/hl7/fhir/r5/elementmodel/SHCParser.java może wejść w nieskończoną pętlę podczas przetwarzania kontrolowanej przez atakującego treści JWT Smart Health Card, której nagłówek zawiera zip: "DEF" i której surowa treść DEFLATE jest pusta lub obcięta. SHCParser.decodeJWT() dociera do SHCParser.inflate(), gdzie Inflater.inflate() może zwrócić zero, podczas gdy Inflater.finished() pozostaje fałszywe, a Inflater.needsInput() jest prawdziwe. Pętla nie ma również warunku zakończenia Inflater.needsDictionary(), SHCParser.decompress() zawiera ten sam wzorzec zerowego postępu, a ResourceChecker.java może osiągnąć parsowanie SHC podczas wykrywania formatu pliku. Nieprawidłowe żądanie walidacji może zablokować wątek roboczy JVM na czas nieokreślony, a równoczesne żądania mogą wyczerpać wszystkich pracowników walidacji. Problem został naprawiony w wersji 6.9.12.

HAPI FHIR to kompletna implementacja standardu HL7 FHIR dla interoperacyjności w opiece zdrowotnej w Javie. Przed wersją 6.9.12, SHCParser w org.hl7.fhir.r5/src/main/java/org/hl7/fhir/r5/elementmodel/SHCParser.java może zużywać kontrolowaną przez atakującego treść JWT Smart Health Card, której nagłówek zawiera zip: "DEF" i której mała surowa treść DEFLATE rozwija się do bardzo dużej wartości. SHCParser.decodeJWT() przekazuje zdekodowaną treść do SHCParser.inflate(), który gromadzi wszystkie zdekompresowane bajty w ByteArrayOutputStream bez limitu rozmiaru wyjścia przed parsowaniem JSON, a SHCParser.decompress() zawiera ten sam nieograniczony wzorzec. Aplikacja lub usługa walidacyjna, która akceptuje treści SHC dostarczone przez atakującego, może więc cierpieć z powodu nadmiernej alokacji sterty, poważnej presji na garbage collector, awarii żądań, niestabilności procesu lub jego zakończenia. Problem został naprawiony w wersji 6.9.12.

Przed wersją 6.9.11 w HAPI FHIR, plik XhtmlParser.java nie narzuca maksymalnej głębokości zagnieżdżenia elementów, więc głęboko zagnieżdżona narracja text.div wywołuje nieograniczoną rekurencję między parseElementInner() i parseElement(), powodując StackOverflowError. Atakujący, który może przesłać zasoby FHIR zawierające takie narracje, może w ten sposób doprowadzić do awarii wątku roboczego parsowania lub walidacji, wpływając na usługi walidatora i każdą aplikację parsującą dostarczone przez atakującego FHIR JSON lub XML. Problem został naprawiony w wersji 6.9.11.

Przed wersją 6.9.11 w HAPI FHIR, parser JSON w org.hl7.fhir.utilities.json.parser.JsonParser nie egzekwuje maksymalnej głębokości zagnieżdżenia dla tablic lub obiektów. W rezultacie mały, ale głęboko zagnieżdżony, składniowo poprawny dokument FHIR JSON może wywołać nieograniczoną rekurencję readArray() lub readObject(), powodując StackOverflowError przed uruchomieniem walidacji strukturalnej. Atakujący, który może przesłać zasoby JSON do walidacji, może w ten sposób doprowadzić do awarii wątku żądania, a usługi, które nie izolują bezpiecznie StackOverflowError, mogą doświadczyć utraty pracowników lub niestabilności procesu — stan odmowy usługi. Problem został naprawiony w wersji 6.9.11.

HAPI FHIR przed wersjami 6.9.9 i 6.9.4.2 akceptuje dowolne wyrażenia FHIRPath bez walidacji wejścia. Funkcje matches(), matchesFull() i replaceMatches() przekazują kontrolowane przez użytkownika wyrażenia regularne do Pattern.compile() i String.replaceAll() przez niekompletną funkcję timeout. Atakujący może wysłać zasób ze złośliwym wzorcem regex powodującym katastrofalne cofanie się, wyczerpując zasoby CPU i powodując odmowę usługi.

W HAPI FHIR przed wersją 6.9.7 silnik FHIRPathEngine przekazuje wyrażenia regularne kontrolowane przez użytkownika z funkcji matches(), matchesFull() i replaceMatches() do operacji regex w Javie bez skutecznych limitów czasowych, co umożliwia katastroficzne cofanie się i odmowę usługi (DoS).

Podatność w HAPI FHIR przed wersją 6.9.10 wynika z niekompletnej łatki dla CVE-2026-45367 w module DSTU2. Metoda FHIRPathEngine.matches() wywołuje String.matches(sw) bez ochrony RegexTimeout, co pozwala nieuwierzytelnionemu atakującemu na wywołanie katastrofalnego cofania się wyrażeń regularnych i przeciążenie serwera.

HAPI FHIR przed wersją 6.9.4 zawiera endpoint /loadIG w usłudze FHIR Validator HTTP, który akceptuje adres URL podany przez użytkownika w treści JSON i wykonuje żądania HTTP po stronie serwera bez walidacji nazwy hosta, schematu lub domeny. Nieuwierzytelniony atakujący z dostępem sieciowym do walidatora może badać wewnętrzne usługi sieciowe, punkty końcowe metadanych chmury i mapować topologię sieci poprzez wyciek informacji oparty na błędach.