CVE-2026-2673: OpenSSL TLS 1.3 Key Exchange Vulnerability

CVE-2026-2673 Overview

CVE-2026-2673 is a cryptographic vulnerability in OpenSSL affecting TLS 1.3 server implementations. When a server's key exchange group configuration includes the DEFAULT keyword to incorporate the built-in default group list, an implementation defect causes the DEFAULT list to lose its "tuple" structure. This results in all server-supported groups being treated as a single sufficiently secure tuple, preventing the server from sending a Hello Retry Request (HRR) when a more preferred group from a higher security tuple is mutually supported by both client and server.

This vulnerability is particularly significant in the context of post-quantum cryptography adoption, as it may cause TLS 1.3 connections to fail to negotiate stronger hybrid post-quantum key agreement groups like X25519MLKEM768, instead falling back to classical groups such as X25519.

Critical Impact

TLS 1.3 connections may negotiate weaker key exchange groups than intended, potentially impacting cryptographic strength of encrypted communications and undermining post-quantum security preparations.

Affected Products

• OpenSSL 3.6 (prior to 3.6.2)
• OpenSSL 3.5 (prior to 3.5.6)

Discovery Timeline

• 2026-03-13 - CVE-2026-2673 published to NVD
• 2026-03-17 - Last updated in NVD database

Technical Details for CVE-2026-2673

Vulnerability Analysis

This vulnerability (CWE-757: Selection of Less-Secure Algorithm During Negotiation) stems from incorrect handling of the TLS 1.3 key exchange group configuration when using the DEFAULT keyword. OpenSSL 3.5 and later introduced a new syntax for managing key agreement groups that partitions them into distinct "tuples" representing roughly equivalent security levels. The server is designed to prefer groups from higher-security tuples and issue Hello Retry Requests when needed to achieve optimal security.

However, when the DEFAULT keyword is used to interpolate the built-in default group list into a custom configuration—whether adding or removing specific elements—the tuple structure is incorrectly flattened. This causes the server to treat all supported groups as belonging to the same security tier, eliminating the preference hierarchy and bypassing the HRR mechanism entirely.

The practical impact is that clients predicting only classical keyshares (such as X25519) in their initial ClientHello will not be prompted to retry with stronger post-quantum hybrid groups, even when both parties support them.

Root Cause

The root cause lies in the parsing and interpolation logic for the DEFAULT keyword within OpenSSL's key exchange group configuration handler. When the default list is expanded inline, the metadata indicating tuple boundaries is lost, causing all groups to be treated as equally preferred from a security standpoint. This implementation defect affects only configurations that use DEFAULT to customize the group list while retaining portions of the built-in defaults.

Attack Vector

The vulnerability is network-accessible and requires no authentication or user interaction. An attacker capable of observing or manipulating TLS handshakes could exploit this weakness in several ways:

1. Passive Downgrade Observation: Monitoring TLS connections to identify servers susceptible to weaker-than-expected key exchange, potentially harvesting encrypted traffic for future cryptanalysis as quantum computing advances.

2. Active Downgrade Attack: A network-positioned attacker could craft client connections that deliberately omit post-quantum keyshare predictions, knowing the server won't request a retry, ensuring all connections use classical cryptography.

3. Long-term Data Harvest: Organizations preparing for post-quantum security may believe their TLS 1.3 deployments are using hybrid key exchange when they are actually falling back to classical algorithms, creating a false sense of security.

The vulnerability does not affect OpenSSL FIPS modules as the relevant code lies outside the FIPS boundary.

Detection Methods for CVE-2026-2673

Indicators of Compromise

• TLS 1.3 connections consistently using classical key exchange groups (e.g., X25519, secp256r1) despite server and client support for post-quantum hybrid groups
• Absence of Hello Retry Request (HRR) messages in TLS handshake traces where post-quantum groups should be negotiated
• OpenSSL configuration files containing the DEFAULT keyword in key exchange group settings

Detection Strategies

• Audit OpenSSL server configurations for use of the DEFAULT keyword in Groups, SupportedGroups, or similar directives
• Analyze TLS handshake logs and packet captures to verify negotiated key exchange groups match expected security policies
• Implement automated scanning to identify OpenSSL versions 3.5.x and 3.6.x in production environments
• Review server certificates and connection metadata for unexpected fallback to classical-only key exchange

Monitoring Recommendations

• Deploy network monitoring to track key exchange groups used in TLS 1.3 handshakes across critical infrastructure
• Configure alerting for TLS connections that fail to negotiate expected post-quantum or hybrid key exchange groups
• Monitor OpenSSL version deployments and correlate against vulnerability databases for affected versions
• Implement periodic configuration audits to detect unauthorized or inadvertent use of the DEFAULT keyword

How to Mitigate CVE-2026-2673

Immediate Actions Required

• Upgrade OpenSSL 3.6.x installations to version 3.6.2 when released
• Upgrade OpenSSL 3.5.x installations to version 3.5.6 when released
• Review and modify server configurations to explicitly define key exchange groups rather than using the DEFAULT keyword
• Prioritize patching for servers handling sensitive data or those deployed as part of post-quantum security initiatives

Patch Information

OpenSSL has released security fixes addressing this vulnerability. The patches restore proper tuple structure handling when the DEFAULT keyword is used in key exchange group configuration.

Detailed patch information is available through the following resources:

• OpenSSL Security Advisory
• GitHub OpenSSL Commit 2157c9d
• GitHub OpenSSL Commit 85977e0
• OSS-Security Mailing List Disclosure

Note that OpenSSL versions 3.4, 3.3, 3.0, 1.1.1, and 1.0.2 are not affected by this vulnerability.

Workarounds

• Replace the DEFAULT keyword with an explicit list of key exchange groups in server configuration, preserving the intended tuple structure manually
• If explicit configuration is not feasible, temporarily use the built-in default group list without customization until patches are applied
• Consider downgrading to OpenSSL 3.4 or earlier unaffected versions if post-quantum key exchange is not immediately required
• Implement client-side enforcement of preferred key exchange groups where possible

# Configuration example: Explicit key exchange group configuration (avoiding DEFAULT keyword)
# Instead of: Groups = DEFAULT:-secp521r1
# Use explicit group list with intended tuple structure:
openssl s_server -groups X25519MLKEM768:X25519:secp256r1:secp384r1