[From nobody Sat Apr 11 15:51:06 2026 Received: (at submit) by bugs.debian.org; 13 Mar 2026 20:39:36 +0000 X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02 (2024-03-25) on buxtehude.debian.org X-Spam-Level: X-Spam-Status: No, score=-9.9 required=4.0 tests=BAYES_00, FOURLA, FROMDEVELOPER, NO_RELAYS,XMAILER_REPORTBUG autolearn=ham autolearn_force=no version=4.0.1-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0.0000 Tokens: new, 22; hammy, 150; neutral, 155; spammy, 0. spammytokens: hammytokens:0.000-+--H*F:U*carnil, 0.000-+--XDebbugsCc, 0.000-+--X-Debbugs-Cc, 0.000-+--HTo:N*Debian, 0.000-+--H*Ad:N*Bug Return-path: <carnil@debian.org> Received: via submission by buxtehude.debian.org with esmtp (Exim 4.96) (envelope-from <carnil@debian.org>) id 1w19IE-002i3y-1r for submit@bugs.debian.org; Fri, 13 Mar 2026 20:39:36 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Salvatore Bonaccorso <carnil@debian.org> To: Debian Bug Tracking System <submit@bugs.debian.org> Subject: openssl: CVE-2026-2673 Message-ID: <177343437335.2724481.8582007866155904056.reportbug@eldamar.lan> X-Mailer: reportbug 13.2.0 Date: Fri, 13 Mar 2026 21:39:33 +0100 Delivered-To: submit@bugs.debian.org Source: openssl Version: 3.6.1-2 Severity: important Tags: security upstream X-Debbugs-Cc: carnil@debian.org, Debian Security Team <team@security.debian.org> Control: found -1 3.5.5-1 Control: found -1 3.5.4-1~deb13u1 Control: found -1 3.5.4-1 Hi, The following vulnerability was published for openssl. CVE-2026-2673[0]: | 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. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2026-2673 https://www.cve.org/CVERecord?id=CVE-2026-2673 [1] https://openssl-library.org/news/secadv/20260313.txt Regards, Salvatore ]