Cloudanix VulnDB

CVE-2025-52496

None

CVSS

—

EPSS

0.2%

Published

Jul 4, 2025

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A flaw in a widely used encryption library could let attackers steal secret keys or alter protected data when software runs multiple tasks at the same time.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Data Exposure
Component
Library
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in AESNI detection code under specific compiler optimizations allows timing or state leakage that can expose AES keys or enable GCM tag forgery in multithreaded callers.

Why it matters to the business

Applications relying on Mbed TLS for AES/GCM in concurrent workloads face elevated risk of cryptographic key compromise or authenticated encryption bypass, potentially exposing sensitive data or allowing tampering.

How an attack unfolds

An attacker identifies a multithreaded process using Mbed TLS for AES operations, triggers the race during AESNI capability detection via concurrent execution and compiler-optimized paths, then leverages the resulting leakage or weakened GCM state to extract keys or forge ciphertexts.

How to fix it

Upgrade armmbed/mbedtls to the commit c765c831e5c2a0971410692f92f7a81d6ec65ec2 (corresponding to version 3.6.4 or later) in all affected builds and rebuild dependent applications.

How to confirm the fix worked

Confirm the library version or commit hash matches the fixed revision, review build logs for the corrected AESNI detection code, and test multithreaded AES/GCM workloads for consistent behavior.

Typical attack path

  1. Identify target process using Mbed TLS for AES/GCM in a multithreaded context
  2. Force concurrent execution paths that exercise AESNI detection under affected compiler optimizations
  3. Observe or manipulate timing/state leakage to recover AES key material or GCM authentication state
  4. Decrypt captured traffic or inject forged GCM-protected messages

How to detect it

Review application logs and process traces for unexpected AES key handling or GCM failures in multithreaded contexts; no public exploitation artifacts are known, so focus on post-patch behavioral anomalies.

What your security team should do

  • Prioritize upgrade of Mbed TLS to the fixed commit across all products and rebuild pipelines
  • Audit multithreaded usage of AES/GCM in applications and apply additional runtime mitigations if immediate patching is delayed
  • Monitor upstream Mbed TLS releases and dependency scanners for further updates

The record

Mbed TLS before 3.6.4 has a race condition in AESNI detection if certain compiler optimizations occur. An attacker may be able to extract an AES key from a multithreaded program, or perform a GCM forgery.

Affected packages

Ecosystem Package Introduced Fixed
Alpine:v3.20 mbedtls 0 3.6.4-r0
Alpine:v3.21 mbedtls 0 3.6.4-r0
Alpine:v3.22 mbedtls 0 3.6.4-r0
Debian:11 mbedtls 0 No fix
Debian:12 mbedtls 0 No fix
Debian:13 mbedtls 0 No fix
Debian:14 mbedtls 0 3.6.4-1
openSUSE:Leap 16.0 mbedtls 0 3.6.6-bp160.1.1

Related vulnerabilities