CVE-2026-118371 in LibreSSL
Summary
by MITRE • 10/28/2026
LibreSSL through 4.4.0 contains a CRLF injection vulnerability in the libcrypto OCSP_sendreq_new() and OCSP_parse_url() functions, which write unvalidated request paths into the OCSP POST request line. Attackers can embed carriage return and line feed characters in a certificate's Authority Information Access OCSP URI to inject HTTP headers or split requests sent to responders and proxies.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/28/2026
LibreSSL versions through 4.4.0 are affected by a critical CRLF injection vulnerability located within the libcrypto library, specifically impacting the OCSP_sendreq_new() and OCSP_parse_url() functions. This security flaw arises from an insufficient validation of user-supplied input when processing Online Certificate Status Protocol (OCSP) Uniform Resource Identifiers. The core technical deficiency lies in the failure to sanitize or escape special characters within the request path components extracted from certificate extensions before they are incorporated into HTTP POST requests. When a maliciously crafted X.509 certificate is processed, the Authority Information Access extension may contain an OCSP responder URI that includes carriage return and line feed sequences encoded as percent-encoded strings or raw control characters. The vulnerable functions in LibreSSL fail to detect these sequences during URL parsing, allowing them to pass through into the construction of the HTTP request header and body boundaries without proper encoding or rejection.
The operational impact of this vulnerability is significant because it allows an attacker to manipulate the structure of HTTP requests sent to OCSP responders and intermediate proxies. By injecting CRLF characters, an adversary can effectively split a single HTTP transaction into multiple distinct messages. This capability enables several malicious outcomes, including header injection where additional headers such as Content-Type or Authorization are inserted prematurely, potentially altering how the server processes the request. Furthermore, it facilitates response splitting attacks where the attacker can inject arbitrary content after the injected line breaks, which may be cached by proxies and served to other users under false pretenses. In more severe scenarios, this could lead to HTTP Request Smuggling if the front-end and back-end servers interpret the malformed boundaries differently, potentially allowing session hijacking or cache poisoning attacks against downstream services that rely on OCSP stapling for certificate validation.
This vulnerability aligns with CWE-93, which categorizes improper neutralization of CRLF sequences in HTTP headers as a distinct weakness type often referred to as CRLF Injection. From an offensive security perspective, the exploitation technique maps closely to ATT&CK T1071 Application Layer Protocol, specifically sub-techniques involving web protocols like HTTP or HTTPS, where attackers manipulate protocol fields to bypass controls or inject malicious payloads. The attack vector typically involves distributing a compromised certificate through phishing emails, drive-by downloads, or man-in-the-middle attacks on unencrypted connections, requiring the victim system to validate the certificate via OCSP using LibreSSL as part of its TLS handshake process.
Mitigation strategies should prioritize immediate upgrading to LibreSSL version 4.5.0 or later, where this input validation flaw has been addressed by implementing strict sanitization routines that reject any URI components containing non-printable characters or CRLF sequences before they are used in HTTP request construction. Organizations relying on OCSP stapling must also ensure their certificate management processes filter out certificates with suspicious Authority Information Access extensions during ingestion. Additionally, deploying Web Application Firewalls configured to detect and block anomalous HTTP header structures can provide a layer of defense against exploitation attempts targeting unpatched systems while updates are being deployed across the infrastructure.