CVE-2025-52496: Mbed TLS AESNI Race and Azure Linux Attestation

Mbed TLS versions before 3.6.4 contain a race in the AESNI detection path (tracked as CVE‑2025‑52496) that can, under specific compiler and multithreaded conditions, temporarily force the library to fall back to a software AES/GCM path and expose cryptographic operations to side‑channel attacks — allowing AES key extraction or GCM forgeries — and Azure Linux is the Microsoft product Microsoft has publicly attested to include the vulnerable library, but that attestation is a scoped inventory statement rather than a guarantee that no other Microsoft artifact includes the same code.

Background / Overview​

Mbed TLS (formerly PolarSSL) is a widely used open‑source TLS/crypto library targeted at embedded and general‑purpose applications. In late June/early July 2025 maintainers published a security advisory describing a race condition in the runtime detection of AESNI/CLMUL support: when multiple threads call the detection routine concurrently and certain compiler optimizations reorder writes, another thread can read an incompletely-initialized result and fall back to the software AES/GCM implementation. That fallback can expose AES operations to cache‑timing style analysis, enabling key extraction in some scenarios or GCM forgery in others. Upgrading to Mbed TLS 3.6.4 (the fixed release) is the recommended remediation.
Microsoft’s Security Response Center (MSRC) published a product‑mapping attestation that explicitly calls out Azure Linux (Microsoft’s cloud Linux distribution lineage) as including the implicated open‑source library and therefore being potentiallnoted that Microsoft began publishing machine‑readable CSAF/VEX attestations in October 2025 and will update CVE records if additional Microsoft products are found to include the same component. That MSRC wording is authoritative for Azure Linux customers but must be read as a product‑scoped attestation, not a claim of exclusivity.
This article explains the technical problem, the real‑world exploitability profile, what Microsoft’s Azure Linux attestation does — and does not — mean, and gives practical guidance for operators who run Microsoft artifacts (Azure Linux images or any other Microsoft‑provided images/agents) on how to discover exposure and remediate effectively.

---

What the vulnerability actually is​

Technical anatomy​

• The bug lives in the runtime CPU‑feature detection routine used by Mbed TLS to decide whether to use hardware accelerated AES/GCM (AES‑NI/CLMUL) or a portable table‑based implementation.
• The detection function caches the computed result in a global variable (for example, c) and uses another global flag (for example, done) to indicate initialization has completed. Under certain compiler optimization patterns the ordering of writes to c and done can be reordered such that another thread sees done set but c still unset or set to an incorrect default.
• That mistaken read causes the second thread to select the software AES implementation while the first thread intended and later sets the hardware capability. The software implementation — in this particular case — is subject to microarchitectural side‑channel leakage (cache‑timing) that an adversary can measure from a collocated attacker thread/process and use to recover AES keys or to mount forgery attacks against GCM.

Mbed TLS maintainers describe the bug and its fix in their security advisory; upstream fixed the race and released Mbed TLS 3.6.4 to resolve it. Single‑threaded programs or programs that ensure one thread performs an AES operation before any other thread starts are not vulnerable in practice because the cached detection then becomes valid before concurrent access occurs. Compiler and optimization interactions are a necessary component of the exploit vector: GCC older than 7 (notably GCC ≤6.x) produced binaries where the reorderings could occur at optimization levels like -O2 or -Os more often than newer compilers; later GCC and Clang builds and changes to compiler intrinsics reduce the likelihood of vulnerable codegen.

Where the practical risk concentrates​

• Multithreaded servers or long‑running daemons that perform frequent AES/GCM operations in parallel threads.
• Environments where an attacker can run a local thread or process that measures microarchitectural state (e.g., shared hosting, co‑located untrusted workloads, or certain enclave/VM scenarios with untrusted co‑tenants).
• Binaries compiled with older compilers or specific optimization flags that increase the chance of the problematic instruction ordering.

