OpenSSL 4.0.3, 3.6.5 and 3.5.9: A High‑Severity Batch Across DTLS, QUIC and Side Channels

If your software terminates TLS, DTLS or QUIC with OpenSSL on one of these branches, plan the upgrade now. The release notes do not say which individual CVE carries the High rating. Until your own review shows otherwise, treat the whole batch as High priority.

This analysis groups the fixes by subsystem, sets out what differs between branches, and explains how to work out whether a deployment is exposed. It stays within what the three release pages state. Any comment on likely impact is labelled as interpretation.

One Shared Fix List, Two Extras for 4.0 #

The three release notes are nearly identical. 3.6.5 and 3.5.9 list the same thirteen CVEs and the same AES-SIV fix. 4.0.3 includes all of that plus CVE-2026-84783 and the base64 BIO regression fix.

Because the list is shared, running an older line is no reason to wait. All three branches covered here need the same response: move to the patched release on your branch.

DTLS: stale retransmissions and undersized records #

Two DTLS issues appear on every branch. CVE-2026-84782 fixes DTLS retransmissions of handshake messages that were sent from a stale buffer offset. DTLS runs over datagrams and must resend lost handshake flights, so this code runs whenever packets are dropped. The notes do not describe the consequence of the stale offset, and readers should not assume a particular outcome.

CVE-2026-75806 is described as an unauthenticated and undersized DTLS 1.2 AEAD record that causes denial of service. Interpretation: the word "unauthenticated" suggests the record does not need to pass integrity checks to trigger the problem. That would make the flaw reachable by a remote peer, so internet-facing DTLS 1.2 services are the natural first priority.

QUIC: five resource and accounting bugs #

The QUIC stack has the largest group of fixes:

• CVE-2026-35191: unvalidated amplification credit could be over-accounted.
• CVE-2026-42772: fragment reassembly had O(n^2) cost, a potential CPU denial of service.
• CVE-2026-54873: a denial of service involving STREAM fragment metadata.
• CVE-2026-75804: connection-level flow control was not enforced for streams.
• CVE-2026-84784: the RETIRE_CONNECTION_ID backlog was unbounded.

Interpretation: taken together, these descriptions point to several ways a peer could drive CPU, memory or outbound traffic beyond the limits OpenSSL's QUIC implementation is meant to enforce. Amplification credit, flow control and backlog limits all exist to bound what an untrusted peer can make an endpoint do. Endpoints that accept QUIC connections through OpenSSL have strong reason to patch early.

Constant-time failures in EC and SM2 #

Three fixes concern timing behaviour:

• CVE-2026-54872: a timing side channel in scalar multiplication for what the notes call "mon-NIST" EC curves. This is probably a typo for non-NIST, but the notes do not confirm that.
• CVE-2026-54875: SM2 scalar multiplication was not constant time on ARM64 and RISC-V.
• CVE-2026-77696: a timing side channel in SM2 signature generation.

Interpretation: timing leaks in scalar multiplication and signing are the kind of flaw that can, in principle, help an attacker learn about private keys. How practical that is usually depends on how precisely an attacker can measure timing, and the notes do not discuss this. CVE-2026-54875 is limited to particular architectures. It is a reminder that ARM64 and RISC-V deployments need their own assessment rather than inheriting conclusions drawn from other platforms.

Certificates, CRL distribution points and CMP #

CVE-2026-35189 fixes excessive memory allocation in relative CRLDP processing. Interpretation: software that processes certificates or revocation data from parties it does not control is the most likely to reach this path.

CVE-2026-75805 fixes a NULL pointer dereference in the CMP client's handling of revocation responses. It matters to deployments that use OpenSSL's CMP client.

Only the 4.0.3 notes list CVE-2026-84783, a use-after-free in the X.509 extension cache under concurrent use. Interpretation: because the description requires concurrent use, multi-threaded applications on 4.0 are the ones to examine first.

Context switching mid-handshake #

CVE-2026-72897 is an out-of-bounds access after SSL_set_SSL_CTX() is called during a handshake. The function name makes this one easy to scope. Search your own code and your dependencies for calls to SSL_set_SSL_CTX(). If you find any made during a handshake, give this fix priority.

AES-SIV: a silent authentication failure #

All three releases fix a bug that has no CVE number but deserves attention. EVP_DecryptFinal() could incorrectly report a stale success when AES-SIV authentication failed. AES-SIV is an authenticated mode, and callers rely on that final return value to decide whether decrypted data can be trusted.

