OpenSSL TLS 1.3 server may choose unexpected key agreement group

Summary

CVECVE-2026-2673
StatePUBLISHED
Assigneropenssl
Source PriorityCVE Program / NVD first with legacy fallback
Published2026-03-13 19:54:34 UTC
Updated2026-05-12 13:17:34 UTC
DescriptionIssue 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.

Risk And Classification

Primary CVSS: v3.1 7.5 HIGH from ADP

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

EPSS: 0.000170000 probability, percentile 0.045070000 (date 2026-05-12)

Problem Types: CWE-757 | CWE-757 CWE-757 Selection of Less-Secure Algorithm During Negotiation ('Algorithm Downgrade')


VersionSourceTypeScoreSeverityVector
3.1ADPDECLARED7.5HIGHCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
3.1134c704f-9b21-4f2e-91b3-4a467353bcc0Secondary7.5HIGHCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

CVSS v3.1 Breakdown

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
None
Availability
None

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Vendor Declared Affected Products

SourceVendorProductVersionPlatforms
CNA OpenSSL OpenSSL affected 3.6.0 3.6.2 semver Not specified
CNA OpenSSL OpenSSL affected 3.5.0 3.5.6 semver Not specified
ADP Siemens SIMATIC CN 4100 affected V5.0 custom Not specified

References

ReferenceSourceLinkTags
github.com/openssl/openssl/commit/2157c9d81f7b0bd7dfa25b960e928ec28e8dd63f [email protected] github.com
cert-portal.siemens.com/productcert/html/ssa-032379.html 0b142b55-0307-4c5a-b3c9-f314f3fb7c5e cert-portal.siemens.com
github.com/openssl/openssl/commit/85977e013f32ceb96aa034c0e741adddc1a05e34 [email protected] github.com
openssl-library.org/news/secadv/20260313.txt [email protected] openssl-library.org
www.openwall.com/lists/oss-security/2026/03/13/3 af854a3a-2127-422b-91ae-364da2661108 www.openwall.com
CVE Program record CVE.ORG www.cve.org canonical
NVD vulnerability detail NVD nvd.nist.gov canonical, analysis

Vendor Comments And Credit

Discovery Credit

CNA: Viktor Dukhovni (en)

CNA: Viktor Dukhovni (en)

© CVE.report 2026 |

Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties, implied or otherwise, with regard to this information or its use. Any use of this information is at the user's risk. It is the responsibility of user to evaluate the accuracy, completeness or usefulness of any information, opinion, advice or other content. EACH USER WILL BE SOLELY RESPONSIBLE FOR ANY consequences of his or her direct or indirect use of this web site. ALL WARRANTIES OF ANY KIND ARE EXPRESSLY DISCLAIMED. This site will NOT BE LIABLE FOR ANY DIRECT, INDIRECT or any other kind of loss.

CVE, CWE, and OVAL are registred trademarks of The MITRE Corporation and the authoritative source of CVE content is MITRE's CVE web site. This site includes MITRE data granted under the following license.

Free CVE JSON API cve.report/api

CVE.report and Source URL Uptime Status status.cve.report