CVE-2026-47660

Przed wersją 2.0.0 Pathling Server operacja `$import-pnp` akceptuje dostarczony przez wywołującego `exportUrl` i używa go jako zdalnego punktu końcowego FHIR Bulk Export bez ograniczania go do zaufanego źródła. Gdy skonfigurowane są poświadczenia PNP, Pathling buduje uwierzytelniony klient eksportu masowego kierujący się na host wybrany przez wywołującego, pobiera pliki wybrane z manifestu, a następnie reklasyfikuje te pliki jako zaufane lokalne importy `file://` - omijając listę dozwolonych `allowableSources`, która chroni zwykłą operację `$import`. Problem został naprawiony w Pathling Server 2.0.0. Obejściem jest wyłączenie operacji `$import-pnp` (`pathling.operations.importPnpEnabled=false`) lub niekonfigurowanie poświadczeń PNP.

Przed wersją 2.0.0 Pathling Server, typowana powierzchnia CRUD/wyszukiwania/wsadowa FHIR pozwala uwierzytelnionemu wywołującemu z tylko ogólnymi uprawnieniami operacyjnymi na działanie na wybranych przez atakującego rodzinach zasobów, ponieważ te punkty wejścia nie egzekwują spójnie udokumentowanych uprawnień `read` i `write` dla poszczególnych zasobów. Udokumentowany model autoryzacji wymaga, aby uprawnienie operacyjne (np. `pathling:search`) było sparowane z odpowiednim uprawnieniem `read` lub `write` dla zasobu (np. `pathling:read:Patient`). Usuwanie i operacje wsadowe są udokumentowane jako wymagające uprawnienia zapisu dla wszystkich typów zasobów. Jednak typowane wyszukiwanie, aktualizacja i powiązane procedury obsługi są oznaczone tylko adnotacją `@OperationAccess(...)` i działają na typie zasobu wybranym przez dostawcę bez sprawdzania odpowiedniego uprawnienia dla zasobu. Problem został naprawiony w Pathling Server 2.0.0.

Przed wersją 2.0.0 Pathling Server, typowana powierzchnia CRUD/wyszukiwania/wsadowa FHIR pozwala uwierzytelnionemu wywołującemu z tylko ogólnymi uprawnieniami operacyjnymi na działanie na wybranych przez atakującego rodzinach zasobów, ponieważ te punkty wejścia nie egzekwują spójnie udokumentowanych uprawnień `read` i `write` dla poszczególnych zasobów. Udokumentowany model autoryzacji wymaga, aby uprawnienie operacyjne (np. `pathling:search`) było sparowane z odpowiednim uprawnieniem `read` lub `write` dla zasobu (np. `pathling:read:Patient`). Usuwanie i operacje wsadowe są udokumentowane jako wymagające uprawnienia zapisu dla wszystkich typów zasobów. Jednak typowane wyszukiwanie, aktualizacja i powiązane procedury obsługi są oznaczone tylko adnotacją `@OperationAccess(...)` i działają na typie zasobu wybranym przez dostawcę bez sprawdzania odpowiedniego uprawnienia dla zasobu. Problem został naprawiony w Pathling Server 2.0.0.

Przed wersją 2.0.0 Pathling Server, punkt końcowy `/$result` pozwala wywołującemu, który może uzyskać dowolny ważny identyfikator zadania eksportu asynchronicznego, na podanie wartości parametru `file` zawierających sekwencje przejścia ścieżki. Procedura obsługi weryfikuje tylko dostarczone `job` i nigdy nie normalizuje ani nie ogranicza żądanej ścieżki `file` do katalogu `jobs/<jobId>` tego zadania przed otwarciem jej jako zasobu systemu plików. Ponieważ przestrzeń robocza eksportu asynchronicznego znajduje się w tym samym katalogu głównym bazy danych magazynu, co utrwalone tabele zasobów, atakujący może użyć własnego zadania eksportu do odczytu innych plików z magazynu. Problem został naprawiony w Pathling Server 2.0.0. Jako tymczasowe złagodzenie, wyłącz operacje eksportu asynchronicznego (`pathling.operations.exportEnabled`, `patientExportEnabled`, `groupExportEnabled`, `bulkSubmitEnabled`) lub włącz uwierzytelnianie i ogranicz możliwość eksportu do zaufanych wywołujących.

Pathling Server przed wersją 2.0.0 ma podatność na path traversal w punkcie końcowym `/$result`. Osoba znająca identyfikator zadania eksportu może podać ścieżkę pliku zawierającą sekwencje `../`, co pozwala na odczyt plików spoza katalogu zadania, w tym danych z magazynu.