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

Viktor Dukhovni <[email protected]> Thu, 19 Mar 2026 13:26:40 +1100
Newsgroups gmane.comp.encryption.openssl.user
Message-ID <[email protected]>
On Wed, Mar 18, 2026 at 03:48:21PM -0400, 'Dimitri Ledkov' via openssl-user=
s wrote:

> The NVD has updated the CVE https://nvd.nist.gov/vuln/detail/CVE-2026-267=
3
>=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.

We're not responsible for the folly of others.  This issue affects
basically nobody today and for some time to come.  A CVE was assigned
only to make sure that distros don't skip integrating the fix into their
stable releases when they choose which security fixes to backport to
their stable OS updates.

Eventually, as PQC-capable clients and servers become more common, and
as servers start to use the "DEFAULT" keyword in their supported groups
configurations prefixing or suffixing it with minor tweaks, the bug fix
will be desirable.

For now the only affected software that comes to mind is bleeding-edge
Postfix 3.11 builds (released 2026-03-05!) on systems with bleeding-edge
OpenSSL runtimes (3.5 or later, released 2025-04-08), when communicating
with similar systems, and only to the extent that HNDL (harvest now
decrypt later) is a real concern (exceptionally high-value target
emailing highly confidential data, protected only by SMTP STARTTLS).

This is because Postfix 3.11 is willing to accept higher latency in
order to avoid occasional problems with middleboxes that choke on larger
PQC TLS Client Hellos, and so by default has (essentially):

    +#if OPENSSL_VERSION_PREREQ(3,5)
    +#define DEF_TLS_EECDH_AUTO      "?X25519MLKEM768:DEFAULT"
    +#define DEF_TLS_FFDHE_AUTO      ""
    +#else
    ... settings for older OpenSSL
    +#endif

When both the Postfix client and server are running the days old 3.11,
this default configuration setting trips over the bug, with servers
accepting the client's X25519 keyshare, rather sending an HRR for
X25519MLKEM768.

> 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

Please don't.  Updated releases are a week or two away, the sky is not
falling.

--=20
    Viktor.  =F0=9F=87=BA=F0=9F=87=A6 =D0=A1=D0=BB=D0=B0=D0=B2=D0=B0 =D0=A3=
=D0=BA=D1=80=D0=B0=D1=97=D0=BD=D1=96!

--=20
You received this message because you are subscribed to the Google Groups "=
openssl-users" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to openssl-users+unsubscribe-MCmKBN63+Bmbup2nOX2J7Q@public.gmane.org
To view this discussion visit https://groups.google.com/a/openssl.org/d/msg=
id/openssl-users/abte4Fk6SPB35wzl%40chardros.imrryr.org.