LibreSSL CRLF Injection and Transport Flaws

Memory exhaustion in LibreSSL's ocspcheck command-line utility (versions through 4.4.0) lets an attacker who controls the OCSP responder named in a certificate's AIA extension, or who can intercept plaintext HTTP OCSP traffic, deny certificate status checks by streaming unbounded response headers or body data. The victim must actually run ocspcheck against the hostile or intercepted responder, so this is a conditional, position-dependent flaw rather than something triggerable against arbitrary Internet hosts, and the impact is availability-only with no confidentiality or integrity effect. No public exploit code and no CISA KEV entry are associated with this CVE at time of analysis; the vendor has published upstream fixes, and the mixed signals (High headline severity versus a required on-path/responder-control precondition) point to moderate, conditional risk.

LibreSSL's libcrypto OCSP client (through 4.4.0) writes an unvalidated request path into the HTTP POST request line, so carriage-return and line-feed characters embedded in a certificate's Authority Information Access OCSP URI are passed through into OCSP traffic, allowing header injection or request splitting toward a responder or proxy. Applications are exposed only if they use OCSP_sendreq_new()/OCSP_parse_url(), have OCSP revocation checking enabled, and actually query a URI taken from an attacker-supplied certificate; the resulting impact is integrity-limited with no confidentiality or availability effect. This is a moderate-severity issue rather than an emergency, no public exploit was identified at time of analysis, and the upstream commit d3f7195f rejects URI paths containing control or non-ASCII characters.

LibreSSL's ocspcheck utility (through 4.4.0) can transmit OCSP requests in cleartext when an OCSP responder URL uses the https scheme on a TCP port other than 443: url2host() discards the URL scheme and http_alloc() decides TLS solely on whether the port equals 443. An on-path attacker in a position to read the traffic can then observe the leaked OCSP request metadata - certificate serial numbers, issuer hashes and nonces - but cannot modify it. Exposure requires a non-default configuration (https responder URL on a non-443 port) and a passive network position, so severity is limited to low-confidentiality metadata disclosure; exploit code is not confirmed, and the issue is not listed as actively exploited.

HTTP header injection in LibreSSL's ocspcheck utility (through 4.4.0) lets a certificate-borne CR/LF sequence in the AIA OCSP URI path be carried into the POST request line sent to the OCSP responder, allowing injected headers or request splitting. The attacker does not reach the code directly: exploitation requires the victim to run ocspcheck against an attacker-supplied certificate whose AIA URI path contains control characters, which is why the assessed severity is moderate (CVSS 4.0 base 6.3, CVSS 3.1 AV:N/AC:H/PR:N/UI:N with integrity-only impact). No public exploit code and no confirmed active exploitation were identified at time of analysis, and impact is limited to the integrity of HTTP traffic toward the responder host, with no confidentiality or availability effect.