OpenSSL CVE-2026-14457

Exploitation requires that the targeted endpoint be explicitly configured for RFC7250 Raw Public Key mode with only a private key loaded and no accompanying certificate - this is a non-default configuration that must be deliberately enabled by an operator. The vendor notes this mode is supported but not recommended; the best-practice RPK configuration (key plus certificate) is fully immune. In addition, RPK negotiation must be active for the relevant side (server cert type or client cert type set to RPK). On the attacker side, no authentication is required and no special timing or race condition is needed - sending the signature_algorithms_cert extension in a standard TLS handshake is sufficient. The limiting factors for defenders: most OpenSSL deployments use certificates and are entirely unaffected; RPK deployments with a paired certificate are unaffected; only the deliberate key-only subset is at risk.

The CVSS 7.5 base score (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) accurately reflects that no authentication is required and the attack is network-accessible, but substantially overstates practical risk for most environments. The critical limiting factor is configuration: only deployments explicitly using RFC7250 RPK in key-only mode - a non-default, administratively deliberate choice - are vulnerable. The vendor explicitly states that the standard best-practice configuration (private key plus certificate, even self-signed) is unaffected. SSVC rates exploitation as 'none' with partial technical impact, consistent with the constrained attack surface. Despite being marked Automatable:Yes (a single crafted ClientHello or TLS 1.3 CertificateRequest suffices), the exploitable population is narrow. No EPSS score was provided in the input data, so exploitation probability cannot be quantified numerically. There is no KEV listing and no known public exploit. For organizations that have deliberately deployed key-only RPK - a reasonable choice for certain pinning-based or DANE-based use cases - this is a genuine availability risk against any network-reachable TLS endpoint and should be patched promptly.

A remote unauthenticated attacker who identifies an OpenSSL TLS endpoint operating in key-only RPK mode sends a ClientHello (TLS 1.2/1.3) or a TLS 1.3 CertificateRequest containing the signature_algorithms_cert extension - an extension that OpenSSL itself does not emit by default and most implementations omit. When OpenSSL's check_cert_usable() processes this extension against the key-only credential slot, it dereferences the NULL certificate pointer and the application aborts. No public exploit code has been identified, but the four fix commits provide sufficient technical detail to reconstruct the triggering condition.