CVE-2026-42765: OpenSSL Certificate Verification DoS Flaw

CVE-2026-42765 Overview

CVE-2026-42765 is a NULL pointer dereference vulnerability in OpenSSL's certificate verification code [CWE-476]. The flaw triggers when an application enables both X509_V_FLAG_OCSP_RESP_CHECK_ALL (OCSP response checking for the whole chain) and X509_V_FLAG_PARTIAL_CHAIN (partial-chain verification). If the verified chain lacks a self-signed trusted anchor, the issuer pointer becomes NULL for the last certificate, and dereferencing it crashes the process.

Critical Impact
An attacker who can influence the certificate chain presented to a vulnerable application can trigger a process crash, resulting in Denial of Service. FIPS modules are not affected because the vulnerable code lies outside the OpenSSL FIPS module boundary.

Affected Products

OpenSSL versions that include OCSP chain checking with partial-chain verification support
Applications explicitly enabling both X509_V_FLAG_OCSP_RESP_CHECK_ALL and X509_V_FLAG_PARTIAL_CHAIN
Non-FIPS OpenSSL deployments performing TLS certificate verification with OCSP

Discovery Timeline

2026-06-09 - OpenSSL publishes security advisory and patches
2026-06-09 - CVE-2026-42765 published to NVD
2026-06-10 - Last updated in NVD database

Technical Details for CVE-2026-42765

Vulnerability Analysis

The vulnerability resides in OpenSSL's X.509 certificate verification routine in crypto/x509/x509_vfy.c. When iterating through a verified certificate chain to perform OCSP response validation, the code retrieves each certificate's issuer using sk_X509_value(ctx->chain, i + 1). The implementation assumes the chain terminates in a self-signed root, so the loop expects an issuer certificate to always be available.

With partial-chain verification enabled, the chain can legitimately terminate at an intermediate trust anchor that is not self-signed. In that scenario, sk_X509_value(ctx->chain, i + 1) returns NULL for the last certificate. The subsequent call to check_cert_ocsp_resp(ctx) dereferences ctx->current_issuer and crashes the process.

Because TLS clients and servers using OpenSSL routinely process attacker-controlled certificate chains, an unauthenticated remote attacker can deliver a chain that triggers the crash. Both feature flags are disabled by default, which limits real-world exposure to applications that explicitly opt in.

Root Cause

The root cause is a missing NULL check on the issuer certificate returned during OCSP chain validation. The verifier conflates two assumptions: that a self-signed anchor terminates every chain, and that the issuer for any non-terminal certificate is always present at index i + 1. Partial-chain mode invalidates the first assumption without the OCSP code path accounting for it.

Attack Vector

The attack vector is network-based with no authentication or user interaction required. An attacker presents a crafted certificate chain to a vulnerable application during TLS or X.509 verification. If the application opts into both OCSP chain checking and partial-chain verification, processing the chain dereferences a NULL pointer and terminates the process.

            /* the issuer certificate is the next in the chain */
            ctx->current_issuer = sk_X509_value(ctx->chain, i + 1);
+            if (ctx->current_issuer == NULL) {
+                /*
+                 * No issuer exists at i+1 — this is the partial-chain
+                 * trust anchor. OCSP requires an issuer to build the
+                 * CertID, so skip OCSP checking for this certificate.
+                 */
+                if ((ctx->param->flags & X509_V_FLAG_PARTIAL_CHAIN) != 0)
+                    continue;
+                return verify_cb_ocsp(ctx, X509_V_ERR_OCSP_VERIFY_FAILED);
+            }

            ok = check_cert_ocsp_resp(ctx);

Source: OpenSSL commit 14340b7

The patch adds a NULL check on ctx->current_issuer. When partial-chain verification is enabled and no issuer exists, OCSP checking is skipped for that certificate; otherwise the verifier returns an OCSP verification failure through verify_cb_ocsp.

Detection Methods for CVE-2026-42765

Indicators of Compromise

Unexpected crashes or segmentation faults in processes linked against OpenSSL during TLS handshakes or certificate verification
Core dumps with stack frames inside x509_vfy.c, check_cert_ocsp_resp, or related OCSP routines
Repeated TLS connection terminations from a single client IP presenting unusual certificate chains
Application restarts or service unavailability events correlated with inbound TLS traffic

Detection Strategies

Audit application source and configuration for use of X509_V_FLAG_OCSP_RESP_CHECK_ALL combined with X509_V_FLAG_PARTIAL_CHAIN
Inventory OpenSSL versions across endpoints and servers and compare against the fixed releases listed in the OpenSSL advisory
Enable verbose TLS verification logging to capture chains that terminate without a self-signed anchor
Monitor process supervisors (systemd, container orchestrators) for abnormal restart rates of TLS-facing services

Monitoring Recommendations

Forward crash telemetry and core dump metadata to a central logging platform for correlation
Track outbound and inbound TLS error rates and alert on sudden spikes
Watch for repeated connection attempts presenting certificate chains with intermediate-only trust anchors
Correlate service crash events with the source IP and SNI of preceding TLS sessions

How to Mitigate CVE-2026-42765

Immediate Actions Required

Upgrade OpenSSL to the fixed version identified in the OpenSSL Security Advisory
Identify all applications that set both X509_V_FLAG_OCSP_RESP_CHECK_ALL and X509_V_FLAG_PARTIAL_CHAIN and prioritize their patching
Rebuild and redeploy any statically linked binaries that bundle vulnerable OpenSSL versions
Restart long-running services after library updates to ensure the patched code is loaded

Patch Information

The issue is fixed by upstream OpenSSL commits 14340b7 and eb345da. Both patches add a NULL check on ctx->current_issuer in crypto/x509/x509_vfy.c and either skip OCSP checking for the partial-chain trust anchor or return X509_V_ERR_OCSP_VERIFY_FAILED through verify_cb_ocsp. Refer to the OpenSSL Security Advisory for fixed version numbers and distribution-specific packages.

Workarounds

Disable X509_V_FLAG_OCSP_RESP_CHECK_ALL when partial-chain verification is required, or vice versa, until patches are applied
Restrict trusted anchors to self-signed root certificates so the partial-chain code path is not triggered
Place a patched TLS-terminating proxy in front of vulnerable services to filter malformed chains
Enforce strict certificate pinning where feasible to reduce exposure to attacker-controlled chains

bash

# Verify the installed OpenSSL version and confirm the patch level
openssl version -a

# On Debian/Ubuntu, update to the fixed package
sudo apt update && sudo apt install --only-upgrade openssl libssl3

# On RHEL/CentOS/Fedora
sudo dnf update openssl openssl-libs

# Restart services that link against OpenSSL
sudo systemctl restart nginx httpd postfix