# Remote buffer overflow in TLS 1.2 ECDHE-PSK client handshake (CVE-2026-50580)

**Title** | Remote buffer overflow in TLS 1.2 ECDHE-PSK client handshake
--------- | ----------------------------------------------------------
**CVE** | CVE-2026-50580
**Date** | 7th of July, 2026
**Affects** | Mbed TLS 1.3.10 through 3.6.6; Mbed TLS 4.0.0 through 4.1.0
**Not affected** | Mbed TLS 1.3.9 and earlier; Mbed TLS 3.6.7 and later 3.6.x versions; Mbed TLS 4.1.1 and later 4.1.x versions; Mbed TLS 4.2.0 and later versions; TF-PSA-Crypto
**Impact** | A malicious TLS 1.2 server can cause a client configured with an oversized PSK identity to write past the end of the TLS output buffer when an ECDHE-PSK ciphersuite is negotiated.
**Severity** | HIGH
**Credits** | Karnakar Reddy (@karnakarreddi)

## Vulnerability

In TLS 1.2 clients, `ssl_write_client_key_exchange()` constructs the
ClientKeyExchange message for ECDHE-PSK ciphersuites by writing the PSK
identity followed by the client's ephemeral EC public key. Before the fix, the
ECDHE-PSK path checked that the output message buffer had enough room for the
handshake header, the two-byte PSK identity length, and the PSK identity, but
did not reserve room for the following one-byte EC point length field and the
EC public key.

If the client was configured with a sufficiently long PSK identity, this check
could pass while leaving too little room for the EC public key. The subsequent
public key export then computed the remaining output space from a pointer that
could already be beyond the intended TLS output-content boundary. This could
underflow the available-length calculation and let the public key export write
past the end of the TLS output buffer in affected configurations.

Applications are vulnerable when they use a TLS 1.2 client configured with an
oversized static PSK identity, allow negotiation of ECDHE-PSK ciphersuites, and
run with an output-buffer layout that does not leave enough spare space after
`MBEDTLS_SSL_OUT_CONTENT_LEN` to absorb the overflow. The issue is exposed in
particular when CBC ciphersuites are disabled, reducing the extra output-buffer
padding that otherwise masks the overwrite in common configurations.

## Impact

A malicious TLS 1.2 server or a TCP man-in-the-middle that negotiates an
ECDHE-PSK ciphersuite with an affected client can trigger memory corruption
while the client constructs its ClientKeyExchange message. Confirmed outcomes
include a client-side process crash and denial of service. Depending on
allocator behavior, build configuration, and application memory layout, code
execution and heap corruption may be possible.

For the attack to be possible, the client application must be configured with a
very long PSK identity and must offer ECDHE-PSK ciphersuites. Applications that
use short PSK identities are not vulnerable to this issue: the PSK identity must
be long enough that the ECDHE-PSK ClientKeyExchange message can fit the
handshake header and PSK identity, but not the following EC public key.

## Affected versions

Mbed TLS versions 1.3.10 through 3.6.6 and 4.0.0 through 4.1.0 are affected
when `MBEDTLS_KEY_EXCHANGE_ECDHE_PSK_ENABLED` is enabled and the application can
use an oversized PSK identity.

Mbed TLS 1.3.9 and earlier are not affected because they do not have
ECDHE-PSK support. Mbed TLS 3.6.7 and later 3.6.x versions, Mbed TLS 4.1.1 and
later 4.1.x versions, and Mbed TLS 4.2.0 and later versions include the fix.

TF-PSA-Crypto is not affected.

## Work-around

Applications can avoid the issue by using short PSK identities. For
ECDHE-PSK, the ClientKeyExchange message needs 7 bytes of header and length
fields, the PSK identity, and the encoded client EC public key. The encoded
public key size depends on the negotiated curve; for the largest currently
supported built-in curves, reserving 133 bytes for it is sufficient. Therefore,
applications using those curves are not affected if the PSK identity length is
at most `MBEDTLS_SSL_OUT_CONTENT_LEN - 140` bytes. For example, this allows PSK
identities up to 116 bytes with `MBEDTLS_SSL_OUT_CONTENT_LEN` set to 256, or up
to 884 bytes with `MBEDTLS_SSL_OUT_CONTENT_LEN` set to 1024. A 64-byte PSK
identity has enough room even with a 256-byte output content buffer.

Applications are also not vulnerable if they do not use TLS clients, do not
enable TLS 1.2, or do not enable ECDHE-PSK ciphersuites. If applications cannot
rely on PSK identity lengths being short enough or disable TLS 1.2 ECDHE-PSK
support by disabling `MBEDTLS_KEY_EXCHANGE_ECDHE_PSK_ENABLED`.

## Resolution

Affected users should upgrade to Mbed TLS 3.6.7 or a later 3.6.x version,
Mbed TLS 4.1.1 or a later 4.1.x version, or Mbed TLS 4.2.0 or a later version.

## 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 Mbed TLS development team does not provide support outside of maintained branches.

| Branch | Mbed TLS 3.6.x | TF-PSA-Crypto 1.1.x | TF-PSA-Crypto 1.x (x>1) | Mbed TLS 4.1.x | Mbed TLS 4.x (x>1) |
| ------ | -------------- | ------------------- | -------------------------- | -------------- | --------------------- |
| Basic fix | f9835c081f1ebed8c2ea3b23574da71c1bb66e44 | N/A | N/A | f63ca6e0af1d37ae048e00e692f21d302d0acd25 | baf449db7e31f031ed5def0fecf417122f72d3ee |
| With tests and documentation | f9835c081f1ebed8c2ea3b23574da71c1bb66e44^..b961ac2cf2472829066a97f10af544af267cfca2 | N/A | N/A | f63ca6e0af1d37ae048e00e692f21d302d0acd25^..a98b95074ad1d2a73e91278a380a424f3f4df4c6 | baf449db7e31f031ed5def0fecf417122f72d3ee^..911b9b67dbf335f79253c2b66acc9767e34b3105 |