CVE-2026-42765: OpenSSL NULL Pointer Dereference in OCSP Certificate Chain Verification

Technical summary

The vulnerability is a NULL pointer dereference (CWE-476) in OpenSSL's certificate verification logic. When processing OCSP responses for a certificate chain, the code iterates through certificates to check each against its issuer. A safety check exists for self-signed certificates, but fails when partial-chain verification is enabled and the verified chain terminates without a self-signed trusted anchor. The final certificate in the chain has no issuer to reference, resulting in a NULL pointer being dereferenced. The FIPS module is unaffected because the vulnerable code lies outside its boundary.

Business impact

Organizations running applications that enable both X509_V_FLAG_OCSP_RESP_CHECK_ALL and X509_V_FLAG_PARTIAL_CHAIN face potential service unavailability. A remote, unauthenticated attacker can trigger a crash by presenting a certificate chain that meets the specific conditions (no self-signed root, OCSP checking enabled). This translates to denial of service for any application processing such certificates—particularly relevant for TLS endpoints, API servers, and certificate validation services. The attack requires no user interaction and can be delivered over the network.

Affected systems

OpenSSL versions affected by this issue have not been explicitly specified in the provided vulnerability data. The vulnerability impacts only applications compiled against OpenSSL that explicitly enable both partial-chain verification (X509_V_FLAG_PARTIAL_CHAIN) and OCSP response checking for the full chain (X509_V_FLAG_OCSP_RESP_CHECK_ALL). These settings are non-default, limiting the population of affected deployments. Verify the specific OpenSSL versions and application configurations against the official OpenSSL security advisory.

Exploitability

The exploit is trivial to execute: a remote attacker simply presents a specially crafted certificate chain during a TLS handshake or certificate validation API call. No authentication, user interaction, or local access is required. The network attack vector (AV:N), low attack complexity (AC:L), and lack of privilege requirements (PR:N) make this readily exploitable. However, the practical attack surface depends on whether target applications have enabled both non-default verification flags. The absence of this vulnerability from the CISA Known Exploited Vulnerabilities (KEV) catalog suggests no active exploitation has been cataloged to date.

Remediation

Apply the OpenSSL security patch as soon as it becomes available from the OpenSSL project. Pending patch availability, immediately audit your applications to determine whether both X509_V_FLAG_OCSP_RESP_CHECK_ALL and X509_V_FLAG_PARTIAL_CHAIN are enabled. If both are active, either disable partial-chain verification or disable OCSP chain checking until a patch is deployed. Review whether partial-chain verification is actually necessary for your use case; in many deployments, it is not. Ensure your OpenSSL dependency is kept current as part of routine patch management.

Patch guidance

Monitor the OpenSSL security advisory page (openssl.org/news/secadv) for the specific patch release addressing CVE-2026-42765. Verify the patch version number and applicability to your OpenSSL version before deployment. Test patches in a non-production environment, particularly if your applications rely on partial-chain verification for legitimate business logic. Update your build and deployment pipelines to incorporate the patched OpenSSL version. If using OpenSSL through a third-party distribution or container image, confirm that your vendor or maintainer has released an updated package.

Detection guidance

Monitor application logs for NULL pointer dereference crashes or segmentation faults during certificate validation operations. If using OpenSSL compiled with debugging symbols, core dumps may indicate a crash in the X509 verification code path. Network-based detection is difficult because the malicious input (a crafted certificate chain) appears as normal TLS traffic; focus on application behavior monitoring and crash analysis. Consider enabling verbose logging in applications that perform certificate verification to track unusual certificate chain patterns (e.g., chains without self-signed roots when partial-chain verification is active).

Why prioritize this

Despite a CVSS score of 7.5 (HIGH severity), real-world risk is moderate due to the requirement for both non-default verification flags to be simultaneously enabled. Prioritize this vulnerability for organizations that have explicitly enabled partial-chain verification in production applications—common in some enterprise PKI deployments and certificate pinning scenarios. Organizations using OpenSSL in default configurations face minimal risk. The lack of KEV catalog inclusion and reported exploitation suggests this is not an imminent threat, but the remote, unauthenticated exploit path warrants prompt patching once fixes are available.

Risk score, explained

The CVSS 3.1 score of 7.5 reflects the high exploitability (remote, no authentication required, low complexity) and guaranteed availability impact (crash). However, this score does not account for the reduced environmental severity due to the requirement for both non-default flags. The vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H correctly shows no confidentiality or integrity impact, only availability. Organizations should apply their own risk modifiers based on whether affected flag combinations are present in their deployments.

Frequently asked questions