CVE-2026-118373 in LibreSSL
Summary
by MITRE • 10/28/2026
LibreSSL ocspcheck through 4.4.0 contains a cleartext transmission vulnerability because url2host() discards the OCSP URL scheme and http_alloc() only selects TLS for port 443. On-path network attackers can read OCSP requests sent to https responder URLs on non-443 ports, exposing certificate serial numbers, issuer hashes, and nonces.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability in LibreSSL versions through 4.4.0 represents a critical flaw in the implementation of Online Certificate Status Protocol (OCSP) checking mechanisms, specifically within the url2host function and subsequent HTTP allocation logic. OCSP is an essential internet protocol used to check the revocation status of X.509 digital certificates without relying on slower or less reliable Certificate Revocation Lists. The core technical flaw stems from how LibreSSL parses and handles URLs provided for OCSP responders. When a URL containing an explicit scheme, such as https://, is processed by the url2host function, it incorrectly discards the scheme information entirely. This loss of protocol context means that subsequent functions lack awareness of whether secure transport was originally intended or required by the configuration.
Following this parsing error, the http_alloc function determines how to establish a connection based solely on the port number specified in the URL rather than any prior security directives. The logic dictates that TLS encryption is only enabled if the target port is explicitly 443. Consequently, when an OCSP responder URL specifies https but utilizes a non-standard port such as 8080 or 9443, the application fails to initiate a secure connection. Instead of negotiating Transport Layer Security (TLS), LibreSSL defaults to sending the request over plain text HTTP. This behavior creates a direct pathway for cleartext transmission of sensitive security data that was intended to be protected by encryption.
The operational impact of this vulnerability is significant because OCSP requests contain highly sensitive information regarding digital certificate lifecycles and identities. An attacker positioned on the network path between the client and the OCSP responder can intercept these unencrypted packets using standard packet sniffing techniques. By analyzing the captured traffic, the adversary gains access to specific details including the serial numbers of certificates being checked, hashes identifying the issuing Certificate Authorities, and unique nonces generated for each request. This exposure facilitates several malicious activities, most notably certificate tracking and user profiling. Attackers can correlate these data points across multiple sessions to build detailed profiles of which websites or services a particular system is accessing, effectively compromising privacy even if the actual web traffic remains encrypted via TLS.
Furthermore, this vulnerability undermines the integrity of the PKI trust model by allowing potential man-in-the-middle attacks where an adversary could modify OCSP responses in transit. Although the primary risk highlighted here is confidentiality loss through eavesdropping, the lack of encryption also opens the door to response manipulation if combined with other network-level exploits. This aligns closely with CWE-319, which classifies cleartext transmission of sensitive information as a critical weakness. From an offensive security perspective, this behavior maps directly to ATT&CK technique T1048, specifically subtechnique 002 for Exfiltration Over Alternative Protocol, where attackers leverage non-standard ports and protocols to evade detection by traditional network monitoring tools that may not inspect traffic on uncommon ports or assume all OCSP traffic is secure.
Mitigation strategies must address both the immediate code defect and broader architectural assumptions about URL handling. The primary remediation involves upgrading LibreSSL to version 4.5.0 or later, where this parsing logic has been corrected to respect the scheme specified in the URL regardless of the port number. For environments unable to upgrade immediately, administrators should ensure that OCSP responder URLs strictly use standard ports such as 80 for HTTP and 443 for HTTPS if cleartext is acceptable, though relying on non-standard ports with https schemes remains risky until patched. Additionally, organizations can implement network-level controls such as deep packet inspection or firewall rules to monitor traffic on common alternative OCSP ports like 8080 for anomalies indicative of data exfiltration. It is also advisable to review application configurations that define OCSP endpoints and ensure they adhere to standard port conventions to minimize the attack surface associated with this parsing ambiguity.