Heap corruption with early renegotiation after corrupted record in DTLS (CVE-2026-50713)

Title	Heap corruption with early renegotiation after corrupted record in DTLS
CVE	CVE-2026-50713
Date	7th of July, 2026
Affects	Mbed TLS 3.6.3 to 3.6.6
Not affected	Mbed TLS 3.6.2 and earlier; Mbed TLS 4.0.0 and later
Impact	Remote code execution through heap corruption
Severity	HIGH
Credits	Haruki Oyama

Vulnerability

Mbed TLS 3.6.3 added support for receiving fragmented handshake messages in TLS 1.2 and 1.3, for interoperability. This new feature required an extra field in the TLS context (mbedtls_ssl_context), called in_hsfraglen in Mbed TLS 4.0.0, containing the amount of data that is already received in an incomplete handshake message. In the 3.6 long-term support (LTS) branch, in order to preserve ABI compatibility, the existing field badmac_seen was renamed to badmac_seen_or_in_hsfraglen. In DTLS, this field tracks the number of records received with a bad MAC (or authentication tag, in AEAD cipher suites). In TLS, this field was previously unused, and is now used for handshake message parsing.

Due to an implementation mistake, the code sometimes reads the dual-purpose field without checking the active protocol. Specifically, at the beginning of mbedtls_ssl_prepare_handshake_record(), the field ssl->in_hslen is not updated when ssl->badmac_seen_or_in_hsfraglen != 0. Thus, after receiving a message with a bad MAC, the handshake message length is not updated, which causes problems in subsequent processing.

During the initial DTLS handshake, only the last message (Finished) is authenticated with a MAC or tag, and if the MAC is invalid, the handshake is rejected immediately. (Note that only DTLS 1.2 is supported, not DTLS 1.3.) Therefore ssl->badmac_seen_or_in_hsfraglen remains 0.

After exchanging application data, ssl->badmac_seen_or_in_hsfraglen may be nonzero if a bad-MAC limit has been set with mbedtls_ssl_conf_dtls_badmac_limit(). If the library sees a handshake message, it can only legitimately be a renegotiation attempt. If renegotiation is disabled (at compile time or run time), the attempt is correctly rejected.

However, if renegotiation is enabled, the library decrypts and parses the handshake message. Due to the incorrect value of ssl->in_hslen, the normal message processing fails.

Furthermore, if the handshake message’s sequence number indicates a prior missing record, then this message needs to be queued. This happens in the function ssl_buffer_message(), which allocates a heap buffer to store the message. The buffer size is ssl->in_hslen, which is still 0. On most platforms, malloc(0) reserves a unique heap location whose size is only a few bytes. The library then writes at least a reconstructed 12-byte header, followed by the message content, whose length is determined from the message content. This overflows a heap buffer, thus corrupts the heap.

Impact

A man-in-the-middle in a DTLS connection where one endpoint has enabled renegotiation and has set a limit to the number of corrupted records can cause heap corruption by rearranging traffic or injecting specially crafted packets. Depending on the application and on the memory layout, this may allow remote code execution.

Affected versions

Only versions of Mbed TLS from 3.6.3 to 3.6.6 are affected.

Work-around

Applications are affected only if they declare a limit to the number of records with a bad MAC/tag with mbedtls_ssl_conf_dtls_badmac_limit(). By default, the bad MAC count is unlimited, which avoids the bug.

Applications are affected only if renegotiation is enabled. It is disabled by default.

Resolution

Affected users should upgrade to Mbed TLS 3.6.7 or a later 3.6.x version, or to Mbed TLS 4.x (which has incompatible changes).

Fix commits

We recommend that users upgrade to a release including the fix. However, if you are maintaining a branch with backported bug fixes, here are the most relevant commits. Please note that these commits may not apply cleanly to older versions of the library, and may not provide a complete fix even if they do apply. The TF-PSA-Crypto and Mbed TLS development team does not provide support outside of maintained branches.

Branch	Mbed TLS 3.6.x	Mbed TLS 4.1.x	Mbed TLS 4.x (x>1)
Basic fix	24c2875cb0eb655fffe7b6a7a956f34bacb7b0a4	N/A	N/A
With tests and documentation	915442dbedffa7c856b92a021e9ac40176514f20..794e1a89db1fdf101ce39134647d08b0bd936e3f	N/A	N/A