OpenSSL 3.6.2 landed this week carrying eight CVE fixes, with the project rating the most severe issue as Moderate. On the surface, that sounds reassuring—no critical exploits, no ransomware-grade zero-days. But the distribution of these fixes across RSA KEM, DANE validation, CMS processing, and AES-CFB-128 reveals something more nuanced: a library catching up on pointer arithmetic bugs and configuration validation gaps that should have been surfaced earlier. Let’s dig into why this patch matters and what it tells us about OpenSSL’s current security posture.
The Eight CVEs: A Layered Risk Profile
OpenSSL 3.6.2 patches eight CVEs, with the most severe issue rated as Moderate. Here’s the breakdown:
RSA KEM and Key Agreement Issues
The release fixes incorrect failure handling in RSA KEM RSASVE encapsulation (CVE-2026-31790) and a loss of key agreement group tuple structure when the DEFAULT keyword is used in server-side configuration of the key-agreement group list (CVE-2026-2673)
The RSA KEM fix is straightforward: incorrect error handling could leave the encapsulation in an inconsistent state. But CVE-2026-2673 is the governance red flag here. If you’re using OpenSSL’s DEFAULT keyword in your key-agreement configuration—a common pattern for “use whatever the system recommends”—you may have been silently negotiating weaker key groups than your policy intended. This is a configuration validation failure, not a cryptographic weakness per se, but it speaks to a gap in how OpenSSL validates its own configuration syntax. If DEFAULT doesn’t preserve the full tuple structure, users relying on it get a degraded experience without realizing it.
The AVX-512 Memory-Read Exposure
An out-of-bounds read in AES-CFB-128 on x86-64 CPUs with AVX-512 support (CVE-2026-28386) is the highest-priority fix for modern deployments. This is a memory-read vulnerability in the AES-CFB-128 mode, triggered only on x86-64 systems with AVX-512 enabled. The risk isn’t arbitrary code execution—it’s a side-channel or information disclosure through out-of-bounds reads. Administrators running 3.6.x on x86-64 systems with AVX-512 enabled should prioritize the AES-CFB-128 fix given the memory-read exposure in that path.
If you’re running encrypted workloads on cloud infrastructure with modern x86 silicon (think: AWS Graviton3, Azure’s latest compute tiers, or on-premises hardware from 2022 onwards), you’re likely AVX-512-capable. The exposure is real. Prioritize this one.
Pointer Arithmetic and Validation Bugs
The release also resolves a potential use-after-free in DANE client code (CVE-2026-28387), a NULL pointer dereference when processing a delta CRL (CVE-2026-28388), and two additional NULL dereference bugs affecting CMS recipient info handling: one in CMS KeyAgreeRecipientInfo processing (CVE-2026-28389) and one in CMS KeyTransportRecipientInfo processing (CVE-2026-28390).
These are classic memory-safety issues: use-after-free and NULL dereferences. In isolation, they’re DoS vectors—an attacker can crash your OpenSSL process by feeding it a malformed CRL or CMS message. But context matters. If you’re a certificate authority consuming untrusted delta CRLs, or a mail gateway parsing S/MIME messages with encrypted recipients, these bugs become attack surface. The severity rating reflects the fact that arbitrary code execution isn’t straightforward from these flaws, but availability impact is certain.
Hexadecimal Conversion Overflow
A heap buffer overflow in hexadecimal conversion (CVE-2026-31789) rounds out the list. This is lower-priority—it’s a heap overflow in a utility function—but it exists. If you’re using OpenSSL’s hex conversion APIs on untrusted input (parsing user-supplied keys, configuration values, or wire protocol data), this is exploitable.
Version Exposure: The Support Landscape
OpenSSL 3.6 and 3.5 are vulnerable to several of these issues. OpenSSL 3.4, 3.3, 3.0, 1.0.2, and 1.1.1 are not affected by some of the CVEs patched in this release. Notice the word “some”—it’s not a blanket statement. Different branches are vulnerable to different CVEs. This is important because it means your upgrade path depends on what version you’re running:
- If you’re on 3.6.x: You need 3.6.2. All eight CVEs affect you.
- If you’re on 3.5.x: You’re affected by most of the same issues (3.5.6 addresses them), but the support window is longer. The 3.6 series carries standard support, with a shorter update window than the long-term support 3.5 branch
- If you’re on 3.4 or earlier: You get partial credit. Some of these bugs don’t affect your version, but others do. You need to audit your specific branch against the full CVE list on openssl-library.org.
This is a governance conversation worth having with your infrastructure team. If you chose 3.6 for its new features (NIST security categories, EVP_SKEY objects, LMS signature support, deterministic ECDSA), you’ve signed up for a higher-cadence patching obligation. 3.5 LTS users get a longer maintenance window, which translates to fewer surprise updates but also a tradeoff in cutting-edge crypto features.
Configuration Validation: The Silent Failure
CVE-2026-2673 deserves its own section because it illustrates a broader problem: configuration bugs are harder to detect than code bugs.
If I deploy OpenSSL 3.6.0 and configure it like this:SSLOpenSSLCipherSuite DEFAULT:!aNULL SSLOpenSSLECDHCurve secp384r1:secp256r1:DEFAULT
My intent is to use secp384r1 as my preferred curve, fall back to secp256r1, then use DEFAULT as a catch-all. But in 3.6.0 through 3.6.1, the DEFAULT keyword corrupts the tuple structure. My fallback becomes unpredictable. The client and server might negotiate something weaker than expected, and I’d have no signal that this happened—no error logs, no handshake warnings. The TLS connection succeeds. The conversation is encrypted. But it’s encrypted with a less-preferred group.
This is why configuration validation matters as much as cryptographic correctness. A poorly validated config can degrade security posture without triggering any alarms.
What Should Have Been
From a practitioner’s governance perspective, here’s what went wrong:
- Configuration parsing should include round-trip validation. After OpenSSL parses a configuration directive, it should validate that the parsed structure matches the intended semantics. A DEFAULT keyword should preserve the full tuple, period.
- Pointer arithmetic in memory-sensitive code (CMS, CRL, hex conversion) should have fuzz testing integrated into the release cycle. All three of these CVEs (CVE-2026-28388, CVE-2026-28389, CVE-2026-28387) are the kind of bugs that fuzzing catches reliably. If they made it to 3.6.0, the fuzzing wasn’t comprehensive enough or wasn’t run at gate-check time.
- AVX-512 SIMD paths need dedicated testing. The AES-CFB-128 bug (CVE-2026-28386) exists because the SIMD implementation wasn’t validated against the scalar path. This is a well-known problem in cryptographic libraries: SIMD paths diverge from scalar paths and introduce new bugs. OpenSSL should have a CI job that runs all crypto tests on AVX-512 hardware.
Upgrade Priority
Immediate (this week):
- If you’re on 3.6.x with AVX-512 hardware, patch for CVE-2026-28386.
- If you’re a certificate authority or mail gateway consuming untrusted CRLs or S/MIME, patch for the NULL dereference fixes.
This sprint:
- Audit your OpenSSL configuration files for DEFAULT keyword usage. After patching 3.6.2, re-test your TLS handshakes to confirm negotiated groups match your policy.
- If you’re on 3.5.x, schedule 3.5.6 for your next maintenance window.
Long-term:
- If you haven’t already, make a decision between 3.6 standard support and 3.5 LTS. Document that decision in your security architecture. The shorter patch window of 3.6 means you’re committing to higher operational overhead for access to newer crypto primitives.
The Broader Picture
OpenSSL 3.6.2 isn’t a crisis patch. The Moderate severity rating is fair—these bugs are real, but they’re not zero-day exploits or cryptographic breaks. What they reveal is that OpenSSL is still catching up on code hygiene in areas like configuration parsing, pointer arithmetic, and SIMD correctness. The library is feature-rich (NIST categories, LMS, EVP_SKEY), but that richness introduces surface area that needs hardening.
For practitioners, the lesson is clear: don’t wait for Critical CVEs to start caring about your OpenSSL posture. Moderate severity bugs compound. A use-after-free in DANE client code doesn’t sound like much until your mail system validates certificates and crashes on a crafted message. A configuration parsing bug doesn’t sound critical until you realize your entire TLS deployment negotiated weaker curves than policy requires.
Patch 3.6.2. Audit your configs. Test your deployments. And if you’re still on 3.0 or 1.1.1, remember: extended support exists, but it’s not free, and the maintenance burden only grows as older versions fall further behind.
