CVE-2026-2673: 
OpenSSL vulnerability analysis and mitigation

CVE-2026-2673 is a TLS 1.3 key exchange group negotiation flaw in OpenSSL that allows an unauthenticated network attacker to force a downgrade to a less preferred (potentially classical, non-post-quantum) key agreement algorithm. The vulnerability was internally reported on February 16, 2026 by Viktor Dukhovni and publicly disclosed on March 13, 2026 via an OpenSSL Security Advisory. Affected versions are OpenSSL 3.5.0–3.5.5 (fixed in 3.5.6) and 3.6.0–3.6.1 (fixed in 3.6.2); versions 3.4, 3.3, 3.0, 1.1.1, and 1.0.2 are not affected. It carries a CVSS v3.1 base score of 6.5 (Medium), though the Feedly estimate categorizes it as HIGH due to its cryptographic downgrade implications (OpenSSL Advisory, Red Hat CVE).

The root cause is classified as CWE-325 (Missing Cryptographic Step) and CWE-757 (Selection of Less-Secure Algorithm During Negotiation / Algorithm Downgrade). When an OpenSSL TLS 1.3 server configuration uses the DEFAULT keyword to interpolate the built-in default group list (e.g., X25519MLKEM768:DEFAULT or DEFAULT:-SomeGroup), an implementation defect in ssl/t1_lib.c causes the DEFAULT list to lose its internal 'tuple' structure during recursive expansion. As a result, all server-supported groups are treated as a single security-equivalent tuple, preventing the server from issuing a Hello Retry Request (HRR) even when a more preferred group (such as the post-quantum hybrid X25519MLKEM768) is mutually supported but not included in the client's initial predicted keyshares. The fix, authored by Viktor Dukhovni, corrects the gid_cb/tuple_cb logic to properly preserve tuple boundaries during DEFAULT expansion (OpenSSL commit 3.6, OpenSSL commit 3.5, oss-security).

Successful exploitation results in the TLS 1.3 handshake completing with a less preferred key exchange group — specifically, a classical algorithm such as X25519 instead of a post-quantum hybrid like X25519MLKEM768 — even when both endpoints support the stronger option. This constitutes an integrity and cryptographic downgrade impact (CVSS integrity: Low, availability: Low), as the negotiated session may lack post-quantum forward secrecy protections. Confidentiality is not directly compromised in the short term, but connections downgraded to classical key exchange are theoretically vulnerable to future 'harvest now, decrypt later' attacks by quantum-capable adversaries. No FIPS modules are affected, and the issue is limited to servers using the DEFAULT keyword in their group list configuration (OpenSSL Advisory, Red Hat CVE).

1. Identify a vulnerable server: Locate an OpenSSL 3.5.0–3.5.5 or 3.6.0–3.6.1 TLS 1.3 server whose configuration uses the DEFAULT keyword in its group list (e.g., X25519MLKEM768:DEFAULT or DEFAULT:-X25519MLKEM768), which is the prerequisite for the bug to manifest.
2. Craft a ClientHello with only classical keyshares: As a TLS client, send a ClientHello that includes post-quantum groups (e.g., X25519MLKEM768) in the supported_groups extension but omits them from the predicted keyshares (key_share extension), including only classical groups such as X25519.
3. Observe server behavior: Due to the tuple structure loss, the vulnerable server treats all groups as a single tuple and selects the best classical group from the client's predicted keyshares (e.g., X25519) without issuing a Hello Retry Request, even though X25519MLKEM768 is mutually supported.
4. Complete handshake with downgraded group: The TLS session is established using the classical key exchange group, bypassing the intended post-quantum cryptographic protection (OpenSSL Advisory, OpenSSL commit 3.6).

• Network: TLS 1.3 handshakes completing with classical key exchange groups (e.g., X25519, P-256) on servers configured to prefer post-quantum hybrid groups (e.g., X25519MLKEM768); absence of Hello Retry Request (HRR) messages in TLS session captures where HRR would be expected.
• Logs: TLS session logs or audit records showing negotiated key exchange groups that do not match the server's configured preference order; repeated connections from the same client IP that consistently avoid post-quantum groups.
• Configuration: Server configurations containing the DEFAULT keyword in the TLS group list (e.g., in openssl.cnf or application-level SSL context settings) on OpenSSL 3.5.0–3.5.5 or 3.6.0–3.6.1.

Upgrade to OpenSSL 3.5.6 or 3.6.2, which contain the fix for this issue. As a workaround prior to patching, administrators should avoid using the DEFAULT keyword in TLS group list configurations and instead explicitly enumerate all desired groups and tuples using SSL_CTX_set1_groups_list() with explicit tuple separators. For example, replace configurations like X25519MLKEM768:DEFAULT with an explicit list such as X25519MLKEM768/*X25519MLKEM768:X25519:P-256. OpenSSL 3.4 and earlier branches are not affected and do not require action (OpenSSL Advisory, oss-security).

The OpenSSL project classified this as a Low severity issue and did not issue emergency out-of-band releases, instead bundling the fix into the next scheduled releases of the 3.5 and 3.6 branches. Security community commentary on oss-security and Bluesky noted the significance of the bug in the context of post-quantum cryptography adoption, with some researchers highlighting that it could silently undermine organizations' efforts to deploy hybrid PQ key exchange. Coverage appeared in Linux security news outlets (9to5Linux, Linuxiac, HelpNetSecurity) following the release of OpenSSL 3.6.2 and 3.5.6. Downstream vendors including Ubuntu, Debian, openSUSE, FreeBSD, Splunk, and Siemens issued their own advisories and updates (oss-security, Ubuntu USN-8155-1, FreeBSD Advisory).