Mbed TLS Race Condition Vulnerability (CVE-2025-52496): AES Key Disclosure Risk

A race condition in Mbed TLS versions ≤3.6.3 could expose AES keys and enable GCM forgeries through cache-timing attacks.
CVE Analysis

6 min read

ZeroPath Security Research

ZeroPath Security Research

2025-07-04

Mbed TLS Race Condition Vulnerability (CVE-2025-52496): AES Key Disclosure Risk

Mbed TLS Race Condition Vulnerability (CVE-2025-52496): AES Key Disclosure Risk

Introduction

A subtle yet critical race condition in Mbed TLS versions up to 3.6.3 could enable sophisticated attackers to extract AES keys or forge GCM authentication tags. This vulnerability, identified as CVE-2025-52496, specifically affects multithreaded applications running on x86/amd64 hardware with AESNI support. While challenging to exploit, the implications for confidentiality and integrity in sensitive environments—particularly those leveraging Intel SGX enclaves—are severe.

Mbed TLS, formerly PolarSSL, is an open-source cryptographic library maintained by Arm under the TrustedFirmware project. Widely deployed in embedded systems, IoT devices, and critical infrastructure, its security integrity is paramount.

Technical Information

Vulnerability Mechanism

The vulnerability arises from a race condition in the mbedtls_aesni_has_support() function, which determines hardware AESNI support:

static int done = 0; static int c = 0; int mbedtls_aesni_has_support(void) { if (!done) { c = detect_aesni_support(); done = 1; } return c; }

Compiler optimizations, especially in GCC ≤6.x at optimization levels -O2 or -Os, may reorder instructions, causing done to be set before c is initialized. In a multithreaded context:

  • Thread 1 starts detection but delays initializing c.
  • Thread 2 sees done=1 and incorrectly uses c=0, falling back to the software AES implementation vulnerable to cache-timing attacks.

This temporary fallback exposes cryptographic operations to side-channel attacks, potentially enabling AES key extraction or GCM forgery.

Attack Vectors and Exploitation Methods

Exploitation requires:

  • Local access to measure cache latency.
  • Precise control over thread execution (e.g., suspending threads in SGX enclaves).
  • Compiler-specific conditions (GCC ≤6.x).

These stringent requirements limit exploitation to highly specialized environments and advanced threat actors.

Affected Systems and Versions

  • Mbed TLS versions: All versions up to and including 3.6.3.
  • Hardware: x86/amd64 CPUs with AESNI support.
  • Configuration: Multithreaded applications performing AES/GCM operations.

Patch Information

Mbed TLS 3.6.4 addresses this vulnerability by ensuring thread-safe AESNI detection, preventing concurrent access issues. The update also resolves additional vulnerabilities, including a heap buffer under-read in PEM parsing and unchecked return values in LMS verification. Users should upgrade immediately to version 3.6.4 or later.

Vendor Security History

Mbed TLS has historically demonstrated prompt and effective responses to security vulnerabilities. This issue was responsibly disclosed by Solar Designer and patched within a month, reflecting the project's commitment to security.

References

Security teams should prioritize this update, particularly in environments leveraging SGX or similar technologies, to mitigate potential exploitation risks.

Source: This report was created using AI

If you have suggestions for improvement or feedback, please reach out to us at [email protected]

Detect & fix
what others miss