Issue summary: In a server or client configuration with RFC7250 Raw Public Keys

CVE-2026-14457 is a NULL pointer dereference (CWE-476) in OpenSSL's RFC 7250 Raw Public Key (RPK) implementation. When a TLS server is configured with only a private key and no associated certificate — a valid but extremely uncommon RPK-only setup — and a connecting peer sends the signature_algorithms_cert TLS extension, OpenSSL dereferences a NULL certificate pointer and the process crashes. Affected versions span OpenSSL 4.0.0–4.0.1, 3.6.0–3.6.3, 3.5.0–3.5.7, and 3.4.0–3.4.6. Fixed in 4.0.2, 3.6.4, 3.5.8, and 3.4.7 respectively. Older branches (3.0.x, 1.1.1, 1.0.2) are unaffected — RPK support was introduced in OpenSSL 3.2 but the vulnerable code path only appears in 3.4+.

The CVSS:3.1 vector scores 7.5 HIGH because it sees network-reachable, no-auth, no-interaction DoS — and mechanically that is correct. But the OpenSSL project itself rates this Low, and they are right. The CVSS score completely ignores the deployment prerequisite: RPK is disabled by default in both clients and servers, and the crash only fires when the server has *no certificate at all* — just a bare private key. In practice this configuration exists almost exclusively in IoT prototyping and academic RFC 7250 test beds. The vendor HIGH label (if derived purely from CVSS) dramatically overstates the real-world risk.

Why this verdict

• Precondition rarity: RPK is disabled by default in all OpenSSL builds. The server must explicitly enable RPK *and* omit any certificate — a configuration the OpenSSL documentation itself discourages. This alone eliminates >99.9% of OpenSSL deployments from the attack surface.
• Impact ceiling is DoS only: CWE-476 NULL pointer dereference results in a process crash. No memory corruption, no RCE path, no data leak. CVSS C:N/I:N/A:H confirms this. Process supervisors restart the service in seconds.
• Role multiplier: OpenSSL is ubiquitous, but the *affected configuration* (RPK-only, no cert) is not. Web servers, load balancers, API gateways, reverse proxies, VPN concentrators, and every other high-value TLS role always configure certificates. The RPK-only path is used in IoT prototyping and RFC 7250 interop testing. No high-value enterprise role canonically runs RPK-only, so the blast-radius floor does not elevate the verdict.
• OpenSSL project agrees: The vendor's own severity assessment is Low, not High. The 7.5 CVSS is a mechanical artifact of the AV:N/AC:L/PR:N/UI:N vector that ignores real-world deployment context.

Why not higher?

There is no realistic path to exploiting this at scale. The vulnerable configuration is opt-in, rare, and discouraged. Even successful exploitation yields only a transient process crash — no lateral movement, no persistence, no data access. Elevating to MEDIUM would require either evidence of real-world RPK-only deployments in production or exploitation in the wild, neither of which exists.

Why not lower?

We do not drop to IGNORE because the vulnerability is real, the fix is available, and organizations running IoT or embedded TLS stacks *might* use RPK-only configurations. Additionally, the CVE is only one day old — exploitation status could change, warranting a LOW rather than outright dismissal.

1. Audit for RPK-only server configurations — Search your OpenSSL-linked services for calls to RPK enablement APIs (SSL_set1_server_raw_public_key or equivalent config directives) where no certificate is loaded. If you find none — and you almost certainly will not — this CVE does not affect you. Complete this audit within the noisgate remediation window for LOW (backlog).
2. Add a certificate to any RPK-enabled server — If you do find an RPK-only server, pair it with a self-signed or CA-signed certificate. This prevents the NULL dereference entirely because the certificate pointer will be populated. This is the OpenSSL-recommended configuration regardless of this CVE.
3. Ensure process supervision is active — Confirm that all OpenSSL-based services run under systemd, Docker, or Kubernetes with automatic restart policies. This limits DoS impact to a brief blip even if the crash is triggered.

Run this on any host where you want to check the installed OpenSSL version. No special privileges required. Example: bash check_cve_2026_14457.sh

#!/usr/bin/env bash
# check_cve_2026_14457.sh — Check OpenSSL version for CVE-2026-14457
# Affected: 3.4.0-3.4.6, 3.5.0-3.5.7, 3.6.0-3.6.3, 4.0.0-4.0.1
# Fixed:    3.4.7, 3.5.8, 3.6.4, 4.0.2
# Exit 0 = PATCHED, Exit 1 = VULNERABLE, Exit 2 = UNKNOWN

set -euo pipefail

VERSION=$(openssl version 2>/dev/null | awk '{print $2}') || { echo "UNKNOWN — openssl not found"; exit 2; }

# Parse major.minor.patch
IFS='.' read -r MAJOR MINOR PATCH <<< "$(echo "$VERSION" | sed 's/[^0-9.]//g')"

if [[ -z "$MAJOR" || -z "$MINOR" || -z "$PATCH" ]]; then
  echo "UNKNOWN — could not parse version: $VERSION"
  exit 2
fi

vulnerable=0

# Check each affected branch
if [[ $MAJOR -eq 4 && $MINOR -eq 0 && $PATCH -le 1 ]]; then
  vulnerable=1
elif [[ $MAJOR -eq 3 && $MINOR -eq 6 && $PATCH -le 3 ]]; then
  vulnerable=1
elif [[ $MAJOR -eq 3 && $MINOR -eq 5 && $PATCH -le 7 ]]; then
  vulnerable=1
elif [[ $MAJOR -eq 3 && $MINOR -eq 4 && $PATCH -le 6 ]]; then
  vulnerable=1
fi

if [[ $vulnerable -eq 1 ]]; then
  echo "VULNERABLE — OpenSSL $VERSION is affected by CVE-2026-14457"
  echo "NOTE: Only exploitable if RPK is enabled WITHOUT a certificate."
  exit 1
else
  echo "PATCHED — OpenSSL $VERSION is not affected (or not in an affected branch)"
  exit 0
fi

Sources

1. OpenSSL Vulnerabilities (3.5 branch)
2. OpenSSL 4.0.2 Patches 11 Vulnerabilities — LinuxCompatible
3. OpenSSL RPK Support Announcement (2023)
4. CWE-476: NULL Pointer Dereference
5. OpenSSL GitHub Releases
6. Canadian Centre for Cyber Security — OpenSSL Advisory AV26-058
7. OpenSSL Security Advisory (openssl-users)