cbcvebase.
CVE-2026-2673
published 2026-03-13

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…

PriorityP338medium6.5CVSS 3.1
AVNACLPRNUINSUCNILAL
EPSS
0.43%
35.1th percentile
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 t

Affected

10 ranges
VendorProductVersion rangeFixed in
debianopenssl< openssl 3.5.5-1~deb13u2 (trixie)openssl 3.5.5-1~deb13u2 (trixie)
msrcazl3_nodejs24_24.13.0-3_on_azure_linux_3.0
msrcazl3_rust_1.75.0-25_on_azure_linux_3.0
msrcazl3_rust_1.90.0-4_on_azure_linux_3.0
opensslopenssl>= 0 < 3.5.6-r03.5.6-r0
opensslopenssl>= 0 < 3.5.6-r03.5.6-r0
opensslopenssl>= 0 < 3.5.5-1~deb13u23.5.5-1~deb13u2
opensslopenssl>= 3.5.0 < 3.5.63.5.6
opensslopenssl>= 3.6.0 < 3.6.23.6.2
siemenssimatic_cn_4100_firmware< 5.05.0

CVSS provenance

nvdv3.16.5MEDIUMCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
osv7.5HIGH
vendor_debian7.5LOW
vendor_redhat7.5HIGH
vendor_ubuntu7.5HIGH
vendor_msrc5.3MEDIUM
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.