CVE-2026-119343

W Stirling-PDF od wersji 2.13.2 do 3.2.0 występuje niekompletna lista blokad w DatabaseService.validateSqlContent(), pozwalająca administratorom obejść ograniczenia importu H2 za pomocą CREATE OR REPLACE ALIAS. Uwierzytelnieni administratorzy mogą przesłać spreparowaną kopię SQL do endpointu import-database, gdzie RUNSCRIPT definiuje aliasy funkcji Java H2 i przywraca wykonywanie metod Java.

W Stirling-PDF przed wersją 2.13.2 uwierzytelniony administrator korzystający z domyślnej bazy H2 i trybu bezpieczeństwa może przesłać spreparowany plik SQL do POST /api/v1/database/import-database. Funkcja DatabaseService.validateSqlContent() dzieli znormalizowane dane wejściowe po średnikach i akceptuje instrukcję, jeśli zawiera dowolne dozwolone słowo kluczowe, co pozwala na obejście niewystarczającej białej listy przez niebezpieczne funkcje H2, takie jak FILE_READ i CSVWRITE, oraz CREATE ALIAS, i wykonanie efektów ubocznych podczas przetwarzania pliku przez RUNSCRIPT. Umożliwia to dowolny dostęp do plików. Zademonstrowany łańcuch wykonania poleceń systemu operacyjnego zapisuje kontrolowane przez atakującego pliki startowe w lokalizacji użytkownika, a następnie uruchamia interpreter Pythona aplikacji skonfigurowany do ładowania tych plików, co skutkuje wykonaniem poleceń jako konto usługi JVM.

W Stirling-PDF od wersji 2.13.1 do 2.13.2 endpoint POST /api/v1/convert/svg/pdf renderuje dostarczony przez atakującego SVG przez Apache Batik, a odwołanie do obrazu z ścieżką względną bez schematu omija SvgSanitizer.isExternalUrl(), zanim Batik rozwiąże je względem bazy dokumentu file:///input.svg jako lokalny plik. Ścieżki convert() i addSvgAsPage() w SvgToPdf.java mogą następnie wyrenderować dekodowalne obrazy z plików serwera do zwróconego PDF, gdy sanityzacja jest włączona, w tym bez uwierzytelnienia w przypadku wdrożeń z wyłączonym logowaniem lub z dostępem nieadministratora, gdy logowanie jest włączone. Podatność ujawnia zawartość PNG, JPG, GIF lub SVG i zapewnia wyrocznię istnienia tylko dla ścieżek dekodowalnych jako obrazy.

W Stirling-PDF od wersji 3.0.0 do 3.2.0 występuje obejście autoryzacji, które pozwala uwierzytelnionym użytkownikom uzyskać dostęp do plików innych użytkowników poprzez wskazanie folderu przetwarzania na katalog przechowywania serwera. Atakujący może utworzyć folder przez POST /api/v1/processing-folders wskazujący storage/<victimUserId>, wylistować pliki i uruchomić pipeline'y, aby czytać, modyfikować lub niszczyć pliki ofiar.

Stirling-PDF to lokalnie hostowana aplikacja webowa do operacji na plikach PDF. Przed wersją 2.9.0, endpoint /api/v1/pipeline/handleData wstrzykuje klucz API STIRLING-PDF-BACKEND-API-USER do podzapytań pipeline, co pozwala uwierzytelnionemu użytkownikowi z rolą ROLE_USER na odzyskanie klucza przez /api/v1/user/get-api-key, podszywanie się pod wewnętrzne konto usługowe, ominięcie limitów szybkości i dostęp do wewnętrznych endpointów. Problem naprawiono w wersji 2.9.0.

Stirling-PDF przed wersją 2.0.0 ma podatność na przechowywany XSS w workflow Get Info w pliku app/core/src/main/resources/templates/security/get-info-on-pdf.html. Niezaufane metadane Title i Author z PDF są wstawiane do elementu summary-text przez innerHTML, co pozwala złośliwemu PDF na wykonanie skryptu po kliknięciu Get Info i dostęp do danych sesji przeglądarki lub modyfikację zawartości strony. Problem naprawiono w wersji 2.0.0.

Endpoint POST /api/v1/convert/url/pdf w Stirling-PDF (ConvertWebsiteToPDF.java) nie został zaktualizowany o zabezpieczenia CustomHtmlSanitizer/SsrfProtectionService, które dodano do trzech pokrewnych endpointów konwersji (html/pdf, file/pdf, markdown/pdf).

Podatność w Stirling-PDF przed wersją 2.0.0 umożliwiała wstrzyknięcie kodu JavaScript przez pola metadanych tytułu i autora PDF. Atakujący może przygotować złośliwy plik PDF, który po wyświetleniu informacji o nim w interfejsie webowym wykonuje kod w przeglądarce ofiary.

Stirling-PDF w wersjach przed 2.0.0 renderuje nazwy plików dostarczone przez użytkownika bezpośrednio do HTML przy użyciu niebezpiecznych metod, takich jak innerHTML, bez sanityzacji. Atakujący może spreparować plik o złośliwej nazwie zawierającej JavaScript, który wykona się w kontekście przeglądarki użytkownika przesyłającego plik, powodując odbity XSS na wielu punktach końcowych przesyłania.