OpenSSL: TLS/DTLS clients using raw public keys may not fail the handshake when the server is unauthenticated

Impact

A client that authenticates a server by RFC7250 raw public key instead of an X.509 chain can complete the handshake even when the server's RPK matches none of the expected keys, because SSL_VERIFY_PEER does not abort as the caller expects. Anything in a position to intercept that connection can present its own key and be accepted, so a channel the operator believes is mutually pinned is open to man-in-the-middle. On a fleet this matters where RPK is used for machine-to-machine links - internal control-plane, telemetry and storage clients that pin a key rather than run a PKI - and it fails silently: there is no error, only a trusted session that was never authenticated. Exposure is narrow: RPK is off by default on both ends, so only deployments that explicitly enabled server-side RPK and rely on handshake failure are affected, and callers that check SSL_get_verify_result() and act on it are not. Introduced with the original RPK implementation in OpenSSL 3.2.

Who can reach it

A network attacker able to intercept or redirect the TLS/DTLS connection between an affected client and its server - no credentials needed, since the point of the flaw is that the attacker's key is accepted. Requires the deployment to have turned RPK on for the server side.

What to do

Update the OpenSSL packages on affected hosts and restart every daemon linked against the library; long-lived processes keep the vulnerable code until they are restarted. The OpenSSL advisory of 2025-02-11 (linked) names the fixed releases on the 3.2, 3.3 and 3.4 branches - check it against your branch rather than assuming. FIPS modules in 3.0 through 3.4 are not affected. Where patching has to wait, either disable server-side RPK or have the client call SSL_get_verify_result() and tear the connection down on failure. No reboot or firmware work is involved.

References

Related entries

• QEMU: missing iov bounds check in the virtio-snd input callback gives a guest a heap out-of-bounds writeCVE-2026-3195 · QEMU virtio-snd device (virtio_snd_pcm_in_cb input callback)High
• Linux kernel (arch/x86/kvm/svm): After a CPU offline/online cycle, KVM's ASID generation counter is reset in a way thatCVE-2026-68093 · Linux kernel (arch/x86/kvm/svm)High
• Linux kernel vhost: wrong avail-index return value lets a stalled guest livelock the hostCVE-2026-74356 · Linux kernel vhost (vhost_get_avail_idx return value, vhost-net mergeable buffers)High
• Linux kernel Tegra241 CMDQV: SMMU probe failure dereferences the freed smmu structCVE-2026-90427 · Linux kernel iommu/tegra241-cmdqv (SMMU devm_krealloc fallback path)High
• Linux kernel (net/xfrm): A qdisc that reuses skbCVE-2023-53500 · Linux kernel (net/xfrm)High
• Linux kernel (arch/x86/kvm/vmx): With adaptive PEBS exposed, KVM never guaranteed that LBR MSRs held guest valuesCVE-2024-26992 · Linux kernel (arch/x86/kvm/vmx)High