OpenSSL TLS 1.3 Server May Select Weaker Key Exchange Group

A newly disclosed vulnerability — CVE-2026-2673 — causes OpenSSL TLS 1.3 servers to silently downgrade cryptographic key-exchange strength when the DEFAULT keyword appears in group configuration. Patches are on their way, but no dedicated release has shipped yet.

The OpenSSL Project disclosed a low-severity security flaw in its TLS 1.3 implementation on March 13, 2026. Tracked as CVE-2026-2673, the bug can cause a TLS 1.3 server to negotiate a less-preferred key exchange group even when both the client and server support a stronger, higher-priority group — silently undermining the cryptographic posture the administrator intended.

The vulnerability was discovered internally and reported on February 16, 2026 by Viktor Dukhovni of the OpenSSL team. It carries a CVSS base score of 3.1 (Low), and there is currently no evidence of public proof-of-concept exploits or active exploitation in the wild.

What Goes Wrong

TLS 1.3 allows servers to advertise a prioritized list of key exchange groups. If a client’s initial ClientHello does not include a keyshare for the server’s most-preferred group, the server is supposed to respond with a HelloRetryRequest (HRR), prompting the client to supply the correct keyshare on its second attempt. This handshake dance is how the protocol ensures the strongest mutually-supported algorithm wins.

The defect in CVE-2026-2673 short-circuits that mechanism. When an OpenSSL server’s configuration uses the DEFAULT keyword to incorporate the built-in group list — perhaps to append or exclude individual groups — an implementation bug strips the tuple structure from the DEFAULT list. The server then treats all supported groups as one flat set of equivalent priority, suppresses the HRR it should have sent, and accepts whatever keyshare the client offered first, regardless of whether a better option was available.

“A less preferred key exchange may be used even when a more preferred group is supported by both client and server, if the group was not included among the client’s initial predicated keyshares.”

— OpenSSL Security Advisory, 13 March 2026

The practical consequence is an algorithm downgrade: communications remain encrypted, but with a key exchange mechanism ranked lower by the administrator’s own policy. This is particularly relevant for organizations deploying new hybrid post-quantum groups, which clients may intentionally defer until a server explicitly requests them via HRR. Affected servers will never request them, quietly falling back to classical key exchange.

Affected Versions

Only the two most recent stable branches of OpenSSL are vulnerable:

• OpenSSL 3.6.x — versions prior to 3.6.2
• OpenSSL 3.5.x — versions prior to 3.5.6

The following branches are not affected:

• OpenSSL 3.4
• OpenSSL 3.3
• OpenSSL 3.0 (LTS)
• OpenSSL 1.1.1
• OpenSSL 1.0.2
• All OpenSSL FIPS modules (the vulnerable code lies outside the FIPS boundary)

Patch Status

Because the OpenSSL Project classified this as low severity, it opted not to issue emergency out-of-band releases. The fixes have been committed to the stable branches in the OpenSSL git repository — commit 2157c9d8 for the 3.6 branch and commit 85977e01 for the 3.5 branch — and will ship in the next scheduled point releases, OpenSSL 3.6.2 and OpenSSL 3.5.6.

This approach has drawn mild criticism from the distribution ecosystem. Because the patches were not landed on top of the last stable point release, and because no versioned tarballs or git tags accompanied them, distributors wishing to cherry-pick the commits must resolve merge conflicts manually. Some community members have begun publishing unofficial “security-only” tarballs — for example, OpenSSL 3.6.1+1 and OpenSSL 3.5.5+1 — to fill the gap while official releases are being prepared.

Red Hat has also issued a security advisory for CVE-2026-2673, noting that fixes are deferred to future Red Hat Enterprise Linux releases tracking the patched OpenSSL upstream.

Windows Interoperability Impact

A secondary dimension of CVE-2026-2673 has emerged in enterprise environments that mix OpenSSL-based services with Windows infrastructure. When an affected OpenSSL server fails to send the expected HRR, Windows SChannel clients may interpret the non-compliant handshake as a fatal protocol error, causing connection failures. Microsoft has addressed this on the Windows side in its standard Patch Tuesday cycle, with updates that make SChannel more tolerant of non-compliant HRR behavior, covering Windows 11, Windows Server 2022, and Windows 10.

Background: TLS 1.3 Key Exchange Groups

TLS 1.3 replaced the static cipher-suite negotiation of earlier protocol versions with a more flexible model. Key exchange is now governed by named groups (also called supported groups), and servers can rank them by preference. The protocol’s HelloRetryRequest mechanism is specifically designed to let a server steer a client toward the optimal group when the first ClientHello does not supply the right keyshare — a critical path for modern hybrid post-quantum algorithms that clients may not speculatively include.

CVE-2026-2673 is not a protocol weakness; TLS 1.3 itself behaves correctly. The flaw is an implementation defect in how OpenSSL processes its own configuration, and it is fully remedied by the available patches.