TurboDocx html-to-docx CVE-2026-110718

Exploitation requires that the application pass attacker-controlled HTML to TurboDocx html-to-docx server-side with image handling active, so that <img src> URLs are fetched during DOCX generation; the attacker-supplied URL must bypass the library's loose isValidUrl() validation and must point at an internal resource (loopback, RFC1918 private ranges, or cloud metadata such as 169.254.169.254) that is actually reachable and responsive from the server. No authentication or user interaction is needed (PR:N/UI:N). Limiting factors raising the bar (reflected in AC:H/AT:P): the attacker needs a valid, live internal target, the fetched response must be embeddable/readable from the returned DOCX word/media folder, and deployments that disable remote image fetching, egress-filter the server, or restrict HTML input are not exploitable.

This is a genuine but conditional priority rather than a drop-everything emergency. The CVSS 4.0 signals (AV:N, AC:H, AT:P, PR:N, UI:N) describe a remote, unauthenticated SSRF whose exploitation carries higher attack complexity and a specific attack requirement - the attacker must craft input that slips past the loose isValidUrl() check and must have a reachable, responsive internal/metadata target. Confidentiality impact is High (VC:H) while integrity and availability are None, consistent with a read-oriented SSRF that exfiltrates fetched responses into the generated DOCX. Publicly available exploit code exists (VulnCheck advisory plus a HackMD writeup), which raises practical risk and lowers the bar for opportunistic use. No EPSS score and no CISA KEV status were supplied in the input, so there is no evidence of active exploitation and no quantified exploitation probability - the elevated real-world concern here rests on the public POC, not on confirmed in-the-wild activity. Net: the public exploit and unauthenticated network vector justify prompt patching for anyone embedding this library in a server that processes untrusted HTML, but the AC:H/AT:P requirements and confidentiality-only impact mean it is not a wormable, mass-exploitable flaw.

An attacker submits HTML to a service that uses html-to-docx server-side, embedding an <img> tag whose src points at a loopback, RFC1918, or cloud metadata endpoint (e.g. 169.254.169.254). The server fetches that internal URL and embeds the response bytes into the word/media folder of the returned DOCX, letting the attacker read internal-only content such as cloud instance credentials. A public proof-of-concept and VulnCheck advisory exist, and because PR:N/UI:N no authentication or victim interaction is required, though AC:H/AT:P mean the attacker needs a reachable, responsive internal target.