CVE-2026-2673
Received Received - Intake
TLS 1.3 Key Exchange Negotiation Flaw in OpenSSL

Publication date: 2026-03-13

Last updated on: 2026-03-17

Assigner: OpenSSL Software Foundation

Description
Issue summary: An OpenSSL TLS 1.3 server may fail to negotiate the expected preferred key exchange group when its key exchange group configuration includes the default by using the 'DEFAULT' keyword. Impact summary: 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. This will sometimes be the case with the new hybrid post-quantum groups, if the client chooses to defer their use until specifically requested by the server. If an OpenSSL TLS 1.3 server's configuration uses the 'DEFAULT' keyword to interpolate the built-in default group list into its own configuration, perhaps adding or removing specific elements, then an implementation defect causes the 'DEFAULT' list to lose its 'tuple' structure, and all server-supported groups were treated as a single sufficiently secure 'tuple', with the server not sending a Hello Retry Request (HRR) even when a group in a more preferred tuple was mutually supported. As a result, the client and server might fail to negotiate a mutually supported post-quantum key agreement group, such as 'X25519MLKEM768', if the client's configuration results in only 'classical' groups (such as 'X25519' being the only ones in the client's initial keyshare prediction). OpenSSL 3.5 and later support a new syntax for selecting the most preferred TLS 1.3 key agreement group on TLS servers. The old syntax had a single 'flat' list of groups, and treated all the supported groups as sufficiently secure. If any of the keyshares predicted by the client were supported by the server the most preferred among these was selected, even if other groups supported by the client, but not included in the list of predicted keyshares would have been more preferred, if included. The new syntax partitions the groups into distinct 'tuples' of roughly equivalent security. Within each tuple the most preferred group included among the client's predicted keyshares is chosen, but if the client supports a group from a more preferred tuple, but did not predict any corresponding keyshares, the server will ask the client to retry the ClientHello (by issuing a Hello Retry Request or HRR) with the most preferred mutually supported group. The above works as expected when the server's configuration uses the built-in default group list, or explicitly defines its own list by directly defining the various desired groups and group 'tuples'. No OpenSSL FIPS modules are affected by this issue, the code in question lies outside the FIPS boundary. OpenSSL 3.6 and 3.5 are vulnerable to this issue. OpenSSL 3.6 users should upgrade to OpenSSL 3.6.2 once it is released. OpenSSL 3.5 users should upgrade to OpenSSL 3.5.6 once it is released. OpenSSL 3.4, 3.3, 3.0, 1.0.2 and 1.1.1 are not affected by this issue.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-13
Last Modified
2026-03-17
Generated
2026-05-06
AI Q&A
2026-03-13
EPSS Evaluated
2026-05-05
NVD
CVE-2026-2673
EUVD
EUVD-2026-12033
Affected Vendors & Products
Showing 3 associated CPEs
Vendor Product Version / Range
openssl openssl 3.5
openssl openssl to 3.6.2 (inc)
openssl openssl to 3.5.6 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-757 A protocol or its implementation supports interaction between multiple actors and allows those actors to negotiate which algorithm should be used as a protection mechanism such as encryption or authentication, but it does not select the strongest algorithm that is available to both parties.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

[{'type': 'paragraph', 'content': "CVE-2026-2673 is a vulnerability in OpenSSL TLS 1.3 servers related to how the server handles key exchange group configurations when using the 'DEFAULT' keyword. The issue causes the loss of the intended 'tuple' structure of key agreement groups during configuration expansion, which means the server may treat all supported groups as a single group rather than distinct groups of roughly equivalent security."}, {'type': 'paragraph', 'content': "This flaw can cause the server to select a less preferred key exchange group even if a more preferred group is mutually supported by both client and server. It particularly affects negotiation involving new hybrid post-quantum key agreement groups, such as 'X25519MLKEM768'. If the client initially predicts only classical groups and defers post-quantum groups until requested, the server fails to issue a Hello Retry Request (HRR) to prompt the client to retry with a more preferred group."}, {'type': 'paragraph', 'content': "The vulnerability arises because the 'DEFAULT' keyword expansion loses the tuple grouping semantics, which are critical for TLS 1.3 group selection logic. The fix preserves the tuple structure during expansion, ensuring correct group preference and improving TLS handshake security and interoperability."}] [1, 2, 3]


How can this vulnerability impact me? :

This vulnerability can impact you by causing your OpenSSL TLS 1.3 server to negotiate a less preferred or weaker key exchange group during the TLS handshake. This means that even if a stronger or more secure key agreement group is supported by both client and server, the server might not select it due to the loss of tuple structure in the configuration.

Specifically, it can prevent the negotiation of newer hybrid post-quantum key agreement groups, potentially weakening the security of the TLS connection. The server may fail to send a Hello Retry Request (HRR) to prompt the client to retry with a more secure group, leading to suboptimal security during key exchange.

This could expose communications to downgrade risks where a less secure key exchange is used, potentially making encrypted communications less resistant to future cryptographic attacks.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

I don't know


What immediate steps should I take to mitigate this vulnerability?

[{'type': 'paragraph', 'content': 'To mitigate the CVE-2026-2673 vulnerability, users of OpenSSL 3.6 should upgrade to OpenSSL version 3.6.2 once it is released.'}, {'type': 'paragraph', 'content': 'Users of OpenSSL 3.5 should upgrade to OpenSSL version 3.5.6 once it is released.'}, {'type': 'paragraph', 'content': 'If you are using OpenSSL versions 3.4, 3.3, 3.0, 1.1.1, or 1.0.2, you are not affected by this issue.'}, {'type': 'paragraph', 'content': "The vulnerability arises from using the 'DEFAULT' keyword in the server's TLS 1.3 key exchange group configuration, which causes loss of tuple structure and may lead to suboptimal keyshare selection."}, {'type': 'paragraph', 'content': "As an immediate step, avoid using the 'DEFAULT' keyword to interpolate the built-in default group list into custom configurations until you have applied the fixed OpenSSL versions."}] [1, 2, 3]


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart