ESP-IDF CVE-2026-45329

The attacker must already be executing code in the Rich Execution Environment (REE) on an ESP32-family device whose firmware was built from ESP-IDF 5.5.4 or 6.0 with the ESP-TEE subsystem enabled and using the affected secure-service wrappers in esp_secure_services.c / esp_secure_services_iram.c (AES, SHA, ECC, SPI helpers). No authentication to the TEE is required (PR:N) - any REE-side caller can invoke the wrappers - and no user interaction is needed. Exploitation is limited to devices that target RISC-V ESP32 variants supporting ESP-TEE; pure Xtensa builds, builds without ESP-TEE enabled, and devices already upgraded to 5.5.5 or 6.0.1 are not exploitable. Realistic risk is further bounded by needing prior REE code execution and by the fact that some wrappers leak only one bit per call, requiring many invocations to recover a useful secret.

The CVSS 3.1 vector AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N gives a base score of 7.1 driven by changed scope and high confidentiality impact, with no impact to integrity or availability - consistent with an information-disclosure oracle against TEE secrets rather than code execution or denial of service. Attack vector is Local (AV:L), meaning the adversary must already be running code in the REE on the target ESP32 device (e.g., compromised application firmware or a malicious component invoking secure-service syscalls); this substantially limits remote exploitability and rules out network-only attacks. EPSS, KEV, and SSVC data were not provided, and no public exploit code was identified at time of analysis, suggesting this is not currently a mass-exploitation candidate; however, the issue is a real priority for any deployment that relies on ESP-TEE to protect keys, secure-boot material, NVS encryption keys, or attestation secrets because the oracle pattern enables incremental recovery even when only one bit leaks per call. PR:N is somewhat counterintuitive for a local attack and reflects that any REE-side caller - not just a privileged one - can invoke the wrappers; defenders should read this as 'any REE code path' rather than 'unauthenticated network attacker'.

An attacker who has already achieved code execution in the REE on an ESP32 device (e.g., via a vulnerable network service in the application firmware or a malicious update) invokes the ESP-TEE secure-service wrapper for SHA or AES, supplying an 'input' pointer that points into TEE-exclusive memory holding signing keys or NVS encryption material. The M-mode peripheral dutifully reads from the TEE address and returns either raw bytes, a hash derived from them, or a single result bit; by repeating the call with shifted pointers the attacker reconstructs the secret byte-by-byte. No public PoC has been published, but the patch commits clearly identify the vulnerable parameter set, making targeted exploit development by an attacker with REE code execution straightforward.