CVE-2026-110718 in html-to-docx
Summary
by MITRE • 10/14/2026
TurboDocx html-to-docx through 1.23.1 contains a server-side request forgery vulnerability that allows attackers supplying HTML to make the server fetch internal URLs via img src attributes. Attackers can reference loopback, private, or cloud metadata addresses that bypass the loose isValidUrl() check, and read responses embedded in the generated DOCX word/media folder.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
The TurboDocx library, specifically through version 1.23.1, contains a critical server-side request forgery vulnerability rooted in its HTML-to-DOCX conversion process. This flaw arises from insufficient validation of user-supplied input when processing HTML content that is intended to be converted into Microsoft Word documents. The core mechanism involves the parsing of img src attributes within the provided HTML payload. When an attacker supplies maliciously crafted HTML, they can inject URLs pointing to internal network resources rather than public internet addresses. Because TurboDocx operates on the server side during the conversion process, it acts as a proxy for these requests, fetching the content specified in the image sources and embedding them into the resulting DOCX file structure.
The technical flaw lies primarily in the implementation of the isValidUrl() function used to validate input URLs before processing. This validation logic is overly permissive and fails to adequately restrict schemes or target hosts that are considered unsafe for server-side fetching. Specifically, it does not properly block access to loopback addresses such as 127.0.0.1 or localhost, private IP ranges defined in RFC 1918, nor cloud metadata endpoints like those found at AWS EC2 instance metadata service URLs (e.g., http://169.254.169.254). By leveraging these internal addresses within the img src attribute, an attacker can bypass the existing security controls and force the server to initiate HTTP requests to resources that are typically inaccessible from external networks or intended for local administrative use only.
The operational impact of this vulnerability is significant as it enables unauthorized data exfiltration from the host system running the TurboDocx service. Attackers who have control over the HTML input can read sensitive internal responses embedded within the generated DOCX file, specifically in the word/media folder where images are stored after being fetched by the server. This capability allows for reconnaissance of internal network services, retrieval of cloud instance metadata which may contain authentication tokens or configuration details, and potential access to other backend systems that trust requests originating from localhost or private IP ranges. The vulnerability effectively turns a document conversion utility into a tool for probing and extracting data from protected environments, compromising the confidentiality and integrity of the underlying infrastructure.
This issue aligns with CWE-918 Server-Side Request Forgery (SSRF), which describes flaws where a web application fetches a remote resource without validating the user-supplied URL. Additionally, it relates to CWE-20 Improper Input Validation, as the input sanitization process fails to enforce strict constraints on allowed schemes and host addresses. In terms of attack tactics, this behavior corresponds to ATT&CK technique T1557 Adversary-in-the-Middle or more specifically T1046 Network Service Discovery if used for scanning, but primarily falls under data exfiltration patterns where internal resources are accessed via the compromised application. The lack of strict allow-listing for URLs and failure to disable server-side fetching of local resources constitutes a fundamental design flaw in input handling.
To mitigate this vulnerability, developers should immediately upgrade TurboDocx to version 1.24.0 or later if available, as newer versions may include stricter URL validation logic. If upgrading is not feasible, implementing a robust allow-list for permitted URLs and domains at the application level is essential. It is critical to explicitly block access to loopback addresses (127.0.0.0/8), link-local addresses (169.254.0.0/16), private IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), and cloud metadata endpoints. Furthermore, disabling the ability to fetch external resources entirely if not strictly required for document generation can eliminate this attack vector. Input validation should be performed using a strict allow-list approach rather than relying on blacklist-based checks or loose regular expressions that may miss edge cases involving different URL formats or encoded characters.