NVD, distribution advisories and independent analyses characterize the vulnerability as high in impact (confidentiality and integrity) but dependent on local access and exploit complexity — factors that reduce mass exploitation likelihood but leave targeted attacks feasible in high‑value settings. (nvd.nist.gov

---

Microsoft’s statement and what the Azure Linux attestation means​

What Microsoft said — the plain reading​

Microsoft’s MSRC entry for the CVE includes an FAQ line that reads, in essence: “Azure Linux includes this open‑source library and is therefore potentially affected by this vulnerability. Microsoft began publishing CSAF/VEX attestations in October 2025 and will update the CVE if impact to additional products is identified.” That language was chosen as part of Microsoft’s phased CSAF/VEX rollout and is a deliberate, product‑scoped attestation.

What that language does not mean​

• It does not say that Azure Linux is the only Microsoft product that could possibly contain the vulnerable Mbed TLS code.
• It does not imply that non‑attested Microsoft products are certified safe — in Microsoft’s model, absence of an attestation for a product typically means “not yet attested,” not “proven clean.”
• It does not absolve customers who run other Microsoft artifacts (Marketplace images, WSL kernels, linux‑azure kernels, published by Microsoft, or partner‑published images inside the Azure ecosystem) from doing artifact‑level verification.

Read operationally: MSRC’s attestation is an authoritative signal that *Azure Linux images were inspected and found to ship the implicated component, and therefore Azure Linux customers must prioritize patchin the statement leaves other artifacts as “unknown” (until Microsoft’s inventory completes and extra attestations are published). Treat the attestation as confirmed presence for the named product*, not as a global exclusion for every other Microsoft product.

---

Is Azure Linux the only Microsoft product potentially affected?​

Short answer: No — but with important nuance.

• Azure Linux is the only Microsoft product Microsoft has publicly attested to include the vulnerable Mbed TLS library at the time of the advisory. That attestation is authoritative for Azure Linux customers.
• However, Microsoft ships many other Linux‑based artifacts (WSL2 kernels, linux‑azure kernels, Marketplace images, curated container base images, agent binaries and SDKs). Whether any of those other artifacts are affected depends on build provenance: which Mbed TLS version was compiled in, whether the runtime detection code was enabled, and whether the artifact was built with a compiler/version/op ic ordering.
• Because the presence of vulnerable code is an artifact‑level property (dependent on the exact build, compiler, flags, and whether the code was vendored or statically linked), it is entirely plausible that other Microsoft artifacts could contain the same vulnerable component even if Microsoft’s initial attestation named only Azure Linux. Microsoft has committed to updating the CVE mapping as it completes inventory work; until then, absence of other product names should be interpreted as “not yet attested” rather than “safe.”

In short: treat the MSRC entry as a call to action for Azure Linux and as a cautionary flag to run your own artifact discovery across any Microsoft‑provided images or binaries you rely upon.

---

How to determine whether your Microsoft artifacts are affected​

Inventory and evidence-based verification are the only reliable ways to decide exposure. Follow these pragmatic steps:

• Inventory images and binaries
• Enumerate all Microsoft‑published images and binaries you run: Azure VM images (including custom Marketplace images you pulled), AKS node images, WSL2 kernel binaries, linux‑azure kernels, Azure agents, and any Microsoft container base images.
• Capture exact image tags, kernel versions, package versions and build provenance — not just generic product names.
• Scan for Mbed TLS artifacts
• Search packages (rpm/dpkg manifests) inside images for mbedtls (mbedtls, mbed‑tls) and for library filenames (e.g., libmbedtls.so.*), and note the package version.
• For statically linked or vendored binaries, run binary scanning tools that detect embedded Mbed TLS symbols or version strings; inspect go/mod or other language‑specific dependency manifests where applicable.
• Check build/compiler provenance
• If a binary contains Mbed TLS, identify the compiler and optimization flags used to build it when possible. Binaries built with older GCC versions and aggressive optimizations are more likely to be vulnerable when the detection code was present.
• Validate runtime behavior (in staging)
• Where practical, reproduce a constrained test: run a multithreaded AES/GCM workload in a staging environment and check whether the library uses hardware AESNI or falls back to software tables at runtime during concurrent startup. (Do not run risky PoCs in production.)
• Rely on vendor attestations and SBOMs
• Consume Microsoft’s CSAF/VEX machine‑readable attestations for Azure Linux and watch for additional attestations. For other Microsoft artifacts, demand SBOMs or ask vendors to confirm whether Mbed TLS 3.6.3 or earlier was shipped in your artifact; treat the absence of an attestation as an unresolved question.

These are operational checks — do not assume absence of a named product equals absence of risk. Automated scanners, SBOM inventories and image layer analysis are your fastest path tRemediation and mitigation

• Primary remediation: Upgrade to Mbed TLS 3.6.4 or later across all affected artifacts and rebuild any statically‑linked or vendored binaries. This is the only robust fix.
• Distribution packages: Apply vendor-supplied security updates where your distro or image vendor provides a patched package. For Azure Linux images Microsoft will publish or has published updated packages as part of the distribution security process; apply those updates to your VMs and node images.
• Short‑term mitigations when patching immediately isn’t feasible:
• Ensure a single thread performs an AES operation (hardware detection) before other threads start cryptographic operations at process startup (this reduces exposure in some cases, but is an operational workaround rather than a fix).
• Compile Mbed TLS with MBEDTLS_AES_USE_HARDWARE_ONLY if you control the build and do not need the software fallback on CPUs that lack AESNI — this removes the table implementation and closes the specific fallback window.
• Limit local attacker capabilities: reduce co‑tenant or unprivileged process ability to run timing measurements (isolate tenants, restrict untrusted code execution), though these controls are imperfect against advanced threat actors.
• Secrets hygiene: If you have reason to suspect key exposure (e.g., untrusted co‑tenant workloads running during the exposure window on the same host), rotate keys and credentials used by affected services after patching and investigate logs for suspicious local activity.

---

Risk analysis — who should worry most​

• Immediate high priority: multi‑tenant hosts, shared build agents, or systems that let untrusted users run code co‑resident with cryptographic services. Those environments provide the local access advantage an attacker needs to exploit a microarchitectural side‑channel.
• Medium priority: single‑tenant long‑running multithreaded services built and deployed with older compilers (GCC ≤6.x) or with known problematic optimization flags. These require certain compiler/optimization combinations to be exploitable.
• Lower priority: single‑threaded progron CPUs without AESNI/CLMUL (they wouldn’t have the hardware path), or applications compiled with newer compilers where the specific reordering is prevented.

Even where the overall probability of exploitation is low, the impact of a successful key extraction or GCM forgery is very high. Treat high‑value cryptographic services and secrets transport paths as if they were compromised until proven otherwise.

---

Practical checklist for Microsoft customers​

• If you run Azure Linux images: follow Microsoft’s updates immediately — MSRC has attested Azure Linux includes the library and those images should be prioritized.
• If you run other Microsoft‑supplied artifacts (Marketplace images, WSL kernels, linux‑azure kernels, Azure VM SKUs that include Microsoft‑provided agents or kernels): treat them as “unverified” until you confirm via SBOM, image scanning, or Microsoft VEX attestations that they don’t ship Mbed TLS ≤3.6.3.
• For containerized workloads: scan image layers and rebuild images that include vulnerable Mbed TLS or statically linked binaries using the patched library.
• For CI/build systems: identify build nodes that may have produced vulnerable binaries. Rebuild artifacts with patched Mbed TLS and modern compilers where possible.
• For high‑value keys: consider rotating keys that were used on hosts where vulnerable Mbed TLS may have run during the exposure window.

---

Why vendor attestations mat​

Microsoft’s phased CSAF/VEX rollout (which began in October 2025) provides a machine‑readable, automatable way to consume vendor attestations about which products ship which components. That is a major win for defenders because it enables precise triage. But it is a phased program: initially MSRC attested Azure Linux and will expand product mappings over time; the attestation is therefore an authoritative yes for Azure Linux, but silence for other products is merely “not yet attested.” Organizations should not treat the initial attestation as comprehensive across Microsoft’s entire product surface.

---

Final assessment and recommendations​

CVE‑2025‑52496 is a concrete, high‑impact vulnerability where the practical exploitability depends on a set of constraints (multithreading, compilers/optimization, local access to timing channels). Microsoft has performed the correct initial step: identify a product in its portfolio (Azure Linux) that includes the vulnerable library and publish a VEX/CSAF attestation so Azure Linux customers can act. However, Microsoft’s single‑product attestation should be seen as the start of a broader inventory effort, not as proof that other Microsoft artifacts are safe.
If you run Azure Linux, treat the MSRC attestation as an authoritative signal and patch now. If you run other Microsoft‑provided kernels, images, agents, or container base layers, do not assume safety — run artifact‑level discovery (SBOMs, image scans, binary analysis) to confirm whether Mbed TLS ≤3.6.3 appears in your deployments. Where you find the vulnerable library, upgrade to Mbed TLS 3.6.4 (or apply vendor patches), rebuild statically linked binaries and container images, and rotate secrets when exposure is credible.
This incident is also a reminder of three broader operational truths:

• Supply‑chain and artifact‑level visibility (SBOMs, image scanning) are indispensable for accurate triage.
• Vendor attestations like CSAF/VEX are powerful aureat early, partial attestations as exhaustive.
• Small, local bugs in crypto or detection code can have outsized consequences; apply defense‑in‑depth (isolation, key rotation, hardened builds) to reduce single‑point cryptographic risks.

Microsoft’s published guidance correctly flags Azure Linux for immediate attention and promises to exrs should treat that as the near‑term priority while working to establish full visibility across their Microsoft‑supplied artifacts and the rest of their estate.
Conclusion: Azure Linux is the product Microsoft has confirmed contains the vulnerable Mbed TLS code and therefore must be treated as affected; other Microsoft artifacts could still carry the same vulnerable library, so do not assume exclusivity — inventory, scan, patch, and rebuild wherever Mbed TLS ≤3.6.3 appears.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center