Live › vulnerability › CVE-2026-118372
Go to dashboardLibreSSL's ocspcheck tool does not reject CR/LF characters in the path of a certificate's AIA OCSP URI, so the path is copied into the HTTP POST request line unchanged. An attacker who controls a certificate can inject extra HTTP headers or split the OCSP request sent to the responder host.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-28 03:31 UTC. All times on this page are UTC.
Systems that run LibreSSL's ocspcheck utility through 4.4.0 on certificates that come from untrusted sources, since the attacker-controlled value is the OCSP URI inside the certificate. The sources do not describe whether applications linking the LibreSSL library are affected, so that is unknown. Teams that do not run ocspcheck can likely skip it.
No product ranges from the sources yet.
ocspcheck -V or ocspcheck with no arguments to see the installed LibreSSL version, and compare it with the fixed release in the sources (unknown)which ocspcheck4.4.0 once a fixed release is published (fixed version unknown from the sources)Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-118372")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.