Cloudanix VulnDB

CVE-2024-28755

Medium · 6.5

CVSS

6.5

EPSS

0.4%

Published

Apr 3, 2024

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in a popular encryption library can stop servers from using the newest secure connection method, potentially forcing weaker protection or blocking connections altogether.

Chainable
Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Denial Of Service
Component
Library
Class
Cryptographic Weakness
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Failure to restore the configured maximum TLS version after mbedtls_ssl_session_reset() allows an attacker to force negotiation of TLS 1.2 instead of TLS 1.3 or to block TLS 1.3 handshakes entirely.

Why it matters to the business

Organizations relying on Mbed TLS for TLS 1.3 may experience service disruption or be forced into weaker TLS 1.2 connections, increasing exposure to cryptographic attacks and potential compliance issues.

How an attack unfolds

An attacker repeatedly triggers mbedtls_ssl_session_reset() on a server context and then initiates a TLS handshake, causing the server to advertise only TLS 1.2 as the maximum version and resulting in a forced downgrade or denial of TLS 1.3 connections.

How to fix it

Upgrade Mbed TLS to the version containing commit 2ca6c285a0dd3f33982dd57299012dacab1ff206 (or later 3.6.0+ release) and rebuild all dependent applications. Verify that mbedtls_ssl_conf_max_tls_version is correctly restored after each reset in testing.

How to confirm the fix worked

After upgrade, perform automated tests that call mbedtls_ssl_session_reset() followed by a TLS 1.3 handshake and confirm the negotiated version matches the configured maximum. Monitor build pipelines for the fixed commit hash.

Typical attack path

  1. Identify a target server using Mbed TLS 3.5.x
  2. Trigger repeated calls to mbedtls_ssl_session_reset() via crafted or legitimate session resets
  3. Initiate a TLS ClientHello advertising TLS 1.3 support
  4. Observe server response limited to TLS 1.2 or handshake failure for TLS 1.3
  5. Repeat to sustain DoS or downgrade effect

How to detect it

Search TLS handshake logs for repeated ClientHello/ServerHello exchanges that negotiate TLS 1.2 when TLS 1.3 was expected, or for handshake failures immediately following session-reset events in application logs.

What your security team should do

  • Prioritize upgrade of all Mbed TLS 3.5.x deployments within the next sprint due to the stable but non-zero EPSS score
  • Add regression tests for session reset behavior in CI pipelines
  • Review downstream dependents of mbedtls for similar exposure
  • Update internal TLS configuration guidance to prefer TLS 1.3 only after remediation

The record

An issue was discovered in Mbed TLS 3.5.x before 3.6.0. When an SSL context was reset with the mbedtls_ssl_session_reset() API, the maximum TLS version to be negotiated was not restored to the configured one. An attacker was able to prevent an Mbed TLS server from establishing any TLS 1.3 connection, potentially resulting in a Denial of Service or forced version downgrade from TLS 1.3 to TLS 1.2.

Affected packages

Ecosystem Package Introduced Fixed
Debian:11 mbedtls 0 No fix
Debian:12 mbedtls 0 No fix
Debian:13 mbedtls 0 No fix
Debian:14 mbedtls 0 3.6.0-3
Ubuntu:20.04:LTS mbedtls 0 No fix
Ubuntu:22.04:LTS mbedtls 0 No fix
Ubuntu:24.04:LTS mbedtls 0 No fix
Ubuntu:24.10 mbedtls 0 No fix
Ubuntu:25.04 mbedtls 0 No fix
Ubuntu:Pro:16.04:LTS mbedtls 0 No fix
Ubuntu:Pro:18.04:LTS mbedtls 0 No fix
Ubuntu:Pro:20.04:LTS mbedtls 0 No fix

Related vulnerabilities