OpenSSL Selection of Less-Secure Algorithm During Negotiation (Algorithm Downgrade) Vulnerability - CVE-2026-2673

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 39DEFAULT39 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 client39s 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 server39s configuration uses the 39DEFAULT39 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 39DEFAULT39 list to lose its 39tuple39 structure and all server-supported groups were treated as a single sufficiently secure 39tuple39 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 39X25519MLKEM76839 if the client39s configuration results in only 39classical39 groups (such as 39X2551939 being the only ones in the client39s 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 39flat39 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 39tuples39 of roughly equivalent security. Within each tuple the most preferred group included among the client39s 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 server39s configuration uses the built-in default group list or explicitly defines its own list by directly defining the various desired groups and group 39tuples39. 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.