CVE-2026-113605

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 przed wersją 3.0.0 endpoint POST /api/v1/ai/tools/create-pdf-from-html-agent przyjmuje kontrolowaną przez atakującego zawartość htmlContent i przekazuje ją do WeasyPrint bez sanityzacji CustomHtmlSanitizer, w przeciwieństwie do chronionej ścieżki /api/v1/convert/html/pdf. Odwołania do zasobów HTTP/HTTPS mogą powodować żądania po stronie serwera do celów wewnętrznych lub metadanych chmury, a odwołania do plików mogą osadzić lokalną zawartość w wygenerowanym PDF. Endpoint jest dostępny bez uwierzytelnienia, gdy security.enableLogin ma wartość false.

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.