CVE-2026-118372 in LibreSSL
Summary
by MITRE • 10/28/2026
LibreSSL ocspcheck through 4.4.0 contains a CRLF injection vulnerability that allows attackers to inject HTTP headers by embedding CR/LF sequences in a certificate's AIA OCSP URI path. Because url2host() copies the path without rejecting control characters and http_open() places it in the POST request line, attackers can inject headers or split OCSP requests sent to the responder host.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/28/2026
The vulnerability identified within LibreSSL versions up through 4.4.0 represents a critical input validation failure located specifically in the ocspcheck utility component. This flaw stems from an improper handling of data extracted from X.509 certificates, particularly concerning the Authority Information Access extension which contains OCSP responder Uniform Resource Identifiers. When the application processes these URIs to establish communication with the designated Online Certificate Status Protocol server, it fails to sanitize or validate the path portion of the URI against control characters such as carriage returns and line feeds. This lack of rigorous input filtering creates a direct pathway for attackers to manipulate the underlying HTTP protocol structure used by the client during the status check process.
The technical mechanism behind this vulnerability relies on the specific implementation details of two internal functions within LibreSSL, namely url2host and http_open. The url2_host function is responsible for parsing the URI provided in the certificate's AIA extension to extract host information and path components. In vulnerable versions, this function copies the entire path string into a buffer without performing any checks to reject or escape control characters like CR (carriage return) and LF (line feed). Subsequently, when http_open prepares the HTTP request for transmission, it constructs the POST request line using this unsanitized data. Because standard HTTP parsing logic interprets CRLF sequences as delimiters between headers and body content, an attacker can inject arbitrary header fields or terminate the initial request line prematurely to append additional malicious commands.
This capability allows a remote attacker who controls or influences the certificate presented during verification to perform HTTP header injection attacks against the OCSP responder host. By injecting specific headers, an attacker might attempt to manipulate how the server processes the request, potentially leading to cache poisoning if the response is cached by intermediate proxies, or facilitating cross-site scripting if the injected content reflects back in a web interface associated with the responder. Furthermore, splitting the OCSP request allows for protocol confusion attacks where the responder may interpret subsequent data as part of a new HTTP transaction rather than payload data intended for status checking. This breaks the integrity and confidentiality expectations of the TLS certificate validation process, potentially allowing an attacker to bypass revocation checks or cause denial-of-service conditions by sending malformed requests that crash or misbehave on the server side.
From a classification perspective, this vulnerability aligns with CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component and CWE-93 CRLF Injection. In terms of offensive security frameworks, it maps to ATT&CK technique T1589.002 Gather Victim Identity Information: Email Addresses which could be leveraged if the injection leads to information disclosure via server error messages or headers, although its primary impact is on protocol integrity and potential request manipulation. The core issue reflects a fundamental failure in secure coding practices regarding boundary validation of data originating from external sources before it interacts with system protocols.
Mitigation strategies for this vulnerability primarily involve upgrading LibreSSL to version 4.4.1 or later where the input sanitization logic has been corrected to reject control characters within URI paths used for OCSP requests. Organizations relying on automated certificate verification processes should ensure their libraries are updated promptly to prevent exploitation in production environments. Additionally, defensive coding practices such as strict allow-listing of permitted characters in URIs and implementing robust output encoding before passing data to HTTP client functions can serve as compensating controls if immediate patching is not feasible. Security teams should also monitor for anomalous traffic patterns from OCSP responders that might indicate attempted exploitation attempts involving malformed request lines or unexpected header injections.