CVE-2024-28836

What it actually does

Server-side TLS version negotiation in Mbed TLS 3.5.x falls back to a disabled TLS 1.2 implementation, allowing a TLS 1.2 ClientHello to trigger an infinite loop (when TLS 1.2 disabled at build time) or establish a downgraded TLS 1.2 session (when disabled at runtime).

Why it matters to the business

Services relying on Mbed TLS for TLS 1.3-only operation can experience denial of service or unintended exposure to weaker protocol versions, leading to availability loss and potential security posture degradation.

How an attack unfolds

An attacker connects to a vulnerable server and sends a TLS 1.2 ClientHello; the server incorrectly processes the message under the disabled TLS 1.2 code path, either looping indefinitely or completing a downgraded handshake.

How to fix it

Upgrade Mbed TLS to the fixed commit 2ca6c285a0dd3f33982dd57299012dacab1ff206 (equivalent to 3.6.0) or later; rebuild and redeploy all affected binaries.

How to confirm the fix worked

Confirm the library version reports 3.6.0 or newer; perform functional testing by sending TLS 1.2 ClientHello packets and verifying the server rejects them without looping or accepting the connection.

Typical attack path

1. Scan for services advertising TLS 1.3 support but using Mbed TLS 3.5.x
2. Send a TLS 1.2 ClientHello packet to the target server
3. Observe server entering infinite loop (DoS) or accepting the downgraded TLS 1.2 session

How to detect it

Monitor process CPU usage and connection handling logs for sustained high utilization after TLS handshakes; inspect server logs for unexpected TLS 1.2 negotiation attempts or fallback messages.

What your security team should do

• Prioritize upgrade of all Mbed TLS instances to the fixed commit within normal change windows
• Audit build and runtime configuration to ensure only intended TLS versions are enabled
• Add version checks for Mbed TLS to dependency scanning pipelines