OpenSSL 4.0.3 ships 14 fixes across QUIC, DTLS and SM2
The project's worst-rated flaw this cycle tops out at High, but a couple of the corrections deserve more attention than the severity meter suggests.
OpenSSL 4.0.3 is out. The Project published it on September 29 as a security patch for the current 4.0 major line. It folds together 14 distinct vulnerabilities spanning the QUIC transport, DTLS, X.509 certificate handling, the SM2 elliptic-curve suite and core key-management code. The project's own advisory puts the worst of them at High, using the exact phrasing "the most severe CVE fixed in this release is High."
If OpenSSL doesn't ring a bell immediately, that is arguably the whole point. The library is the cryptographic backbone of much of the internet, implementing the TLS and SSL protocols behind most HTTPS traffic, powering email and VPNs, and embedded in servers and operating systems. Its track record includes Heartbleed, the 2014 leak that bled server memory to the public in a single afternoon, which is why every release gets watched closely. A flaw here doesn't touch one vendor alone.
In addition to the 14 CVEs, this release corrects two non-vulnerability bugs that didn't earn their own identifiers. One is a correctness regression in AES-SIV authentication reporting. The other is a data-loss bug in base64 encoding, and both are worth a closer look.
The worst fix has no CVE number
Here's the part that most admin dashboards will miss. The AES-SIV issue carries no dedicated CVE, but it's the one I'd watch most closely. EVP_DecryptFinal() used to report a stale success when an AES-SIV operation failed authentication. That means apps relying on the return value to confirm integrity could treat a tampered plaintext as if it were legitimate, a serious correctness problem for anyone on authenticated encryption in SIV mode.
The base64 bug is more of a data-integrity annoyance. A regression earlier in the 4.0 line caused incomplete writes down the BIO chain to potentially lose encoded data. Stream something through the base64 encoding BIO filter and you might walk away with truncated output and no idea it happened.
Here's the full CVE inventory from the release notes:
| CVE | Component | Summary | Impact |
|---|---|---|---|
| CVE-2026-84782 | DTLS | Retransmits handshake messages from a stale buffer offset | Protocol corruption on retransmission |
| CVE-2026-84783 | X.509 | Use-after-free in the extension cache under concurrent use | Crash or possible code execution |
| CVE-2026-35189 | PKCS#7 / CRL | Excessive memory allocation in relative CRLDP processing | Memory-exhaustion DoS |
| CVE-2026-35191 | QUIC | Unvalidated amplification credit gets over-accounted | Amplification-based DoS |
| CVE-2026-42772 | QUIC | O(n²) fragment reassembly enables CPU DoS | CPU-exhaustion DoS |
| CVE-2026-54872 | Crypto (EC) | Timing side-channel in scalar multiplication for mon-NIST curves | Possible key recovery |
| CVE-2026-54873 | QUIC | STREAM fragment metadata abused for DoS | Memory-exhaustion DoS |
| CVE-2026-54875 | Crypto (SM2) | Non-constant-time SM2 scalar multiplication on ARM64/RISC-V | Possible key recovery |
| CVE-2026-72897 | libssl | Out-of-bounds access after SSL_set_SSL_CTX() during a handshake | Memory corruption / crash |
| CVE-2026-75804 | QUIC | Connection-level flow control wasn't enforced for streams | Flow-control bypass |
| CVE-2026-75805 | CMP | NULL pointer dereference in revocation response handling | Crash / DoS |
| CVE-2026-75806 | DTLS | Unauthenticated, undersized DTLS 1.2 AEAD record | DoS |
| CVE-2026-77696 | Crypto (SM2) | Timing side-channel in SM2 signature generation | Possible key recovery |
| CVE-2026-84784 | QUIC | Unbounded RETIRE_CONNECTION_ID backlog | Memory-exhaustion DoS |
What the batch actually tells you
QUIC jumps out as the dominant theme, accounting for at least five of the 14 fixes. That tracks, since the protocol moved from niche to mainstream fast and a still-maturing codebase draws bug hunters and attackers in equal measure. Most of these are denial-of-service flavors: unbounded backlogs, fragment-metadata abuse, flow-control gaps and amplification accounting. They're resource-exhaustion problems rather than anything that compromises data.
The second theme is more stubborn. Three fixes target timing or constant-time failures in scalar multiplication and signature generation, two of them specifically about SM2. Timing side channels are some of the hardest bugs in cryptography to kill completely, so their repeated appearance is less surprising than it sounds. The third theme is just the C language being C. Use-after-free, out-of-bounds access, NULL dereferences and memory-exhaustion bugs make up the same familiar roster you'd find anywhere a large hand-written-C codebase lives, memory-safety hardening notwithstanding. Two more fixes land on DTLS, the UDP variant of TLS that real-time and loss-tolerant apps lean on, both about how records behave when the network is being hostile.
OpenSSL is moving quickly right now, and 4.0.3 sits squarely in the middle of it. The predecessor shipped on August 25, and this advisory even flags that 1,965 commits had already landed on the master branch by the time 4.0.3 was tagged. There's a lot ahead.
OpenSSL skipped the 2.0 designation entirely to dodge a clash with one of its own modules. Yes, that's real. It's the first major release since 2018, and it brought Encrypted Client Hello, post-quantum curve groups and dropped engines support entirely. Keep in mind that 4.0 isn't a Long-Term Stable line. It carries support only through May 14, 2027, with extended protection offered as a paid add-on through the OpenSSL Corporation.
Timing matters because 4.1 is close. The project announced OpenSSL 4.1 Beta1 on September 23, with a final 4.1 release expected in October. As of right now it's still in beta, but the headline feature is DTLS 1.3 support, which pulls much of TLS 1.3's speed and security into the UDP world, post-quantum cryptography included.
The cadence is changing too. Per an announcement at ICMC26, OpenSSL now commits to a major release every two years. That puts 4.2 as the next LTS (April 2027) and 5.0 in October 2027. Since the last 4.x release stays supported for the whole 5.x cycle, teams have real room to pick when to upgrade. Separately, 3.0 reached end of life on September 16 and no longer receives publicly available security fixes. If you're still on that line, the clock is ticking.
Upgrade to 4.0.3 soon, especially if you run QUIC, DTLS, CMP infrastructure, or SM2 on ARM64 or RISC-V. The memory-corruption bugs and the AES-SIV misreporting are the ones most likely to matter beyond a denial of service, so prioritize those. If your apps stream through the base64 BIO filter, verify output integrity after upgrading, because the older behavior could silently truncate data. And if a bigger upgrade is already on the table, 4.1 is close enough that evaluating the beta makes more sense than lingering on 4.0.x for much longer.
Head here for the 4.0.3 release notes and download links.
