CVE-2025-52496Disclosure(arm / mbed_tls)

LOWCVSS 7.8 · HIGH

Signal is active with 1 mentions in latest observed window

Immediate actions

  • Track advisory updates for patch or workaround availability

Recommended action window: Monitor and triage in normal cycle

NVD description

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.

0.0/ 10 priority

Sources & remediation

Weakness type (CWE)
CWE-733

Priority

LOW

Exploitation

NONE

PoC

YES

Patch

NONE

Momentum

NONE

Are you affected?

If you run products in this scope, you should treat this CVE as relevant to your environment.

  • mbed_tls

Threat summary

  • 1 mentions across 1 observed day

What's happening

  • Technical details provided in 1 signal
  • Disclosure: 1 classified signal
  • 1 total mentions across 1 day

Affected systems

Vendors
Products
mbed_tls

Deep dive

Activity timeline1 mentions / 1d
00111Mentions · 2026-07-01: 1Technical Details · 2026-07-01: 107-01
Signal classification1 categories
Disclosure
1100.0%
Referenced assets1 URL
By indicator
Full discourse1 post
  • Daniel J. Bernstein@hashbreaker
    Disclosure

    @FlorianHeigl1 @veorq @harryhalpin We're still seeing AES cache-timing vulnerabilities such as https://www.cve.org/CVERecord?id=CVE-2025-52496. NIST has never withdrawn its claim "Table lookup: not vulnerable to timing attacks" from the selection of Rijndael as AES. But they do seem to be grudgingly admitting AES block size is too small.

    Post summary

    The tweet reports that AES cache‑timing flaws (CVE‑2025‑52496) remain active and notes NIST’s ongoing claim that Rijndael is not vulnerable to timing attacks, highlighting the persistence of the vulnerability and the need for vigilance.

    0002150
    24.0K followersView on X
CPE platform detail1 entries

1 of 1 entries

PartVendorProductVersionTarget SWTarget HW
Apparmmbed_tls---

Explore more