CVE-2026-115758: SumatraPDF: TLS hostname validation disabled in `HttpGet()`
SumatraPDF is a multi-format reader for Windows. In version 3.6.1 and earlier, HttpGet() in src/base/Httpwin.cpp unconditionally passes INTERNETFLAGIGNORECERTCNINVALID to WinINet, disabling hostname matching for HTTPS update metadata and crash-symbol requests while retaining certificate-chain validation. A network-positioned attacker with a Windows-trusted certificate for an attacker-controlled domain can impersonate the project's update host, inject promo text and a clickable URL before update metadata validation, and provide an attacker-controlled archive to ExtractSymbols(). Installer replacement is not directly possible because HttpGetToFile() validates TLS and MaybeStartUpdateDownload() restricts the download host. No fixed version is available as of this review.
Event History
Frequently Asked Questions
Who is exposed to this issue?
Users of SumatraPDF 3.6.1 and earlier are exposed when the application makes affected HTTPS requests for update metadata or crash symbols over a network an attacker can intercept or influence. The attacker must have a certificate trusted by Windows for a domain they control.
Can this be used to replace the SumatraPDF installer or bypass the normal update-download host restriction?
No. Installer replacement is not directly possible through this issue because HttpGetToFile() performs TLS validation and MaybeStartUpdateDownload() restricts the download host.
What could an attacker change through the affected requests?
An attacker can impersonate the update host for affected metadata requests, inject promotional text and a clickable URL before update metadata validation, and supply an attacker-controlled archive to ExtractSymbols(). Certificate-chain validation still occurs; hostname matching is the validation that is disabled.
Is a fix available?
No fixed version was available as of the review.