CVE-2026-25832 in Mbed TLS
Summary
by MITRE • 09/14/2026
In Mbed TLS 3.6.x before 3.6.7 and 4.1.x before 4.1.2, the TLS 1.3 client accepts HelloRetryRequest selecting an unadvertised group.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/14/2026
The vulnerability identified in Mbed TLS versions prior to 3.6.7 for the 3.6 branch and prior to 4.1.2 for the 4.1 branch represents a significant deviation from the strict key exchange requirements defined in Transport Layer Security version 1.3 specifications. This flaw specifically affects the client-side implementation of the TLS handshake protocol, where the library fails to adequately validate the cryptographic groups advertised by the server during the HelloRetryRequest phase against those initially offered by the client. In a standard TLS 1.3 connection initiation, the client sends a ClientHello message containing a list of supported key share groups, such as X25519 or P-256. If the server does not support any of these groups, it responds with a HelloRetryRequest message that includes its own preferred group in the selected_groups extension. The security integrity of this handshake relies on the client strictly adhering to the constraint that it must only select a key share from the list originally provided by itself or explicitly negotiated through this retry mechanism.
The technical flaw lies in the validation logic within the Mbed TLS implementation, which incorrectly permits the client to accept and utilize a cryptographic group specified in the HelloRetryRequest even if that specific group was not present in the initial ClientHello's supported groups extension. This behavior violates RFC 8446 Section 4.2.10, which mandates that the server must only select from the groups advertised by the client, or conversely, implies that the client should reject any selection that falls outside its own capabilities and prior advertisements if it is to maintain consistency in the negotiation state. By accepting an unadvertised group, the implementation creates a mismatch between the negotiated parameters and the initial capability set communicated during the handshake start. This discrepancy can lead to undefined behavior or potential crashes depending on how subsequent key derivation functions handle keys generated from groups that were not explicitly initialized for use by the client context.
From an operational impact perspective, this vulnerability primarily poses risks related to denial of service rather than direct confidentiality breaches in most standard configurations. An attacker positioned as a man-in-the-middle could craft malicious HelloRetryRequest messages containing arbitrary or malformed group identifiers. If the server is configured to support these groups but the client library accepts them despite not advertising them initially, it may proceed with key exchange using parameters that were never intended for use by that specific instance of Mbed TLS. This can result in connection failures, memory corruption due to improper initialization of elliptic curve contexts, or complete handshake termination. While this does not directly allow an attacker to decrypt traffic without the private keys, it undermines the robustness and predictability of secure connections, potentially facilitating availability attacks against services relying on strict compliance with TLS 1.3 standards for security policy enforcement.
This issue is categorized under CWE-20 Improper Input Validation, as the software fails to correctly validate input data received during the protocol negotiation phase. Specifically, it reflects a failure in enforcing constraints defined by the application layer protocol itself. In terms of offensive security frameworks, this vulnerability aligns with MITRE ATT&CK technique T1498 Network Denial of Service, particularly sub-technique 2 Indirect Flows or resource exhaustion through malformed handshake sequences. It also touches upon CWE-697 Incorrect Collaboration in Multi-party Protocols, as the client and server fail to reach a mutually consistent state due to improper validation of negotiated parameters. The flaw highlights the critical importance of strict adherence to protocol specifications in cryptographic libraries, where even minor deviations can lead to instability or security gaps.
Mitigation for this vulnerability requires immediate upgrading of the Mbed TLS library to version 3.6.7 or later if operating on the LTS branch, or version 4.1.2 and above for the development branch. These releases contain patches that enforce strict validation logic, ensuring that any group selected during a HelloRetryRequest was explicitly advertised in the initial ClientHello message. Organizations should also implement network-level monitoring to detect anomalous TLS handshake patterns, such as repeated HelloRetryRequests with unusual group selections, which may indicate exploitation attempts. Additionally, developers integrating Mbed TLS into their applications should ensure that their build configurations are updated and that any custom extensions or modifications do not bypass the newly enforced validation checks introduced in these patched versions. Regular security audits of cryptographic implementations remain essential to maintain compliance with evolving standards like RFC 8446 and to prevent similar implementation flaws from compromising secure communications infrastructure.