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

The NVD has updated the CVE https://nvd.nist.gov/vuln/detail/CVE-2026-2673

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.

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

Any users can reuse the git cherry-picks, rebased and conflicts
resolved, or download immutable releases from there.

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.

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.

Regards,

Dimitri.


On Fri, Mar 13, 2026 at 9:23=E2=80=AFAM 'Tomas Mraz' via openssl-project
<[email protected]> wrote:
>
> 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
>
> OpenSSL TLS 1.3 server may choose unexpected key agreement group (CVE-202=
6-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
>
> Severity: Low
>
> Issue summary: An OpenSSL TLS 1.3 server may fail to negotiate the expect=
ed
> preferred key exchange group when its key exchange group configuration in=
cludes
> the default by using the "DEFAULT" keyword.
>
> Impact summary: A less preferred key exchange may be used even when a mor=
e
> 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 t=
o
> interpolate the built-in default group list into its own configuration, p=
erhaps
> adding or removing specific elements, then an implementation defect cause=
s the
> "DEFAULT" list to lose its "tuple" structure, and all server-supported gr=
oups
> 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 sup=
ported
> 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 preferr=
ed TLS
> 1.3 key agreement group on TLS servers.  The old syntax had a single "fla=
t"
> list of groups, and treated all the supported groups as sufficiently secu=
re.
> If any of the keyshares predicted by the client were supported by the ser=
ver
> the most preferred among these was selected, even if other groups support=
ed by
> the client, but not included in the list of predicted keyshares would hav=
e 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 keysha=
res,
> the server will ask the client to retry the ClientHello (by issuing a Hel=
lo
> Retry Request or HRR) with the most preferred mutually supported group.
>
> The above works as expected when the server's configuration uses the buil=
t-in
> default group list, or explicitly defines its own list by directly defini=
ng 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.
>
> 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 repos=
itory.
>
> This issue was internally reported on the 16th of February 2026 by Viktor
> Dukhovni.  The fix was developed by Viktor Dukhovni.
>
> 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
>
> URL for this Security Advisory:
> https://openssl-library.org/news/secadv/20260313.txt
>
> Note: the online version of the advisory may be updated with additional d=
etails
> over time.
>
> For details of OpenSSL severity classifications please see:
> https://openssl-library.org/policies/general/security-policy/
>
> --
> 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/m=
sgid/openssl-project/10107223b33073994e235de61f20bde963d8fe0b.camel%40opens=
sl.foundation.

--=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/CA%2BV%3D%2BpvQ307wgUPUMiGP1q-Pr8bhdzgUDo9qm5ivt-pbh%2Bi=
sdQ%40mail.gmail.com.