CVE-2026-42765

What it actually does

This flaw is a NULL pointer dereference in OpenSSL certificate verification logic. It is reachable only when an application explicitly enables both partial-chain verification and OCSP response checking for the entire certificate chain using X509_V_FLAG_PARTIAL_CHAIN and X509_V_FLAG_OCSP_RESP_CHECK_ALL. In that configuration, OpenSSL may attempt to treat a non-existent next certificate as the issuer for the final certificate in a chain that does not end in a self-signed trusted anchor. The resulting NULL dereference crashes the calling process, causing denial of service. The issue does not affect default OpenSSL verification settings and is outside the OpenSSL FIPS module boundary.

Why it matters to the business

An affected service or application can be remotely crashed if it validates attacker-controlled certificates with the uncommon combination of partial-chain verification and full-chain OCSP checking. The practical risk is concentrated in products that perform mutual TLS, outbound TLS inspection, certificate enrollment, proxying, mail/security gateway processing, or other automated certificate validation against untrusted peers. Although the CVSS availability impact is high, the real-world likelihood is reduced because both required verification flags are disabled by default, EPSS is low and flat, no public exploit maturity is reported, and the issue is not in CISA KEV.

How an attack unfolds

An attacker first identifies an application that uses OpenSSL for certificate validation and that has enabled both partial-chain verification and OCSP response checking across the full chain. The attacker then causes that application to validate a crafted or unusual certificate chain that is accepted as a partial chain but does not include a self-signed trusted anchor. During OCSP response checking, OpenSSL walks the verified chain and tries to access the issuer certificate for each certificate. For the final certificate in this partial chain, there is no next issuer certificate. The vulnerable code dereferences that missing issuer pointer, crashing the process. Depending on where OpenSSL is used, the attacker may deliver the chain by connecting to a mutually authenticated TLS service, luring a client or scanner to connect to an attacker-controlled TLS endpoint, submitting a certificate to a validation workflow, or otherwise triggering automated certificate verification.

How to fix it

Apply the vendor-provided OpenSSL update for CVE-2026-42765 as soon as fixed packages are available for the operating system, appliance, container image, language runtime, or embedded product in use. No exact upstream fixed version was provided in the input, so track the relevant OpenSSL and downstream vendor advisories for the corrected package version. Where immediate patching is not possible, reduce exposure by disabling one of the two required verification modes: avoid X509_V_FLAG_OCSP_RESP_CHECK_ALL, avoid X509_V_FLAG_PARTIAL_CHAIN, or limit OCSP checks to the leaf certificate if that is operationally acceptable. Ensure certificate validation paths terminate in an expected trusted anchor before full-chain OCSP checking is attempted. For services exposed to untrusted certificate chains, add process supervision, rate limiting, and crash-restart controls to reduce operational impact. FIPS module replacement alone is not a mitigation, because the vulnerable logic is outside the OpenSSL FIPS module boundary.

How to confirm the fix worked

Confirm whether deployed applications link to or bundle an affected OpenSSL build, including statically linked binaries, containers, appliances, language runtimes, and third-party products. Review source code and configuration for simultaneous use of X509_V_FLAG_PARTIAL_CHAIN and X509_V_FLAG_OCSP_RESP_CHECK_ALL. Validate vendor package versions against the relevant OpenSSL or downstream advisory once fixed versions are published. In a controlled test environment, exercise certificate verification with a partial chain that lacks a self-signed trusted anchor and full-chain OCSP checking enabled; a fixed build should reject or handle the chain without crashing. Operationally, confirm that affected services remain stable under malformed or incomplete certificate-chain validation attempts and that crash logs no longer show OpenSSL-adjacent NULL dereference failures during certificate verification.

Typical attack path

1. Find an application or service that uses OpenSSL certificate verification with both X509_V_FLAG_PARTIAL_CHAIN and X509_V_FLAG_OCSP_RESP_CHECK_ALL enabled.
2. Prepare or obtain a certificate chain that can be processed as a partial chain but does not end with a self-signed trusted anchor.
3. Present the chain through a supported protocol or workflow, such as TLS, mutual TLS, certificate submission, proxy inspection, or automated certificate scanning.
4. Trigger OpenSSL full-chain OCSP response checking during certificate verification.
5. Cause OpenSSL to dereference a NULL issuer pointer for the last certificate in the partial chain.
6. Crash the affected process and create a denial-of-service condition until the process is restarted or traffic is blocked.

How to detect it

There are no reliable CVE-specific indicators proving exploitation because the observable result is a process crash during certificate validation. To assess possible prior exploitation, review application logs, system journals, crash reporters, core dump directories, container restart events, load balancer health-check failures, and TLS/mTLS gateway logs for crashes or restarts that correlate with certificate-validation activity, OCSP checking, or inbound/outbound TLS handshakes from untrusted peers. On Linux, inspect kernel logs and systemd journals for segmentation faults in processes linked to OpenSSL around the time of failed TLS sessions. In containerized environments, review orchestrator restart counts, OOM-independent exits, and stderr logs for abrupt termination after certificate parsing or OCSP validation. If core dumps are available, confirm whether the crashing thread is in OpenSSL certificate verification or OCSP response checking code. Network logs may show repeated TLS sessions, client-certificate presentations, or scanner-like behavior immediately before crashes, but the certificate chain itself is often required for confirmation. Also perform exposure detection by searching code and configuration for X509_V_FLAG_PARTIAL_CHAIN and X509_V_FLAG_OCSP_RESP_CHECK_ALL used together.

What your security team should do

• Prioritize inventory of internet-facing and security-critical services that validate untrusted certificates using OpenSSL, especially mTLS gateways, proxies, scanners, mail gateways, certificate enrollment systems, and TLS inspection components.
• Search code and configuration repositories for X509_V_FLAG_PARTIAL_CHAIN and X509_V_FLAG_OCSP_RESP_CHECK_ALL used together; treat matches as the highest-priority exposure candidates.
• Patch OpenSSL through the appropriate OS, container, appliance, or application vendor channel when fixed builds become available, including products that statically bundle OpenSSL.
• If patching is delayed, disable full-chain OCSP checking or partial-chain verification where business requirements allow, and document any temporary validation behavior change.
• Increase monitoring for repeated process crashes, core dumps, or service restarts following TLS handshakes or certificate-validation workflows.
• Use compensating controls such as connection rate limits, isolation of certificate-validation services, and automatic process recovery for exposed services.
• Because the issue is not currently KEV-listed, has low EPSS, and has no reported exploit maturity, prioritize based on exposure and use of the two required OpenSSL flags rather than OpenSSL presence alone.