Interpretation: code that correctly checks the return value of EVP_DecryptFinal() could still have accepted data that failed authentication. If you use AES-SIV through EVP, treat this as a security fix despite the missing CVE.

4.0 only: base64 BIO data loss #

4.0.3 fixes a regression introduced in OpenSSL 4.0 in the base64 encoding BIO filter. Incomplete writes further down the BIO chain could cause encoded base64 data to be lost. The notes list this as a bug fix and assign no CVE. It is still worth checking whether base64 output written on earlier 4.0 releases is complete.

Affected and Fixed Versions #

The sources name the patched release on each branch. They do not give the first affected version for any CVE. The only statement about origin is that the base64 regression was introduced in OpenSSL 4.0. The table below therefore treats every earlier release on each branch as potentially affected. That is a planning assumption, not an OpenSSL statement.

These sources say nothing about other branches. If you run a line not listed here, consult OpenSSL directly rather than assuming it is unaffected.

Protection Steps #

The notes give neither version ranges nor per-CVE severity. Without that detail, upgrading costs less than proving each deployment safe.

1. Upgrade to the patched release on your branch: 4.0.3, 3.6.5 or 3.5.9. Staying on your current branch keeps the change limited to a patch release.
2. Prioritise by exposure. In this author's reading, a sensible order is:
   1. Services that accept QUIC or DTLS 1.2 connections
   2. Code that calls SSL_set_SSL_CTX() during a handshake
   3. Software that processes certificates and CRL distribution points from untrusted sources, or uses the CMP client
   4. Multi-threaded applications on 4.0, because of the X.509 cache use-after-free
3. Review AES-SIV call sites. If you decrypt AES-SIV data through EVP_DecryptFinal(), decide whether data accepted before the upgrade needs to be checked again.
4. Do not skip ARM64 and RISC-V builds. The SM2 constant-time fix applies specifically to those architectures.
5. On 4.0, audit base64 BIO output produced through chains where writes could be incomplete.
6. Do not use 4.1.0-beta2 as a remediation path. It is a pre-release, and its notes do not say whether it includes these fixes.

How to Check Whether You Are Affected #

Start with the version. For each application, establish which OpenSSL release it actually uses and compare that with the table above. A deployment on 4.0, 3.6 or 3.5 that is below 4.0.3, 3.6.5 or 3.5.9 respectively should be assumed to lack these fixes.

Version alone does not tell you whether a vulnerable code path is reachable. After the version check, answer these questions for each service. Each one maps to a specific item in the release notes:

• Does it accept QUIC connections through OpenSSL? Five fixes concern the QUIC stack.
• Does it use DTLS? CVE-2026-84782 concerns DTLS handshake retransmission. CVE-2026-75806 concerns DTLS 1.2 specifically.
• Does it call SSL_set_SSL_CTX() during a handshake? This is the CVE-2026-72897 path.
• Does it process relative CRL distribution points, or use the CMP client to handle revocation responses?
• Does it use non-NIST EC curves, or SM2 at all? Is it SM2 on ARM64 or RISC-V?
• Does it decrypt with AES-SIV and rely on EVP_DecryptFinal()?
• On 4.0, does it use X.509 extensions concurrently, or write output through the base64 BIO filter?

Answering "no" to every question lowers urgency but is not a reason to skip the update. These are patch releases on your existing branch, and applying them is far cheaper than checking reachability for every CVE in the list.

A Note for Teams Evaluating 4.1.0-beta2 #

The 4.1.0-beta2 pre-release is dated 2026-10-09. It adds:

• DTLS 1.3 (RFC 9147)
• RFC 8701 GREASE
• DTLS support in the SSL listener API
• An IKEV2 KDF
• Initial support for the Elbrus2000 architecture

It is a feature release in beta, not a security patch. Its notes list a known issue, tracked as #32878. When a DTLS 1.3 KeyUpdate is received, other outstanding post-handshake records are dropped from the retransmission buffer. A lost NewSessionTicket would therefore not be resent. The notes say a fix is in progress.

The beta also includes changes that affect builds and tooling:

• The no-ecdsa and no-ecdh Configure options are dropped. Use no-ec to disable elliptic curve support.
• The Windows-on-Itanium and Windows CE targets are removed.
• The tsget utility now uses Net::Curl::Easy. Users of tsget should install it before upgrading.