CVE-2026-33180

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.

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 wersją 6.9.11 zawiera podatność na przechowywany XSS w ukrytym poleceniu skanowania, które łączy tytuły Implementation Guide, profile i źródła bez escapowania w pliku Scanner.java. Użytkownik skanujący złośliwy IG/profile i otwierający raport HTML może wywołać wykonanie złośliwego JavaScript w kontekście przeglądarki.

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.

W HAPI FHIR przed wersją 6.9.4, metoda ManagedWebAccessUtils.getServer() używa String.startsWith() do dopasowywania URL-i żądań do skonfigurowanych serwerów w celu wysyłania poświadczeń uwierzytelniających. Brak sprawdzania końca hosta lub ukośnika powoduje, że domena atakującego (np. http://tx.fhir.org.attacker.com) pasuje do prefiksu i otrzymuje tokeny Bearer, dane uwierzytelniające Basic Auth lub klucze API, gdy klient HTTP podąża za przekierowaniem.