Re: 3rd-party tarball releases available for CVE-2026-2673 reclassed from Low to High Re: OpenSSL Security Advisory

The NVD classification for this basically non-issue is just hilarious.

I have no further comments.

Tomas Mraz, CTO, OpenSSL Foundation


On Wed, 2026-03-18 at 15:48 -0400, Dimitri Ledkov wrote:
> The NVD has updated the CVE
> https://nvd.nist.gov/vuln/detail/CVE-2026-2673
>=20
> The assigned score is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
> which is classed as High by multiple security scanners.
>=20
> Due to lack of upstream tags and tarballs, I have prepared backports
> of the fix onto stable releases 3.5.5+1 and 3.6.1+1 and published
> that
> at: https://github.com/openssl-stable/openssl-stable/releases
>=20
> Any users can reuse the git cherry-picks, rebased and conflicts
> resolved, or download immutable releases from there.
>=20
> I again call for OpenSSL upstream to reconsider and tag releases for
> any CVE. It is always best to branch last point release, commit the
> fix, tag it, and merge into the updates branch. This way, tagged
> releases require no additional work. Git describe can then correctly
> identify the builds before and after the fix on the updates branch as
> those with or without the fix.
>=20
> The OpenSSL assessment and classification of CVEs may not align with
> classification determined by the regulators. Hence all CVE patches
> should follow the same process once they are made public.
>=20
> Regards,
>=20
> Dimitri.
>=20
>=20
> On Fri, Mar 13, 2026 at 9:23=E2=80=AFAM 'Tomas Mraz' via openssl-project
> <[email protected]> wrote:
> >=20
> > OpenSSL Security Advisory [13th March 2026]
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >=20
> > OpenSSL TLS 1.3 server may choose unexpected key agreement group
> > (CVE-2026-2673)
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >=20
> > Severity: Low
> >=20
> > 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.
> >=20
> > 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.
> >=20
> > 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.
> >=20
> > 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).
> >=20
> > OpenSSL 3.5 and later support a new syntax for selecting the most
> > preferred TLS
> > 1.3 key agreement group on TLS servers.=C2=A0 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.
> >=20
> > The new syntax partitions the groups into distinct "tuples" of
> > roughly
> > equivalent security.=C2=A0 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.
> >=20
> > 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".
> >=20
> > No OpenSSL FIPS modules are affected by this issue, the code in
> > question lies
> > outside the FIPS boundary.
> >=20
> > OpenSSL 3.6 and 3.5 are vulnerable to this issue.
> >=20
> > 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.
> >=20
> > OpenSSL 3.4, 3.3, 3.0, 1.0.2 and 1.1.1 are not affected by this
> > issue.
> >=20
> > Due to the low severity of this issue we are not issuing new
> > releases of
> > OpenSSL at this time. The fix will be included in the next release
> > of 3.6
> > and 3.5 branches, once it becomes available. The fix is also
> > available in commit
> > 2157c9d8 (for 3.6) and commit 85977e01 (for 3.5) in the OpenSSL git
> > repository.
> >=20
> > This issue was internally reported on the 16th of February 2026 by
> > Viktor
> > Dukhovni.=C2=A0 The fix was developed by Viktor Dukhovni.
> >=20
> > General Advisory Notes
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >=20
> > URL for this Security Advisory:
> > https://openssl-library.org/news/secadv/20260313.txt
> >=20
> > Note: the online version of the advisory may be updated with
> > additional details
> > over time.
> >=20
> > For details of OpenSSL severity classifications please see:
> > https://openssl-library.org/policies/general/security-policy/
> >=20
> > --
> > You received this message because you are subscribed to the Google
> > Groups "openssl-project" group.
> > To unsubscribe from this group and stop receiving emails from it,
> > send an email to [email protected].
> > To view this discussion visit
> > https://groups.google.com/a/openssl.org/d/msgid/openssl-project/1010722=
3b33073994e235de61f20bde963d8fe0b.camel%40openssl.foundation
> > .

--=20
Tom=C3=A1=C5=A1 Mr=C3=A1z, Chief Technology Officer, OpenSSL Foundation
We need your support! Help us protect digital privacy=E2=80=A6 everywhere.
https://openssl.foundation/donate/ways-to-give

--=20
You received this message because you are subscribed to the Google Groups "=
openssl-project" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to [email protected].
To view this discussion visit https://groups.google.com/a/openssl.org/d/msg=
id/openssl-project/7918aa5bb137353ed5ffafef0d22bfca34e22a26.camel%40openssl=
.foundation.