CVE-2026-2673

Issue summary: An OpenSSL TLS 1.3 server may fail to negotiate the expected<br /> preferred key exchange group when its key exchange group configuration includes<br /> the default by using the &amp;#39;DEFAULT&amp;#39; keyword.<br /> <br /> Impact summary: A less preferred key exchange may be used even when a more<br /> preferred group is supported by both client and server, if the group<br /> was not included among the client&amp;#39;s initial predicated keyshares.<br /> This will sometimes be the case with the new hybrid post-quantum groups,<br /> if the client chooses to defer their use until specifically requested by<br /> the server.<br /> <br /> If an OpenSSL TLS 1.3 server&amp;#39;s configuration uses the &amp;#39;DEFAULT&amp;#39; keyword to<br /> interpolate the built-in default group list into its own configuration, perhaps<br /> adding or removing specific elements, then an implementation defect causes the<br /> &amp;#39;DEFAULT&amp;#39; list to lose its &amp;#39;tuple&amp;#39; structure, and all server-supported groups<br /> were treated as a single sufficiently secure &amp;#39;tuple&amp;#39;, with the server not<br /> sending a Hello Retry Request (HRR) even when a group in a more preferred tuple<br /> was mutually supported.<br /> <br /> As a result, the client and server might fail to negotiate a mutually supported<br /> post-quantum key agreement group, such as &amp;#39;X25519MLKEM768&amp;#39;, if the client&amp;#39;s<br /> configuration results in only &amp;#39;classical&amp;#39; groups (such as &amp;#39;X25519&amp;#39; being the<br /> only ones in the client&amp;#39;s initial keyshare prediction).<br /> <br /> OpenSSL 3.5 and later support a new syntax for selecting the most preferred TLS<br /> 1.3 key agreement group on TLS servers. The old syntax had a single &amp;#39;flat&amp;#39;<br /> list of groups, and treated all the supported groups as sufficiently secure.<br /> If any of the keyshares predicted by the client were supported by the server<br /> the most preferred among these was selected, even if other groups supported by<br /> the client, but not included in the list of predicted keyshares would have been<br /> more preferred, if included.<br /> <br /> The new syntax partitions the groups into distinct &amp;#39;tuples&amp;#39; of roughly<br /> equivalent security. Within each tuple the most preferred group included among<br /> the client&amp;#39;s predicted keyshares is chosen, but if the client supports a group<br /> from a more preferred tuple, but did not predict any corresponding keyshares,<br /> the server will ask the client to retry the ClientHello (by issuing a Hello<br /> Retry Request or HRR) with the most preferred mutually supported group.<br /> <br /> The above works as expected when the server&amp;#39;s configuration uses the built-in<br /> default group list, or explicitly defines its own list by directly defining the<br /> various desired groups and group &amp;#39;tuples&amp;#39;.<br /> <br /> No OpenSSL FIPS modules are affected by this issue, the code in question lies<br /> outside the FIPS boundary.<br /> <br /> OpenSSL 3.6 and 3.5 are vulnerable to this issue.<br /> <br /> OpenSSL 3.6 users should upgrade to OpenSSL 3.6.2 once it is released.<br /> OpenSSL 3.5 users should upgrade to OpenSSL 3.5.6 once it is released.<br /> <br /> OpenSSL 3.4, 3.3, 3.0, 1.0.2 and 1.1.1 are not affected by this issue.