CVE-2026-119343 in Stirling-PDF
Summary
by MITRE • 10/30/2026
Stirling-PDF is a locally hosted web application that facilitates various operations on PDF files. Prior to 3.0.0, POST /api/v1/ai/tools/create-pdf-from-html-agent accepts attacker-controlled htmlContent and passes it to WeasyPrint without CustomHtmlSanitizer, unlike the sanitized /api/v1/convert/html/pdf control path. HTTP and HTTPS resource references can make server-side requests to internal or cloud-metadata destinations, while file references can embed local content readable by the Stirling-PDF process into the generated PDF. The endpoint is reachable without credentials when security.enableLogin is false, and the flaw is distinct from earlier Stirling-PDF WeasyPrint vulnerabilities in older conversion paths. This issue is fixed in version 3.0.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
Stirling-PDF serves as a locally hosted web application designed to facilitate various operations on PDF files, including creation, modification, and conversion tasks. A critical security vulnerability was identified within the endpoint POST /api/v1/ai/tools/create-pdf-from-html-agent in versions prior to 3.0.0. This specific API route accepts user-supplied HTML content via the htmlContent parameter and processes it using the WeasyPrint library to generate a PDF document. Unlike other conversion endpoints such as /api/v1/convert/html/pdf, which implement robust sanitization measures through CustomHtmlSanitizer, this particular AI tool endpoint fails to apply equivalent input validation or output encoding controls. This inconsistency in security implementation creates a distinct attack vector that was not present in earlier WeasyPrint-related vulnerabilities affecting different conversion paths within the application.
The core technical flaw lies in the absence of proper sanitization for HTML content passed to the rendering engine, which leads directly to Server-Side Request Forgery and Local File Inclusion risks. When an attacker supplies HTTP or HTTPS resource references within the malicious HTML payload, WeasyPrint processes these URLs by making server-side requests on behalf of the application. This behavior allows attackers to direct internal network traffic toward sensitive destinations that are typically inaccessible from external networks, such as cloud metadata endpoints like 169.254.169.254 or local service interfaces bound only to localhost. Additionally, file references embedded in the HTML can cause the server to read and embed local content into the generated PDF output. Since Stirling-PDF runs with specific system privileges, it may access files that are readable by its process user account but restricted for regular users, effectively enabling Local File Inclusion attacks where sensitive configuration files or internal data can be exfiltrated through the resulting document.
The operational impact of this vulnerability is significant due to the potential for unauthorized data exposure and network reconnaissance within private infrastructure environments. Because the endpoint is reachable without credentials when the security.enableLogin setting is disabled, which is a common default or administrative oversight in local deployments, unauthenticated attackers can exploit these flaws remotely. The ability to probe internal networks via SSRF allows adversaries to map out service architectures, identify vulnerable services on adjacent hosts, and potentially pivot further into protected segments of the network. Furthermore, the leakage of sensitive file contents through PDF generation compromises data confidentiality, violating basic principles of information security regarding access control and data protection. This issue is classified under CWE-918 for Server-Side Request Forgery and CWE-22 for Improper Limitation of a Pathname to a Restricted Directory, reflecting both the network-based exploitation capability and the file system access violation inherent in the flaw.
Mitigation strategies must prioritize immediate remediation by upgrading Stirling-PDF to version 3.0.0 or later, where this specific endpoint has been patched with appropriate sanitization logic consistent with other secure conversion paths. For environments unable to upgrade immediately, administrators should ensure that security.enableLogin is set to true to enforce authentication requirements on all API endpoints, thereby preventing unauthenticated access to the vulnerable route. Network-level controls such as web application firewalls or reverse proxy configurations can also be employed to restrict outbound traffic from the Stirling-PDF server IP address, blocking requests to known cloud metadata ranges and internal subnets that do not require external internet connectivity. Additionally, running the application with minimal file system permissions ensures that even if local file inclusion is attempted, the process lacks the necessary privileges to read sensitive configuration files or user data, thereby reducing the blast radius of any successful exploitation attempt aligned with ATT&CK techniques for server-side request forgery and unauthorized access to cloud resources.